Hacker News new | ask | show | jobs
by uluyol 1475 days ago
Why is spending GB on stack space a bad thing? Ultimately, in a server, you need to store state for each request. Whether that's on the stack or heap, it's still memory that necessarily has to be used.
2 comments

If you need the stack space then there is no difference. The difference arises because if you preallocate all that stack space using worst case stack sizes and don't use most of it, you've wasted lots of memory.

Also there is a ton of nuance here like overcommitted pages and large address spaces which mitigate some of those downsides.

Expect, Go doesn't do that. It grows stacks as you use them and shrinks them if you stop using so much. So the overhead should be limited. FWIW, heap allocations also come with memory overhead.
Right, yes, go does have some nice ways of handling this problem. I was speaking more generally about using that much stack space vs heap space for threads in general - but I should have realized that this specific thread was more about go, and perhaps my comment wasn't as useful in that context.
Despite popular belief, not everything is a (web) server. I can imagine many threads to be appealing in e.g. simulations.
I definitely can’t hire anyone in this thread to work on cell phone performance. We fight for 10 KBs of memory and yes, we are still doing this in 2022.

Even on a server, you may have TBs of RAM but you don’t have that much L1 cache nor that much memory bandwidth.

Why would you need hundreds of thousands or millions of goroutines for a cell phone app/daemon?

I would expect the number (and corresponding memory usage) to therefore be low.

The only numbers in programming are one, two, and many.

So if you’re not very careful and nothing stops you, it’s pretty easy to create an unbounded amount of anything.

By that logic, allowing more than 2 byte allocations is a mistake.
Sure, but my point is that if you want to run 100k-1m things concurrently, you need to store state for them.

That has a memory cost no matter what.