6 ms·
Half a year ago: "I wouldn't be surprised to see Rust at least abandon M:N soon though once they start really optimizing performance." With Rust I'm sure they'
by bsdetector 13y ago
Half a year ago: "I wouldn't be surprised to see Rust at least abandon M:N soon though once they start really optimizing performance."
With Rust I'm sure they'll drop M:N, if not now then eventually, like essentially everybody else in CS history. It seems great on a superficial level, but when you really start caring about performance and latency and fairness it's the pits.
My question is when Go will drop it. Imagine how easy it would be to have C call Go code if Go didn't have its own threading and segmented stacks; simply push the arguments and call/jmp. Maybe reference a few objects. None of that allocating a stack, locking a goroutine to a thread, stealing work to another thread, etc. You could even embed Go into a C program instead of having to do it the other way around, and you wouldn't have the problem of adapting existing programs or rewriting them in Go.
But I bet Go will continue with M:N and segmented stacks for a decade because it seems like they actually want it to be difficult to interface with anything else. Like Pure Java, they want you to rewrite everything in Go instead of just using some existing library.
- jeltz 13y agoErlang has been using M:N very successfully and managed to have good latency and fairness while sacrificing performance. The hard part about M:N is doing it without a VM. EDIT: To clarify I believe you are too harsh about M:N, and that Erlang is excellent proof that M:N has its use cases.
- girvo 13y agoErlang and it's BEAM VM are so different to other mainstream languages, that I'm not sure that proves that much...
- jeltz 13y agoIt proves that there are cases where M:N scheduling is the right choice. But it does not prove if it is the right choice for language implementation X (where X in this case is Rust).
- thirsteh 13y agoBeing different from the mainstream isn't a bad thing. For the sake of argument, Rust is very different from the mainstream too.
- scarboy 13y agoGo is moving to contiguous stacks in 1.3.
- sanxiyn 13y agoHaskell people seem happy with their M:N scheduler. Is something Haskell-specific helping them? https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Schedul...
- wtracy 13y agoPure functions allow the runtime to make an entire set of assumptions that aren't safe with other languages.
- thirsteh 13y agoGiven that you 'forkIO' functions in the IO monad, i.e. impure functions, what do you mean by that? 'forkIO' in Haskell is essentially the same as dispatching a green thread in any other language, e.g. the same as 'go' in Go. Haskell/GHC's threads are primarily a concurrency construct, not a parallelism one. You 'forkIO' a bunch of impure functions and communicate between them using channels, STM, etc., exactly the same as in other languages. For parallelism in pure functions there are much better tools--par seq, parallel strategies, repa, Data Parallel Haskell, etc.
- wtracy 13y agoI didn't realize that Haskell supported M:N threading in IO contexts. In that case, I don't have an answer to the original question.
- deleted 13y ago[deleted]
- qznc 13y agoI consider 64bit machines the final nail in the coffin of N:M for next decade. Since you can spawn millions of kernel threads the argument of easier-than-callbacks in favor of N:M disappears.
- mcguire 13y agoIn practice, though, I've never seen a situation with a single server running more than a thousand kernel threads end well. My experience may be limited, though.
- jlouis 13y agoThe problem with kernel threads are they require kernel context. This is usually at least 4-8 kilobytes of memory. Which is about 8-16 times as much as an Erlang process...