ComponentSystem vs JobComponentSystem

I'm bit confused on when to use one over the other. What are some use cases where I would use ComponentSystem but not JobComponentSystem and vice versa? Wouldn't it be more performant to execute most systems as jobs?

For example, in the PURE ECS sample why are the RemoveDeadSystem, ShotDamageSystem, EnemyShootSystem, and EnemyRemovalSystem... JobComponentSystems while the others are ordinary ComponentSystems?

 

JobComponentSystem is the preferred way for stuff that CAN be jobified. not everything (currently) can.

currently you have to be on the main thread to call existing Unity APIs or use reference types, and that will remain.

eventually there will be a jobified API for everything.

 

I see! So eventually JobComponentSystems will be the new standard and everything would essentially be multithreaded.

What do you mean by "use reference types"? sorry I'm a bit new

 

In .NET there are 2 fundamental object types, Value types and Reference types.

All structs are value types (along with the fundamental numeric types and stuff like enums) and are handled directly on the stack or stored directly in memory as part of another object. Value types don't need to be garbage collected, as they aren't allocated on the heap themselves (they may be part of an object that IS allocated on the heap, or contain a reference to an object on the heap, see below).

All classes (and strings) are reference types (including ALL Unity.Object-derived classes, such as MonoBehaviour and ScriptableObject, etc). They are instantiated on the heap and handled by reference pointers. They are also candidates for garbage collection, and can contain value types (directly in their allocated memory block) or references to other reference type instances.

 

Thank you recursive and M_R

 

Asking for clarification:
So ComponentSystems are on the main thread and can be thought of as say a monobehaviour update (i.e. called once a frame and allow access to UnityEngine dlls). You would [Inject] ComponentData arrays that you would iterate over if needed.

A JobComponentSystem is almost the same thing except it jobifies the end result of the (main thread) Update for multithreading?

 

Correct. Both have the same injection capabilities.

The JobComponent System simply takes in a JobHandle representing it's dependencies and produces a JobHandle representing all of it's jobs (there are functions to combine JobHandles scheduling them). If there's no work to be done (early out) a JobComponentSystem can simply return the dependency JobHandle it was given instead of scheduling anything.

A Barrier System (such as EndFrameBarrier and TransformInputBarrier) doesn't do any real processing of it's own, but acts as a sync point for executing EntityCommandBuffers, which are a way of batching entity changes (create/destroy entity, add/set/remove component) instead of executing them immediately (which can be slower or have issues with one thread destroying an entity or component while another thread is still trying to use it).

 

Thanks that really clears things up for me. I dont come from a ECS background so some of the naming conventions and rules between ECS and the Job system kinda confused me. The way I interpenetrated Unity it seemed as if they were one in the same or extremely similar so I wasnt exactly sure which rules applied where or why. I think this really clears things up for me.

 

JobComponentSystem's OnUpdate is also execute on main thread? can use classic Unity API?
@recursive

 

All systems executes on main thread, CS and JCS both, difference only in automatic dependencies. Only Jobs can run in different thread (but scheduled only on main thread)

 

thx

 

I wouldn't go that far. Not everything can or should be jobified. Sometimes it's just simpler (and maybe even faster) to do a small thing on the main thread instead of spawning a job for this and having to manage the complexity and cognitive overhead of stuff happening in multiple threads.

ComponentSystem

will probably stay relevant even when most of Unity API is integrated with ECS as you cannot parallelize everything - some things intrinsically need to happen one thing at a time.

 

JCS automatic dependencies.
if schedule a job, in JCS's OnUpdate, and return its handle:

Code (CSharp):

1. protected override JobHandle OnUpdate(JobHandle inputDeps)
2. {
3.     return job.Schedule(inputDeps);
4. }

In the JCS's next OnUpdate, has the job (last scheduled in this JCS) completed?

 

Yes, because there is code in the

JobComponentSystem

base class which keeps track of the jobs that were scheduled last frame and will wait for them to finish before running the

OnUpdate

method again. This is to avoid "infinite dependency chains", at least so it reads in the code.

 

thx

 

I cant get JobComponentSystem to import, any ideas?

 

The JobComponentSystem can do that too. We'll probably still be able to inherit from the ComponentSystem for a long time since I don't see it going before ECS 1.0.0 and once it's part of the API deprecating it will take a long time, but essentially: yes, you can do the same thing with JobComponentSystem as with ComponentSystem but more. The added cost is negligible so I say shoot for ease of use: always use JobComponentSystem.

 

Both deprecated. The only right way which you should use for everything - SystemBase.

 

The SystemBase OnUpdate does not give you an inputDependency however. Are you sure they are deprecated?

 

Yes, they deprecated. SystemBase has Dependency property. Moreover Entities.ForEach\Job.WithCode handles this automatically as ILPP will compile it to IJobChunk and will handle Dependency for you.

 

So does it mean the most preferable replacement for ComponentSystem.PostUpdateCommands() for now is to use EntityCommandBuffer in SystemBase?

 

Yes. If you need the changes to be applied directly after your job runs, then you should create an EntityCommandBuffer in the system's update method and play it back with the systems entity manager. This will create an additional sync point. If you don't want the additional sync point and you can delay the playback, then you should get the EntityCommandBuffer from one of the existing system (e.g. EndSimulationEntityCommandBufferSystem).

 

Thank you, that's quite helpful