Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

I haven’t read through the code in detail but I can tell you “sub-nanosecond overhead” is misleading and marketing fluff. On first look, the measure seems to be some convoluted “time per thing” where the number of threads is far far smaller than the number of “thing”s

Re: Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

#5

Post by jd3 » Tue, Aug 13, 2024, 1:00 AM UTC

shoggouth wrote: post #3

List of limitations of the project: https://github.com/judofyr/spice?tab=readme-ov-file#limitati...

Want to state off the bat this this project is awesome and huge kudos to the author for spending their time, attention, and energy 1) working diligently to get this working at all and 2) sharing it with the broader HN community, who are generally known to by hyper-critical to a pedantic degree and/or overly pessimistic (cough the initial Docker project Show HN thread cough)

I also really appreciate that the author recognizes the limits of their own project, which preemptively addresses most of the usual snark.

> Lack of tests: Spice contains a lot of gnarly concurrent code, but has zero testing coverage. This would have be improved before Spice can be responsibly used for critical tasks.

Testing correctness of execution for critical tasks is one thing, but I would expect a library which implements "gnarly concurrent code" to at least have regression tests — what guarantee is there to an end-user that functionality which exists in a working state today might not break tomorrow due to a subtle yet nefarious regression?

sqlite has 590 times as much test code and test scripts as it does raw c source code [0]; this fact, along with its stability and portability, is one of the numerous reasons why it has proliferated to become the defacto embedded database used across the planet. While we're comparing apples to oranges in this contrived example, the general point still stands — regression tests beget stability and confidence in a project.

In epics where I work, if we _must_ defer baseline regression tests, we usually create a follow-up ticket inside of the same epic to at least write them before feature/epic launch, usually.

[0]: https://www.sqlite.org/testing.html

Re: Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

#6

Post by pverghese » Tue, Aug 13, 2024, 1:02 AM UTC

jd3 wrote: post #5

shoggouth wrote: post #3

List of limitations of the project: https://github.com/judofyr/spice?tab=readme-ov-file#limitati...

Want to state off the bat this this project is awesome and huge kudos to the author for spending their time, attention, and energy 1) working diligently to get this working at all and 2) sharing it with the broader HN community, who are generally known to by hyper-critical to a pedantic degree and/or overly pessimistic ( cough the initial Docker project Show HN thread cough ) I also really appreciate that the author…

You are welcome to add it. This is a proof of concept

Re: Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

#7

Post by mananaysiempre » Tue, Aug 13, 2024, 1:06 AM UTC

nirushiv wrote: post #4

I haven’t read through the code in detail but I can tell you “sub-nanosecond overhead” is misleading and marketing fluff. On first look, the measure seems to be some convoluted “time per thing” where the number of threads is far far smaller than the number of “thing”s

That is the ecological niche of Rayon (cited) as well, isn’t it? You need to process a lot of things (thousands to millions), you want to parallelize that processing as much as possible (couple dozen of cores tops), you want to not get killed by scheduling overhead. So you account for the per-thing overhead.

Re: Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

#8

Post by jd3 » Tue, Aug 13, 2024, 1:07 AM UTC

pverghese wrote: post #6

jd3 wrote: post #5

Earlier quoted context omitted.

Want to state off the bat this this project is awesome and huge kudos to the author for spending their time, attention, and energy 1) working diligently to get this working at all and 2) sharing it with the broader HN community, who are generally known to by hyper-critical to a pedantic degree and/or overly pessimistic ( cough the initial Docker project Show HN thread cough ) I also really appreciate that the author…

You are welcome to add it. This is a proof of concept

> Spice is primarily a research project. Read along to learn more about it, but if you're considering using it in production you should be aware of its many limitations.

Ah, I missed that upon first read. In that case, that caveat/limitation is definitely justified.

Re: Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

#9

Post by raggi » Tue, Aug 13, 2024, 1:10 AM UTC

cooperative scheduling is the basis for so many patterns with great metrics :)

Re: Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig

#10

Post by dsp_person » Tue, Aug 13, 2024, 1:15 AM UTC

jd3 wrote: post #5

shoggouth wrote: post #3

List of limitations of the project: https://github.com/judofyr/spice?tab=readme-ov-file#limitati...

Want to state off the bat this this project is awesome and huge kudos to the author for spending their time, attention, and energy 1) working diligently to get this working at all and 2) sharing it with the broader HN community, who are generally known to by hyper-critical to a pedantic degree and/or overly pessimistic ( cough the initial Docker project Show HN thread cough ) I also really appreciate that the author…

> sharing it with the broader HN community

Note that I posted this, but I am not the author