Feature Request Are there plans to compile ISystem foreach as jobs?

Similar to Entities.ForEach, will foreach on queries ever be the way we write jobs for ISystem?

Code (CSharp):

1. foreach (var (transform, speed) in SystemAPI.Query<TransformAspect, RefRO<RotationSpeed>>().Job())
2. {
3.        transform.RotateLocal(quaternion.RotateY(speed.ValueRO.RadiansPerSecond * deltaTime));
4. }

Sth like that? Or this:

Code (CSharp):

1. SystemAPI.JobQuery<TransformAspect, RefRO<RotationSpeed>>()

Both are a bit weird, but I think there is a way.

I really like ISystem, buit the verbosity of jobs is my only reason for not switching to it.
https://github.com/Unity-Technologi...Scripts/Gameplay/Race/PlayerProgressSystem.cs

P.S. ChatGPT tells me that it is possible to use attributes there

Code (CSharp):

1. [JobAttributeExample1]
2. foreach (var (transform, speed) in [JobAttributeExample2]SystemAPI.Query<TransformAspect, RefRO<RotationSpeed>>().Job())
3. {
4.         transform.RotateLocal(quaternion.RotateY(speed.ValueRO.RadiansPerSecond * deltaTime));
5. }

 

No plans to make SystemAPI.Query based jobs. We tried it with EntitiesForEach, but learnt that it wasn't what we wanted in the long run. That said, we recognize the concern and want to make it easier to go from main thread to multi-threaded :3

Kind Regards
- Dani

 

Thank you for the answer. I'm not surprized that you didn't like the Entities.ForEach() now that I saw and really liked the look of ISystem code (with some exceptions). But could you please share some possible ways to make it easier to crate and run jobs without something analogous to ForEach? I just can't imagine any right now.

 

Have you tried IJobEntity?
It can't get any less verbose than that.

 

I know, exactly. That's why I'm saying I can't imagine it getting any smaller than that without something like Entities.ForEach(). Or what I found now (I guess I skipped that version) Job.WithCode();

The "verbose" example I linked:
https://github.com/Unity-Technologi...Scripts/Gameplay/Race/PlayerProgressSystem.cs

Only way It could get smaller is something like this:

Code (CSharp):

1.         Job.WithCode(() =>
2.         {
3.             for (int i = 0; i < randomNumbers.Length; i++)
4.             {
5.                 randomNumbers[i] = randomGen.NextFloat();
6.             }
7.         }).Schedule();

But maybe somehow with a different syntax?

Am I too lazy?

In the end I actually decided to go with ISystem and IJobEntity/IJobChunk to keep things clean and consistent. But curious if there are plans to trim the boiler plate code a bit further.

 

Does foreach SystemAPI.Query and IJobEntity.Run() compile down to pretty much the same thing given they're both main thread code or does the job version incurr more overhead?
I'd like to write job code as opposed to foreach for this very reason of easily refactoring down the track.

 

At built time they become equivalent, in editor jobs with safety checks on will have a minor extra cost to check that you set up the job correctly :3

Also correct there's likely no *code* that could be smaller than IJobEntity, but that doesn't mean there's no other ways for us to make it easier to write multi-threaded code, a key factor in DOD, is the ability to change your design based on growing needs :3

 

Do not use ChatGPT for Unity DOTS related subject. It will not have reliable answered, since sampling data is so small. And tech of DOTS evolves faster than GPT chat can keep up at this point.