Those are two quite big differences :). I also wouldn’t say that OS schedulers are trying to optimize for the same thread-to-core ratios or same degree of throughput. There’s a reason that primitives such as goroutines exist.
-
-
Replying to @jhaberstro
TBH I think Go would have been just fine, and maybe better off, if goroutines were implemented as 1:1 OS threads.
1 reply 0 retweets 2 likes -
Replying to @pcwalton
I'd be interested to hear why. The rise of APIs that let you spawn short lived tasks onto thread pools seem to indicate the contrary. After that, it is just a question of which programming model is easiest to use to interface with these thread pools and how do you make that fast.
1 reply 0 retweets 0 likes -
Replying to @jhaberstro @pcwalton
goroutines seem better than most (in my limited understanding of Go). They seem to allow you to "just" write imperative, blocking code without giving up a lot of the benefits of asynchronicity.
1 reply 0 retweets 0 likes -
Replying to @jhaberstro
M:N threading hasn’t worked out so well in other OS’s. For example, Linux tried that decades ago with NGPT and gave up. Windows is deprecating fibers despite having a superior implementation to that of Go.
4 replies 2 retweets 3 likes -
Replying to @pcwalton @jhaberstro
The biggest practical problem is that you give up all compatibility with existing code when you go M:N (really: when you go small stacks). This means that every time you want to call an OS library you have to switch to a big stack.
1 reply 0 retweets 4 likes -
Replying to @pcwalton @jhaberstro
Windows and macOS have no stable kernel API outside the system API, so that means every syscall needs a switch to a big stack. This huge cost usually outweighs all the gains of M:N. It killed M:N threading as a general solution in Rust.
1 reply 0 retweets 4 likes -
Replying to @pcwalton @jhaberstro
M:N threading is still useful for CPU-bound task-parallel kernels. For that we have Rayon/GCD/etc, on in opt-in basis. Note that these frameworks are stackless (so OS library incompatibility isn’t a problem) and don’t try to multiplex I/O.
1 reply 0 retweets 1 like -
Replying to @pcwalton @jhaberstro
Async/await is likewise stackless and avoids the OS library incompatibility problem. If you want M:N, I think a better solution is reviving something like Paul Turner’s switchto patch or Windows fibers. http://pdxplumbers.osuosl.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf …
1 reply 0 retweets 4 likes -
Replying to @pcwalton @jhaberstro
This adds the primitive necessary for M:N into the kernel (a user-level “switch to thread X” syscall), avoiding the OS incompatibility problem. Windows already has this via fibers (which is why I think it’s a better solution than Go’s).
1 reply 0 retweets 0 likes
But Windows UMS fibers are deprecated, despite being the technically-best solution around. And the Linux switchto patch stalled out in 2013. Kernel developers seem to have soured on the concept of M:N in general. /end
-
-
Replying to @pcwalton
Thanks for the explaining your thoughts. I can see how the M:N threads with their own stacks can be a compatibility nightmare. In a world where one is designing a novel HW architecture, everything would likely need to be rewritten anyways so compatibility matters less so! :-P
1 reply 0 retweets 0 likes -
Replying to @jhaberstro @pcwalton
Sorry for butting in, I happened to see this discussion! I'd be super grateful and interested if you happen to have any blog posts, research papers or presentations in mind that would provide a good overview about the current state and recent history of this 1:1 vs m:n stuff.
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.