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

121–130 of 205 posts

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

#121

Post by neonsunset »

fortran77 wrote: post #116

He should have looked at Erlang.

Erlang is likely going to have about the same or greater starting overhead as Go here from what I measured[0] with Elixir. Each Erlang process carries its own independent GC which allows it to isolate allocation impact, contributing to the robustness of its implementation. I assume this is where the cost comes from. If you do measure Erlang - please post the numbers.

Processes in Erlang, Goroutines in Go and Virtual Threads in Java do not fully replace lightweight asynchronous state machines - many small highly granular concurrent operations is their strength.

[0]: https://gist.github.com/neon-sunset/8fcc31d6853ebcde3b45dc7a... (disclaimer: as pointed out in a sibling comment it uses Elixir's Task abstraction which adds overhead on top of the processes)

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

#122

Post by win32_func »

The JS version can quickly be improved to use less memory (~10%).

    async function main() {
        const numTasks = parseInt(process.argv[2], 10);
        const taskDuration = 10000; // 10 seconds

        const tasks = Array.from({ length: numTasks }, () =>
            new Promise(resolve => setTimeout(resolve, taskDuration))
        );

        await Promise.all(tasks); // Wait for all tasks to resolve
        console.log("All tasks completed.");
    }

    main().catch(err => {
        console.error("Error occurred:", err);
    });

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

#123

Post by blitzar »

Izkata wrote: post #110
liontwist wrote: post #42

Earlier quoted context omitted.

I've seen 100k. What happens at a million? How many is unworkable?

$ cat /proc/sys/kernel/pid_max 4194304 My computer can handle that many processes, after that no new processes can be spawned (see: forkbomb)

I am left wondering what happens at 4194305

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

#124

Post by gpderetta »

melodyogonna wrote: post #84
Aeolun wrote: post #72

Earlier quoted context omitted.

Isn’t that kind of dumb when none of the other languages do this? Apparently allocating memory is really fast? Maybe we should change the test to load 1MB of data in every task?

Most of those languages (excepting Java virtual threads) uses stackless coroutines. Go uses stackful coroutines which allocates some memory upfront for a goroutine to use

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.

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

#126

Post by scrapheap »

winternewt wrote: post #54
jakewins wrote: post #45

Earlier quoted context omitted.

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?

Yes and no.

If that memory isn't being used and other things need the memory then the OS will very quickly dump it into swap, and as it's never being touched the OS will never need to bring it back in to physical memory. So while it's allocated it doesn't tie up the physical RAM.

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

#127

Post by blixt »

tossandthrow wrote: post #120
blixt wrote: post #115

While it’s nice to compare languages with simple idiomatic code I think it’s unfair to developers to show them the performance of an entirely empty function body and graphs with bars that focus on only one variable. It paints a picture that you can safely pick language X because it had the smaller bar. I urge anyone making decisions from looking at these graphs to run this benchmark themselves and add two things: - A…

This urge is as old as statistics. And I dare to say that most people after reading the article in question are well prepared to use the results for what they are.

I can’t say I share your optimism. I’ve seen plenty of developers point to graphs like these as a reason for why they picked a language or framework for a problem. And it comes down to the benchmark how good of a proxy it actually is for such problems. I just hope that with enough feedback the author would consider making the benchmark more nuanced to paint a picture of why these differences in languages exist (as opposed to saying which languages “lose” or “win”).

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

#128

Post by neonsunset »

Quothling wrote: post #119
jchw wrote: post #85

Earlier quoted context omitted.

I'm torn. As far as practicality goes I actually agree with you: if I knew I were trying to do something to the order of 1,000,000 tasks in Go I would probably use a worker pool for this exact reason. I have done this pattern in Go. It is certainly not unidiomatic. However, it also isn't the obvious way to do 1,000,000 things concurrently in Go. The obvious way to do 1,000,000 things concurrently in Go is to do a for…

I agree with everything you said and I think you contributed a lot to what I said making things much more clear. > I'll tell you what this benchmark tells me really though: C# is seriously impressive. The C# team has done some really great work in recent years. I personally hate working with it and it's "magic", but it's certainly in a very good place as far as trusting the CLR to "just work". Hilariously I also foun…

Userspace scheduling of Goroutines, virtual stack and non-deterministic pointer type allocation in Go are as much magic if not more, the syntactic sugar of C# is there to get the language out of your way and usually comes at no cost :)

If you do not like the aesthetics of C# and find Elixir or OCaml family tolerable - perhaps try F#? If you use task CEs there you end up with roughly the same performance profile and get to access huge ecosystem making it one of the few FP languages that can be used in production with minimal risk.

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

#129

Post by jeswin »

Good to see NativeAOT getting positive press.

Go won because it served a need felt by many programmers: a garbage-collected language which compiled to native code, with robust libraries supported by a large corp.

With Native AOT, C# is walking into the same space. With arguably better library selection, equivalent performance, and native code compilation. And a much more powerful, well-thought-out language - at a slight complexity cost. If you're starting a project today (with the luxury of choosing a language), you should give C# + NativeAOT a consideration.

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

#130

Post by ReptileMan »

martypitt wrote: post #112

Seriously impressive results from C#. I'm a JVM guy by day, and long-time admirer of C# as a language, but always assumed the two were broadly comparable performance-wise. This is a sample of 1 usecase, (so questionable real-worldness) but the difference is really eye-opening. Congrats to the C# team!

Just a minor nitpick - this is the .NET Runtime vs JVM. My personal observations are that CPU wise they are close, but for reasons unknown JVM has always been more memory hoggish.

The JIT compiler that microsoft created has been nothing short of amazing.

Post reply on HN