4 ms·

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 un

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.

jakewins 2y ago
The accounting here is weird though; Go isn’t using that RAM, it’s expecting the application to. The reason that doesn’t happen is because it’s a micro benchmark that produces no useful work.. The way the results are presented a reader may think the Go memory usage sounds equivalent to the others - boilerplate, ticket-to-play - and then the Go usage sounds super high. But they are not the same; that memory is in anticipation of a real world program using it
- Aeolun 2y ago
  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?
  - melodyogonna 2y ago
    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
    - gpderetta 2y ago
      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.
      - jakewins 2y ago
        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 measure the same thing. For some real world use cases the pre allocated stack will perform better than the runtimes that instead will do heap allocations.
        gpderetta 2y ago
        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.
  - perryizgr8 2y ago
    > Apparently allocating memory is really fast? Apart from i/o, allocating memory is usually the slowest thing you can do on a computer, in my experience.
deleted 2y ago
[deleted]
lmm 2y ago
> 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.
- OutOfHere 2y ago
  If you want to support 1 million concurrent active users, you can need it.
  - lmm 2y ago
    Maybe. But in that case you will need to do something for each of those users, and which languages are good at that might look quite different from this benchmark.

jakewins 2y ago

The accounting here is weird though; Go isn’t using that RAM, it’s expecting the application to. The reason that doesn’t happen is because it’s a micro benchmark that produces no useful work.. The way the results are presented a reader may think the Go memory usage sounds equivalent to the others - boilerplate, ticket-to-play - and then the Go usage sounds super high. But they are not the same; that memory is in anticipation of a real world program using it

Aeolun 2y ago
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?
- melodyogonna 2y ago
  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
  - gpderetta 2y ago
    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.
    - jakewins 2y ago
      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 measure the same thing. For some real world use cases the pre allocated stack will perform better than the runtimes that instead will do heap allocations.
      - gpderetta 2y ago
        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.
- perryizgr8 2y ago
  > Apparently allocating memory is really fast? Apart from i/o, allocating memory is usually the slowest thing you can do on a computer, in my experience.

deleted 2y ago

[deleted]

lmm 2y ago

> 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.

OutOfHere 2y ago
If you want to support 1 million concurrent active users, you can need it.
- lmm 2y ago
  Maybe. But in that case you will need to do something for each of those users, and which languages are good at that might look quite different from this benchmark.