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.
[ Parent
| on HN ]
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.)