add schobi scheduler

[Kamayuq]

I would like to add the schobi scheduler to your comparison I implemented 3 flavors: sequential baseline, fork join and group shared. The latter could be considered a cheat, but I think we can make an exception if it is faster than the sequential baseline. The schedulers are allowed to be implemented using their idiomatic language as well. And yes it looks like GPU code for a reason.

Anyways here are the numbers from an 9175F and 16core/32MB per core sliced 16chiplet CPU with terrible atomic latency. Any more normal CPU should have different and probably drastically better scaling:

benchmark	sequential	schobi group-shared	schobi fork-join	libfork	TooManyCooks	citor	TBB	cppcoro	coros	taskflow
fib(35)	1.00x	9.90x	0.04x	1.04x	0.57x	0.43x	0.21x	0.15x	0.20x	0.18x
skynet	1.00x	11.71x	0.33x	1.38x	0.96x	0.70x	0.48x	0.28x	0.39x	0.17x
nqueens(14)	1.00x	12.91x	5.07x	12.01x	10.39x	9.85x	8.28x	5.50x	2.18x	5.82x
matmul(2048)	1.00x	12.02x	4.70x	4.73x	4.45x	3.95x	4.25x	4.20x	4.39x	3.96x
geometric mean	1.00x	11.58x	0.75x	3.00x	2.24x	1.85x	1.37x	0.99x	0.93x	0.92x

*sequential is completely single threaded without scheduler overhead
**the other rows are speedup compared to optimized sequential implementation 16x is the theoretical maximal achievable limit on this 16core CPU numbers lower than 1x are actually slower than the baseline.

The deep fork join corner of the problem space is something schobi does not compete in and does not want to compete in by choice.

[Kamayuq]

I added some other group-shared implementations and TBB is such a sleeper sometimes:

benchmark	sequential	schobi fork-join	schobi group-shared	libfork fork-join	libfork group-shared	TBB fork-join	TBB group-shared
fib(35)	1.00x	0.04x	9.16x	1.10x	12.32x	0.21x	12.58x
skynet	1.00x	0.34x	12.45x	1.43x	13.35x	0.49x	12.10x
nqueens(14)	1.00x	5.00x	12.76x	12.33x	12.73x	8.14x	13.01x
matmul(2048)	1.00x	4.69x	10.98x	4.59x	9.98x	4.13x	9.73x
geometric mean	1.00x	0.75x	11.24x	3.07x	12.02x	1.36x	11.78x

I kinda still like the C flavor better, but I am heavily biased.

[tzcnt]

Thanks for the contribution. I'll take some time to look at this and get it integrated. I'm interested in your single-task latency and single-parallel-group benchmark too. Those seem like useful representations of the way these things are often used.

[Kamayuq]

Not only that if we convert a few more we might gain some valuable insight as sharing data is often “invisible” overhead in the profiler and every additional experiment is a good representation of what a slightly different memory access pattern can cost or gain you on a given machine. I really like the collection of hardware you have running.