Using tasks without GC?

[Chris Katko]

Thanks everyone, looks like i'll have to benchmark myself (which 
is fine) but I'm always afraid because I know "proper 
benchmarking is hard. (TM)"

Feel free to throw any other side advice in. I'm looking to get a 
broad perspective on this.

Straight up shutting off the garbage collector in exchange for 
memory is an interesting concept. But I wonder how quickly it 
will get eaten up. ALSO, if I do shut it off, when i turn it on 
is it going to take much longer? Does the GC take linear / 
quadratically more time based on the N of "items need to be 
freed"?

The thing is, I'm looking to parallelize a dedicated server for 
running MASSIVE numbers of objects (10000's or 100000's) at high 
tick rate. Worse, for my particular "game mode", the "rounds" can 
last hours. So while a slow crawl of RAM is okay, it won't be 
okay if it hits 30 GB in an hour. So that's going to be another 
"it works IF it works [in our particular game/application]" as 
opposed to "this definitely will/won't work". That's more 
"benchmarking and see" scenarios, which I'm trying to avoid as 
much as possible. You normally don't want to willfully START a 
project with a design where the only way to know if it works... 
is to bench.

There's also an option of periodically firing off (without ending 
the game) say, once every hour and tell everyone to just "live 
with it" because it's (I HOPE!) not going to be a 15/30/60 second 
delay. In my particular application, that still wouldn't be that 
disruptive. (Unless turning GC off hits max ram every couple 
minutes. Then again nobody is going to be okay with that.)

On Saturday, 4 January 2020 at 11:30:53 UTC, dwdv wrote:
>> Creates a Task on the GC heap that calls an alias.
>
> If possible, there's also scopedTask, which allocates on the 
> stack: https://dlang.org/phobos/std_parallelism.html#.scopedTask
>
>> So my question is: Has anyone done any analysis over how 
>> "dangerous" it is to use GC'd tasks for _small_ tasks (in 
>> terms of milliseconds)?
>
> Nothing major, but 
> https://github.com/mratsim/weave/tree/master/benchmarks/fibonacci puts quite a bit of pressure on various implementations. You might want to profile ./pfib 40:
>
> import std;
>
> ulong fib(uint n) {
>     if (n < 2) return n;
>
>     auto x = scopedTask!fib(n-1); // vs. Task!fib(n-1);
>     taskPool.put(x);
>     auto y = fib(n-2);
>     return x.yieldForce + y; // {yield,spin,work}Force
> }
>
> void main(string[] args) {
>     enforce(args.length == 2, "Usage: fib <n-th fibonacci 
> number requested>");
>     auto n = args[1].to!uint;
>     // defaultPoolThreads(totalCPUs);
>     writefln!"fib(%d) = %d"(n, fib(n));
> }
>
> At least D isn't locking up beyond 12 tasks; looking at you, 
> stdlib-nim. :)