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

How much memory do you need in 2024 to run 1M concurrent tasks?

hez2010.github.io

Post reply on HN
Print view View original

151–160 of 205 posts

Re: How much memory do you need in 2024 to run 1M concurrent tasks?

#151

Post by masklinn »

xarope wrote: post #138
masklinn wrote: post #59

Earlier quoted context omitted.

Go is absolutely using that ram, it’s not available to other services on the system.

The argument then, is what if we DO load 2K worth [0] of randomized data into each of those 1m goroutines (and equivalents in the other languages), and do some actual processing. Would we still see the equivalent 10x (whatever math works it out to be) memory "bloat"? And what about performance? We, as devs, have "4" such resources available to us, memory, network, I/O and compute. And it behooves us to not prematurel…

So the argument is “if you measure something completely different from and unrelated to the article you do not get the same result”?

I guess that’s true.

And to be clear, I do agree with the top comment (which seems to be by you), TFA uses timers in the other runtimes and go does have timers so using goroutines is unwarranted and unfair. And I said as much a few comment up (although I’d forgotten about AfterFunc so I’d have looped and waited on timer.After which would still have been a pessimisation).

And after thinking more about it the article is in also outright lying: technically it’s only measuring tasks in Go, timers are futures / awaitables but they’re not tasks: they’re not independently scheduled units of work, and are pretty much always special cased by runtimes.

Re: How much memory do you need in 2024 to run 1M concurrent tasks?

#153

Post by enginoid »

JyB wrote: post #142

I’m still baffled that some people are bold enough to voluntarily posts those kind of most-of-the-time useless “benchmark” that will inevitably be riddled with errors. I don’t know what pushes them. In the end you look like a clown more often than not.

Trying things casually out of curiosity isn’t harmful. I expect people understand that these kinds of blog posts aren’t rigorous science to draw foundational conclusions from.

And the errors are a feature — I learn the most from the errata!

Re: How much memory do you need in 2024 to run 1M concurrent tasks?

#155

Post by jonathanstrange »

n2d4 wrote: post #41
AkshitGarg wrote: post #9

I feel this benchmark compares apples to oranges in some cases. For example, for node, the author puts a million promises into the runtime event loop and uses `Promise.all` to wait for them all. This is very different from, say, the Go version where the author creates a million goroutines and puts `waitgroup.Done` as a defer call. While this might be the idiomatic way of concurrency in the respective languages, it do…

Actually, I think this benchmark did the right thing, that I wish more benchmarks would do. I'm much less interested in what the differences between compilers are than in what the actual output will be if I ask a professional Go or Node.js dev to solve the same task. (TBF, it would've been better if the task benchmarked was something useful, eg. handling an HTTP request.) Go heavily encourages a certain kind of progr…

No professional Go programmer would spawn 1M goroutines unless they're sure they have the memory for it (and even then, only if benchmarks indicate it, which is unlikely). Goroutines have a static stack overhead between 2KiB to 8KiB depending on the platform. You'd use a work stealing approach with a reasonable number of goroutines instead. How many are reasonable needs to be tested because it depends on how long each Goroutine spends waiting for I/O or sleeping.

But I can go further than that: No professional programmer should run 1M concurrent tasks on an ordinary CPU no matter which language because it makes no sense if the CPU has several orders of magnitudes less cores. The tasks are not going to run in parallel anyway.

Re: How much memory do you need in 2024 to run 1M concurrent tasks?

#157

Post by lenkite »

Izkata wrote: post #65
afavour wrote: post #63

Earlier quoted context omitted.

Fair point. Kind of makes the comparisons between languages a little unfair, though. Go and Rust would be executing these operations in parallel, Node would not. Would make a significant difference to real world performance!

The measurement is memory, not performance. Paused/queued tasks in the sequential node version still count, and in theory could be worse since the Go and Rust ones would be consuming them in parallel and not building up the queue as much.

> The measurement is memory, not performance.

But, then they can measure memory by simply using a threat pool of size 1 and then submitting tasks to it right ? That would be the equivalent comparison for other languages.

They should launch a million NodeJS processes.

Re: How much memory do you need in 2024 to run 1M concurrent tasks?

#159

Post by wiseowise »

JyB wrote: post #142

I’m still baffled that some people are bold enough to voluntarily posts those kind of most-of-the-time useless “benchmark” that will inevitably be riddled with errors. I don’t know what pushes them. In the end you look like a clown more often than not.

The fastest way to learn truth is by posting wrong thing on the internet, or something.

Re: How much memory do you need in 2024 to run 1M concurrent tasks?

#160

Post by gpderetta »

jakewins wrote: post #144
gpderetta wrote: post #124

Earlier quoted context omitted.

Then it is fair to compare the memory usage of a stackful coroutine to a stack less one as they are the idiomatic way to perform async task on each language.

I mean this is subjective, but as long as it’s clear that one number is “this is the memory the runtime itself consumes to solve this problem” and the other number is “this is the runtime memory use and it includes pre-allocated stack space that a real application would then use”, sure Point being: Someone reading this to choose which runtime will fit their use case needs to be carefully to not assume the numbers mea…

Of course, as any microbenchmark, the bare results are useless. The numbers can be interesting only if you take the time to understand the implications.
Post reply on HN