Comment by pcwalton | Hacker News Reader

Comment by pcwalton | Hacker News Reader

Copying my message on Reddit here:

I profiled this and found that the vast majority of the time was spent allocating stack segments. So the basic problem is that this benchmark is simply tuned for segmented stacks. An implementation that does not use segmented stacks will do worse on this benchmark. We've rejected segmented stacks because they don't perform well in the real world (and hurt many other benchmarks, including most of the shootout), but they do make this one particular program fast.

The debate on M:N versus 1:1 threading seems irrelevant to this benchmark. In 1:1 mode we will also allocate a lot of stack space.

Channel performance is mostly irrelevant to this benchmark.

It's hard to say what the more "idiomatic" Rust version of this program would be, because this program doesn't do anything. The fastest version of this program would be println((N + 1).to_str()). :) An implementation based on libdispatch/TBB-style blocks might be faster, but it would look quite a bit different from this benchmark.

> The fastest version of this program would be println((N + 1).to_str()).

Chinese Whispers basically represents a DSP system: each agent is "plugged into" the next one in the chain, and a signal has to propagate through the chain, being modified by each agent in an arbitrary fashion. The fact that they all just +1 the signal is irrelevant; each one could output whatever it likes. The only assumption is that the work each agent performs is O(1).

In that case the fastest way to do it in Rust would be to use an iterator.

Oh, sorry, forgot to include: 1. Only the agent that outputs a signal knows where it should be propagated[1]. (The decision of propagation is part of the each agent's internal state.) and 2. Each agent may be running on a different system than the next, and may propagate the signal using a network call instead of an internal message-pass-and-yield.

Chinese Whispers is inherently a test of message passing in a distributed system. An iterator-based design (e.g. a "controller" agent that pulls in the state after each call and sends it to the next agent, forcing a hub-and-spoke series of RPC calls) will

• tend to introduce highly-degraded performance, since you've doubled the number of messages being sent;

• force a synchronous wait in the controller (it can't do anything until it's talked to everyone, whereas with the asynchronous propagation, all it has to do is "kick it off");

• possibly just not work at all--if, for example, an agent propagates into a private network that only accepts messages from that agent, not from your controller.

---

[1] The Chinese Whispers problem includes a set-up phase, where the controller instantiates the agents and wires them to one-another. This is just for the sake of convenience, though; the controller should not be assumed to have knowledge of how the agents are interconnected once it has the ring established.

This particular benchmark is especially poor if that's what it's trying to test then, because this benchmark is completely gated on task/goroutine spawning performance and message passing barely even shows up in the profile in both Rust and Go.

Yes a "fairer" evaluation of "chinese whispers" would first setup the whole thing, then start the test and send a message into the ring.

  > including most of the shootout

I feel like this comment makes it sound like we care more about the shootout benchmarks than we actually do.

Since you might be reading this, why does rust do this channel/port thing instead of just channels? Is that written down somewhere? Does it have to do with the type system or the ownership sematics?

Do you know if ghc uses segmented stacks ?

I'm wondering, because I implemented chinese whispers in haskell and it seems to be on par with go.

Yeah, but they're recent (segmented stacks).

How stacks work in something like STG are very different from a language like Rust or C.

IIRC I've read something that said Go was going to move away from segmented stacks in future versions. I have no idea about the progress.

Reply on news.ycombinator.com