3 ms·

Except it’s more than that. Go and Java maintain a stack for every virtual thread. They are clever about it, but it’s very possible that doing anything more tha

by pkulak 2y ago

Except it’s more than that. Go and Java maintain a stack for every virtual thread. They are clever about it, but it’s very possible that doing anything more than a sleep would have blown up memory on those two systems.

bilbo0s 2y ago
I have a sneaky suspicion if you do anything other than the sleep during these 1 million tasks, you'll blow up memory on all of these systems. That's kind of the Achille's Heel of the benchmark. Any business needing to spawn 1 million tasks, certainly wants to do something on them. It's the "do something on them" part that usually leads to difficulties for these things. Not really the "spawn a million tasks" part.
- vlovich123 2y ago
  The “do something” OP is referring to is simple things like a deeply nested set of function calls and on stack data structures allocated and freed before you sleep. This increases the size of the stack that Go needs to save. By comparison stackless coroutines only save enough information for the continuation, no more no less. That’s going to be strictly smaller than saving the entire stack. The argument you seem to be making is that that could be the same size as the stack (eg heap allocations) but I think that’s being unreasonably optimistic. It should always end up being strictly smaller.
  - theamk 2y ago
    I have no doubt it's going to be strictly smaller, it's just the difference could be too small to care. Like say you are making a server, and each client has 16KB of state. Then memory usage would be 17KB in Node vs 19 KB in Go. Smaller? Yes. Smaller enough that you want to rewrite the whole app? Probably not.
    - vlovich123 2y ago
      But it wouldn’t necessarily be 17kib vs 19kib then. It would be reasonable to assume that larger context would be paired with more stack usage so it’s 17kib vs 21 or 25kib and that’s 20-40% more memory being required for Go. That can be quite substantial as 1M concurrent clients represents a case where that memory starts becoming quite a premium.

by pkulak 2y ago

bilbo0s 2y ago

I have a sneaky suspicion if you do anything other than the sleep during these 1 million tasks, you'll blow up memory on all of these systems. That's kind of the Achille's Heel of the benchmark. Any business needing to spawn 1 million tasks, certainly wants to do something on them. It's the "do something on them" part that usually leads to difficulties for these things. Not really the "spawn a million tasks" part.

vlovich123 2y ago
The “do something” OP is referring to is simple things like a deeply nested set of function calls and on stack data structures allocated and freed before you sleep. This increases the size of the stack that Go needs to save. By comparison stackless coroutines only save enough information for the continuation, no more no less. That’s going to be strictly smaller than saving the entire stack. The argument you seem to be making is that that could be the same size as the stack (eg heap allocations) but I think that’s being unreasonably optimistic. It should always end up being strictly smaller.
- theamk 2y ago
  I have no doubt it's going to be strictly smaller, it's just the difference could be too small to care. Like say you are making a server, and each client has 16KB of state. Then memory usage would be 17KB in Node vs 19 KB in Go. Smaller? Yes. Smaller enough that you want to rewrite the whole app? Probably not.
  - vlovich123 2y ago
    But it wouldn’t necessarily be 17kib vs 19kib then. It would be reasonable to assume that larger context would be paired with more stack usage so it’s 17kib vs 21 or 25kib and that’s 20-40% more memory being required for Go. That can be quite substantial as 1M concurrent clients represents a case where that memory starts becoming quite a premium.