Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goroutines Under the Hood (2020)

osmh.dev

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Goroutines Under the Hood (2020)

#51

Post by uluyol »

jjnoakes wrote: post #37
uluyol wrote: post #6

Earlier quoted context omitted.

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.

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.

Re: Goroutines Under the Hood (2020)

#52

Post by uluyol »

guenthert wrote: post #35
uluyol wrote: post #6

Earlier quoted context omitted.

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.

Despite popular belief, not everything is a (web) server. I can imagine many threads to be appealing in e.g. simulations.

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.

Re: Goroutines Under the Hood (2020)

#53

Post by astrange »

uluyol wrote: post #50
astrange wrote: post #49

Earlier quoted context omitted.

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.

Re: Goroutines Under the Hood (2020)

#54

Post by jjnoakes »

uluyol wrote: post #51
jjnoakes wrote: post #37

Earlier quoted context omitted.

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.

Re: Goroutines Under the Hood (2020)

#55

Post by sagarm »

astrange wrote: post #53
uluyol wrote: post #50

Earlier quoted context omitted.

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.
Post reply on HN