Reading a bit about Go's goroutine scheduler. Sounds like it tries to solve many of the same problems a GPU's shader core does. # threads ("goroutines") >> # of simds ("OS threads"), fast switching, small stacks, minimal fairness, turn blocking calls into async calls.
-
-
Replying to @jhaberstro
Well, most of those apply to the OS scheduler too, except for minimal fairness and small stacks (though you can have small stacks using native OS threads too). Really I think Cilk/Rayon are more analogous to GPU schedulers.
1 reply 0 retweets 1 like -
Replying to @pcwalton
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.
1 reply 0 retweets 0 likes -
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
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 …
-
-
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 -
Replying to @pcwalton @jhaberstro
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
1 reply 0 retweets 1 like - 3 more replies
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.