TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Goroutines Are Not Significantly Smaller Than Threads

10 pointsby bshanksabout 4 years ago

4 comments

theamkabout 4 years ago
I think this is a prime example of why micro-benchmarks are hard to get right, and easy to get wrong.<p>In particular, there are two concerning things here:<p>&quot;rust&quot; and &quot;go&quot; have pretty different memory performance characteristics -- one has GC and heavy runtime and other does not! It seems like this is &quot;go vs rust&quot; comparison, not &quot;goroutines vs thread&quot;. For fairness, you want the same language.<p>Another point is that the examples are really trivial, and don&#x27;t really exercise the stack. Would the thread stack shrink back or grow too fast? What about goroutine stack?
syocabout 4 years ago
Very recently posted. 111 comments <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26440334" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26440334</a>
btillyabout 4 years ago
The benchmark does not fit the title.<p>In the benchmark as originally done, threads took 3x the memory of goroutines. And that benchmark missed the 40 MB of data hidden in the kernel. Which makes a thread take over 4x the memory of a goroutine. And threads were 50% slower.<p>The memory and performance overhead of threads may not be an issue in specific use cases when you&#x27;re doing real work. But a factor of 4+ memory overhead does make threads significantly larger than goroutines.
Thaxllabout 4 years ago
For people that want to know where the memory is allocated in the kernel, slabtop is your friend ( or the less readable &#x2F;proc&#x2F;slabinfo ).