On Sat, Jan 04, 2020 at 12:51:15AM +0000, Chris Katko via Digitalmars-d-learn 
> I'm looking through D's parallelism module and the docs state,
> up-front:
>  >Creates a Task on the GC heap that calls an alias.
> The modern, scalable way to make a parallel game engine uses tasks.
> (as opposed to functional decomposition where 1 thread is networking 1
> thread is physics, etc.) That requires making LOTS of tasks (_per
> frame_!) and dispatching them. And a 60 FPS frametime is... 16 ms or
> less.

I don't know the inner workings of std.parallelism well enough to answer
your question directly, but couldn't you just spawn a bunch of workers
that can be assigned tasks? So you only allocate up-front when first
spawning the workers, but during the main loop you have a fixed number
of workers that can receive and execute tasks.  So you don't have to
allocate at all after the initial up-front allocation.

Generally, doing a lot of small GC allocations is bad for performance. I
would avoid doing that, and use a fixed number of workers that you
create, say at the beginning of every level or something, and thereafter
you never deallocate them, just leave them idle if there are no tasks,
otherwise have some dispatcher to assign tasks to them.


Latin's a dead language, as dead as can be; it killed off all the Romans, and 
now it's killing me! -- Schoolboy

Reply via email to