News for hackers. Stuff that matters.
Re:Why We Use Go by pcwalton on Friday May 29, 2015 @12:14AM (#9622615)
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!) :)
Re:Why We Use Go by SamReidHughes on Friday May 29, 2015 @12:25AM (#9622649)
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.
Re:Why We Use Go by pcwalton on Friday May 29, 2015 @02:54AM (#9623123)
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.
Re:Why We Use Go by SamReidHughes on Friday May 29, 2015 @03:11AM (#9623174)
Could 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.)