3 ms·
> I can tell you “sub-nanosecond overhead” is misleading and marketing fluff If and only if (1-thread Spice - non-parallelized baseline) > 1ns, which their te
by x-complexity 2y ago
> I can tell you “sub-nanosecond overhead” is misleading and marketing fluff
If and only if (1-thread Spice - non-parallelized baseline) > 1ns, which their tests back up their claims.
https://github.com/judofyr/spice/tree/main/bench https://github.com/judofyr/spice/tree/main/bench
- adrian_b 2y agoAt your link it also says: "Spice shows subpar scalability: The speed-up of using 16 threads was merely ~11x" If that is true, then "Spice" is suitable only for small tasks, which can be completed at most in milliseconds, which can benefit from its low overhead, while for any bigger tasks something better must be used.
- judofyr 2y agoAuthor here. I’d maybe phrase it as “Spice is not optimal” instead of “Spice is not suited for”, but yes, that’s the conclusion for this benchmark. I’m hoping/assuming that for a more typical case (more CPU work being done) Spice will scale better, but I haven’t done the benchmark yet.
- Veedrac 2y agoIMO this is the least convincing part of the benchmark though, since it's uninterpretable without an optimal baseline. You don't know how much of this is because of Spice and how much is because of how the task scales. (This is acknowledged as future work.)