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

51–60 of 205 posts

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

#51

Post by [deleted] »

threeseed wrote: post #33
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…

The requirement is to run 1 million concurrent tasks. Of course each language will have a different way of achieving this task each of which will have their unique pros/cons. That's why we have these different languages to begin with.

[deleted]

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

#52

Post by tzahifadida »

This test is no real. These languages works differently. Garbage collected and manually allocating and deallocating. If you do not configure a garbage collected language correctly it will spin out of control in memory consumption because it will just not garbage collect. If you would have configured the garbage collection to be low for java and go then go would look like rust.

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

#53

Post by lmm »

threeseed wrote: post #33
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…

The requirement is to run 1 million concurrent tasks. Of course each language will have a different way of achieving this task each of which will have their unique pros/cons. That's why we have these different languages to begin with.

> The requirement is to run 1 million concurrent tasks.

That's not a real requirement though. No business actually needs to run 1 million concurrent tasks with no concern for what's in them.

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

#54

Post by winternewt »

jakewins wrote: post #45
masklinn wrote: post #38

Earlier quoted context omitted.

> I have no idea what Go is doing to get 2500 bytes per task. TFA creates a goroutine (green thread) for each task (using a waitgroup to synchronise them). IIRC goroutines default to 2k stacks, so that’s about right. One could argue it’s not fair and it should be timers which would be much lighter. There’s no “efficient wait” for them but that’s essentially the same as the appendix rust program.

Fair or not, it’s a strange way to count - Go isn’t using that RAM. It’s preallocating it because any real world program will.

Please elaborate. If each stack is 2KB then surely all of that virtual memory is committed to physical RAM, and hence is using actual memory?

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

#55

Post by afavour »

Maybe I’m missing something here but surely Node isn’t doing anything concurrently? Promises don’t execute concurrently, they just tidy up async execution. The code as given will just sequentially resolve a million promises. No wonder it looks so good. You’d need to be using workers to actually do anything concurrently.

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

#56

Post by Mawr »

> Now Go loses by over 13 times to the winner. It also loses by over 2 times to Java, which contradicts the general perception of the JVM being a memory hog and Go being lightweight.

Well, if it isn't the classic unwavering confidence that an artificial "hello world"-like benchmark is in any way representative of real world programs.

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

#57

Post by cperciva »

masklinn wrote: post #38
cperciva wrote: post #7

This depends a lot on how you define "concurrent tasks", but the article provides a definition: Let's launch N concurrent tasks, where each task waits for 10 seconds and then the program exists after all tasks finish. The number of tasks is controlled by the command line argument. Leaving aside semantics like "since the tasks aren't specified as doing anything with side effects, the compiler can remove them as dead c…

> I have no idea what Go is doing to get 2500 bytes per task. TFA creates a goroutine (green thread) for each task (using a waitgroup to synchronise them). IIRC goroutines default to 2k stacks, so that’s about right. One could argue it’s not fair and it should be timers which would be much lighter. There’s no “efficient wait” for them but that’s essentially the same as the appendix rust program.

Aha, 2k stacks. I figured that stacks would be page size (or more) so 2500 seemed both too small for the thread to have a stack and too large for it to not have a stack.

2k stacks are an interesting design choice though... presumably they're packed, in which case stack overflow is a serious concern. Most threading systems will do something like allocating a single page for the stack but reserving 31 guard pages in case it needs to grow.

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

#58

Post by charlotte-fyi »

afavour wrote: post #55

Maybe I’m missing something here but surely Node isn’t doing anything concurrently? Promises don’t execute concurrently, they just tidy up async execution. The code as given will just sequentially resolve a million promises. No wonder it looks so good. You’d need to be using workers to actually do anything concurrently.

That's not entirely true. There's a thread pool of workers underneath libuv. Tasks that would block do indeed execute concurrently.

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

#59

Post by masklinn »

jakewins wrote: post #45
masklinn wrote: post #38

Earlier quoted context omitted.

> I have no idea what Go is doing to get 2500 bytes per task. TFA creates a goroutine (green thread) for each task (using a waitgroup to synchronise them). IIRC goroutines default to 2k stacks, so that’s about right. One could argue it’s not fair and it should be timers which would be much lighter. There’s no “efficient wait” for them but that’s essentially the same as the appendix rust program.

Fair or not, it’s a strange way to count - Go isn’t using that RAM. It’s preallocating it because any real world program will.

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

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

#60

Post by Izkata »

afavour wrote: post #55

Maybe I’m missing something here but surely Node isn’t doing anything concurrently? Promises don’t execute concurrently, they just tidy up async execution. The code as given will just sequentially resolve a million promises. No wonder it looks so good. You’d need to be using workers to actually do anything concurrently.

You're thinking of parallelism. Concurrency doesn't require them to actually be running at the same time.
Post reply on HN