5 ms·
That's very sad for Rust, because Go's goroutines are amazingly awesome.
by NateDad 11y ago
That's very sad for Rust, because Go's goroutines are amazingly awesome.
- pcwalton 11y agoI firmly believe that moving away from M:N threading was the right decision for Rust. Even if nothing else, the fact that Rust FFI performance is thousands of times faster than cgo alone justifies the decision. There are numerous other reasons (fairness, I/O performance, performance of synchronization primitives, implementation complexity) why just using the OS scheduling is superior for a systems language. The primary benefit of M:N scheduling—fast thread spawning due to small initial stack sizes—requires GC, which Rust doesn't have, and arguably has little to do with M:N scheduling in the first place, given that thread stacks are configurable in the syscall.
- NateDad 11y agoI believe you know what you're talking about, and so are right about what's best (or really, even possible) in rust, but I can still be sad that there's not some magic way to have my cake and eat it too.
- SamReidHughes 11y agoHow does having small initial stack sizes give you fast thread spawning?
- pcwalton 11y agoBecause you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
- SamReidHughes 11y agoBut you can allocate large stacks efficiently too. Is this something specific to how GC works? Edit: Is it about having stacks smaller than a page, maybe not aligned to 4K and not fighting for the same cache lines?
- pcwalton 11y agoIn general mallocs allocate small blocks a lot faster than they allocate large blocks, because small blocks qualify for free list binning and the OS kernel doesn't need to serve you as many pages. (It wasn't obvious to me either that this was the case, but try it and see for yourself!) :)
- SamReidHughes 11y agoAt RethinkDB we managed our own free lists for stacks for this reason. One funny problem with the first implementation was that a stack could be born on one posix thread and die on another -- and certain threads would accumulate all the stacks, while the others would keep allocating them fresh.
- pcwalton 11y agoYeah, caching works OK when your total thread count is relatively constant, but most thread spawning benchmarks do things like spawn 100000 threads, synchronize, and then shut them all down, in which case the thread high-water-mark is constantly increasing and your stack cache always misses.
- SamReidHughes 11y agoCould you find out the names and addresses of people making these benchmarks? If so, that seems like it would be a relatively easy problem to fix. (Edit: I mean of course so we could allocate memory at their addresses for better locality, this is HN after all. Other ideas would need to be pulled to a different arena.)
- deleted 11y ago[deleted]
- Manishearth 11y agoI'm pretty certain green threading can be designed as a library. However, the choices made by that library need not affect the language as a whole anymore.
- Jweb_Guru 11y agoNot easily--it has to be able to hook in at the linker level in order to deal with thread local storage properly.