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
My friend and former colleague
@BSmaalders has some hard won insight in this area.1 reply 0 retweets 0 likes -
Sun used M:N threads initially (circa early 90s). Solaris didn't and doesn't support pagable kernel thread stacks, as a result one or two 4k pages of non-pagable memory was needed per thread. On small memory (<32M) machines this limited thread count too much. 1/
1 reply 1 retweet 1 like -
Replying to @BSmaalders @binarycrusader and
A variety of problems ensued, many of them not immediately noticed due to lack of really good multi-threaded test suites. In the end, correct Posix signal behavior w/ M:N threading turned out to be extremely difficult to implement in all cases.
2 replies 0 retweets 0 likes
Yeah, Go doesn’t really even try to expose signals in its runtime. (Nor does it expose fork.)
-
-
Signals and threads combine in interesting ways, particularly because signals interfaces combine synchronous notifications (e.g. SEGV, BUS, FPE, etc) with externally generated signals (QUIT, INT, etc); for threads these are fundamentally different things.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.