Live data from Hacker News

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

github.com

51–56 of 56 posts

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

#51

I'm not terribly familiar with this space, but I do like the concurrency model presented here. I think the README here is very well written, and I have a good idea of what's going on just from reading it, but there are a few areas where I'm left scratching my head. Thankfully the code is fairly easy to read.

One thing I noticed was that when I build in Debug mode `zig build`, I got:

    Baseline,3.92809172
    Spice 1 thread,19.1012624
When I built with ReleaseSafe mode `zig build --release=safe`, I got:

    Baseline,3.264224280000001
    Spice 1 thread,3.78043278
So Spice does have a notable degradation of performance if not built for release. The baseline implementation does not share the same degree of degradation when built with the Debug zig build mode.

(zig 0.13.0)

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

#52
post #25

Earlier quoted context omitted.

It's not "lying" to use the words most likely to correctly get your point across to your target audience. Maybe they could have communicated better (for a seemingly dead project, IMO they put enough time in regardless), but it's not lying. > Anyone making claims about performance should know the difference. They probably do know the difference. Knowing the difference isn't the thing you're quibbling with. > If someon…

The whole point of overhead is that it is a base constant on top of whatever you do. The whole point of overhead is to eventually be amortized in some way. When someone asks what the overhead is, it is a lie to try to factor amortization in because it's implied that it will be done somewhere anyway.

I think we're maybe talking past each other with definitions.

I think something is a lie when somebody intentionally tries to mislead (even when communicating "facts" if the intent is to maliciously shape the recipient mind). I think when they intentionally try to convey the "right" ideas (as I think this author is doing -- again, using words the way you think most of your peers use them is usually a good thing), that's not a lie. There are gray areas in between. I don't think this is a gray area, except insofar as I don't know all the facts perfectly.

You still seem to disagree with me though. I'd really like to understand why. I have a couple theories, which I'll list, but I'm interested in any insights you have:

1. You disagree with my description of what "lying" is.

2. You think the author is less deserving of trust than I do (since they seem to be profiting almost nothing other than a tiny bit of publicity, since they did outline in their README exactly what they meant, with photos, and since the title didn't stoop to clickbait, my default position is that they likely weren't too malicious, but you might have different priors and might also disagree with my opinions of those conflicts of interest).

> the whole point of overhead ...

That's perhaps the last pertinent thing we disagree about. I'll throw out my opinion, and I sincerely want to know your thoughts on the matter:

An extremely commonplace occurrence is that something is slow and you want to speed it up (measuring perceived latency). If you can magically do that by adding parallelism then it's a good day at work. Unfortunately, parallelism can easily add "overhead" -- parallelizing small or finely grained problems usually increases wall-clock timing, usually substantially.

In that mode of operation, the whole problem you're trying to solve is reducing a certain latency measurement, making it clear from context what "overhead" means. Other definitions don't even enter into the equation.

Zooming out a bit, I've heard that phrasing a ton of times in many different companies. Sure, it's better if people know to speak more precisely (and I think we're in agreement that a few more performance characteristics would be nice to know here), but it's hard for me to imagine a world were my default perception of somebody is that they're lying when they're using the exact same words and meanings as scores of other good engineers. _Maybe_ they are, but that's by no means my default assumption.

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

#53

Earlier quoted context omitted.

Thanks for the answer, this part is particularly interesting indeed: > Despite this being an utterly useless program we've learnt something that we can apply later on: Our smallest unit of work should probably be a bit bigger than ~7 ns before we reach for Rayon. That's a very interesting project. The big limitation I see with the current approach is that the usability of the library is much worth than what Rayon off…

Too late to edit so I'll put it here: > the usability of the library is much worse than what Rayon I'm a little bit ashamed to see that this fairly upvoted comment of mine has such an stupid English mistake in it…

Don't worry about it: my brain "autofilled" wor.. as worse.

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

#54
post #39
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…

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) So you made me dig up the announcement, and contrary to how you recall, it is almost universally positive. https://news.ycombinator.com/item?id=5408002

I meant to say dropbox, not docker

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

#55
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…

> (cough the initial Docker project Show HN thread cough) Docker was largely met with enthusiasm here when it was launched. I believe you must refer to how Dropbox was received — famously negatively, initially.

Yes, I meant to say dropbox

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

#56
post #52

Earlier quoted context omitted.

The whole point of overhead is that it is a base constant on top of whatever you do. The whole point of overhead is to eventually be amortized in some way. When someone asks what the overhead is, it is a lie to try to factor amortization in because it's implied that it will be done somewhere anyway.

I think we're maybe talking past each other with definitions. I think something is a lie when somebody intentionally tries to mislead (even when communicating "facts" if the intent is to maliciously shape the recipient mind). I think when they intentionally try to convey the "right" ideas (as I think this author is doing -- again, using words the way you think most of your peers use them is usually a good thing), tha…

This seems like a lot of writing that has nothing to do with the topic. If someone wants to know the overhead of something and you tell them the overhead divided by an arbitrary number already, that's lying.
Post reply on HN