41–49 of 49 posts
Earlier quoted context omitted.
That's very sad for Rust, because Go's goroutines are amazingly awesome.
I'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.
Earlier quoted context omitted.
That's very sad for Rust, because Go's goroutines are amazingly awesome.
I 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 prima…
Earlier quoted context omitted.
I 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 prima…
How does having small initial stack sizes give you fast thread spawning?
Earlier quoted context omitted.
How does having small initial stack sizes give you fast thread spawning?
Because you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
Edit: Is it about having stacks smaller than a page, maybe not aligned to 4K and not fighting for the same cache lines?
Earlier quoted context omitted.
Because you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
But 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?
Earlier quoted context omitted.
But 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?
In 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!) :)
Earlier quoted context omitted.
In 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!) :)
At 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.
Earlier quoted context omitted.
In 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!) :)
At 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.
Earlier quoted context omitted.
At 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.
Yeah, 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.
(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.)