Feedback Request - .ScheduleAuto(dep,chunkThreshold)

When ScheduleParallel() systems have only a few entities to process they can take significantly longer* (at least on my 3900X) to execute than the Schedule corollaries. I believe it would be desirable to have the job switch dynamically, possibly based on a user-defined chunk count threshold that the job is executing over - calling Schedule instead of ScheduleParallel if the work is below said threshold.

At the moment, especially with lambdas (exacerbated by needing to combining job handles & the

Every Entities.ForEach statement needs to end with a .Schedule(), .ScheduleParallel() or .Run() invocation.

compile check) this is fairly verbose, even when extracting the body of work out into a struct. I would really appreciate it if something like ScheduleAuto, default behaviour of ScheduleParallel when passed a chunk threshold or else similar functionality could be considered.

*In my tests (entities 0.9.1, build attached to profiler) with low entity counts (<100), main thread execution time is ~5x (which I want to stress is reasonable, given splitting the work across e.g. 22 workers) faster using Schedule() than ScheduleParallel(). My systems need to scale well from 1 to many thousands of entities so at the moment I'm pursuing the manual/verbose way.

 

Some kind of intelligent system that tests itself if it runs faster with Run/Schedule/ScheduleParallel would be nice in the future.

 

I think that could be tricky to implement. I also like being able to reason about whether it's going wide or not, rather than guess. Though I'm not averse the scheduler determining the fastest path automatically - especially if the logic/conditions are clear.

 

I think when ECS gets more flexible it won't be as tricky.
Self-tests don't have to happen at runtime. When we can get detailed reports how systems are performing with different load and decide with that if we Run/Schedule/ScheduleParallel there won't be much magic going on.

At least not more than with ScheduleAuto. My problem with ScheduleAuto is were it draws the line. Does it use Run with <10 entities? 100? Schedule with 100-1000 and ScheduleParallel with more?
I think there's no straight answer and it has the be measured what's actually the best form for the system and data.

What's preventing us from doing that right now is that we can't switch a system from Schedule/Parallel to Run without code changes. When we have structural changes Schedule needs an ECB which Run doesn't like having.
So to use Run without code changes on our side we would need a code conversion from ECB to EntityManager calls on main thread.
TBH I think that's feasible with the way SystemBase code-gen is working now and would give it the needed flexibility.

 

I'm affraid such automated/intelligent system we could potentialy result in all/most systems running on the main thread.
Ok that system runs faster without schedule but it would be better to do the job on another thread and continue working something else on the main thread.

 

Totally agree with @Joachim_Ante. Automatic switching between Schedule and Run would not only produce unexpected sync points (because Run should complete all the dependencies), but can also introduce ordering issues, that will be hard to debug.

 

Agree with JA about sync points (bit unclear about ordering issues you mention though). When optimisations land if the cost of e.g. ScheduleParallel drops by a factor of 20-100x then worrying about this becomes largely inconsequential. However if it ends up more like a 2-5x improvement, for systems that need to scale well doing it manually atm is not only often worth the sync but also verbose to write. Obviously I'm hoping for the former. If it's more like the latter I'd still like a more succinct way of achieving it.