It would be more interesting to see a benchmark where a task will not be empty but would have an open network connection e.g. would make an HTTP request to a test server with 10 seconds response time. Network is a frequent reason real world applications spawn 1M tasks.
How much memory do you need in 2024 to run 1M concurrent tasks?
91–100 of 205 posts
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#92> high number of concurrent tasks can consume a significant amount of memory note absolute numbers here: in the worst case, 1M tasks consumed 2.7 GB of RAM, with ~2700 bytes overhead per task. That'd still fit in the cheapest server with room to spare. My conclusion would be opposite: as long as per-task data is more than a few KB, the memory overhead of task scheduler is negligible.
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.
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.
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#93Yet again nodejs surpasses my pre-read expectations 3rd best (generalized) for a million? Wow. I must be missing something - isn’t Go supposed to be memory efficient? Perhaps promises and goroutines aren’t comparable?
If you want to run 1 million coroutines that just sleep in your app, yeah nodejs looks very efficient. The problem is that when each coroutine needs to allocate memory, which I would suppose anything real would do, the 2Kb Go pre-allocates will be an advantage - as it will probably be required except for the most trivial workloads (like in this benchmark) - and then because Go actually runs them in parallel, unlike nodejs, you would likely see a huge improvement in both performance and memory usage with Go or Rust.
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#94Earlier quoted context omitted.
Go stacks are dynamically copied and resized. Stack overflow is not a concern.
Oh yuck. Invalidating all the pointers to the stack? That's got to be expensive. I guess if you're already doing garbage collection moving the stack doesn't make things all that much worse though... still, yuck.
Yeah it’s the drawback, originally it used segmented stacks but that has its own issues.
And it’s probably not the worst issue because deep stacks and stack pointers will mostly be relevant for long running routines which will stabilise their stack use after a while (even if some are likely subject to threshold effects if they’re at the edge, I would not be surprised if some codebases ballasted stacks ahead of time). Also because stack pointers will get promoted to the heap if they escape so the number of stack pointers is not unlimited, and the pointer has to live downwards on the stack.
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#95Earlier quoted context omitted.
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…
But you wouldn't call a million tasks with `Promise.all` in Node, right? That's just not a thing that one does. Instead, there's usually going to be some queue outside the VM that will leave you with _some_ sort of chunking and otherwise working in smaller, more manageable bits (that might, incidentally, be shaped in ways that the VM can handle in interesting ways). It's definitely true to say that the "idioamatic" w…
> But you wouldn't call a million tasks with `Promise.all` in Node, right? That's just not a thing that one does.
But neither would you wait on a waitgroup of size 1 million in Go... right?
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#96Do we know how memory consumption?
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#97While the idea in general is interesting, the whole site is unreadable in Firefox, text gets all over the place the graphics.
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#98While the idea in general is interesting, the whole site is unreadable in Firefox, text gets all over the place the graphics.
Seems fine to me.
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#99NodeJS is better at memory than go?
They are doing different things in this benchmark.
NodeJS has one thread with a very tight loop.
Go actually spawned 1M green threads.
Honestly this benchmark is just noise. Not to say useless in most real world scenarios. Specially because each operation is doing nothing. It would be somewhat useful if they were doing some operation like a DB or HTTP call.
Re: How much memory do you need in 2024 to run 1M concurrent tasks?
#100Can someone explain the node version to me? My js knowledge is from a decade ago. AFAIK, setTimeout creates a timer and returns a handle to it. What does promisify do? I'd assume it's a general wrapper that takes a function that returns X and wraps it so that it returns Promise. So that code actually runs 10k tasks that each create a timer with a timeout of 10 seconds and return immediately.