4 ms·

> Indeed, but is relevant? If you have a machine with average memory installed, both are fine. The whole point is that you don't. You literally pay for the mem

by rualca 5y ago

> Indeed, but is relevant? If you have a machine with average memory installed, both are fine. The whole point is that you don't. You literally pay for the memory your application requires, proportionally to the amount of memory. The difference in the resources required to run is around two orders of magnitude. Let's put things in perspective: in some platforms such as AWS Lambda, you are charged per memory used per second.

capableweb 5y ago
Yeah, sure, that's one use case, to run it on AWS Lambda. Everyone does not, and if you really care about latency/throughoutput, you won't be anywhere near Lambda, and probably not even on AWS or any "cloud" for that matter. Paying for the amount of memory you use down to the MB, is hardly something everyone does, which makes it weird that you are now the third reply that assume this runs on AWS/Lambda.
- rualca 5y ago
  > Yeah, sure, that's one use case, to run it on AWS Lambda. It's not an edge case. It is a clear and irrefutable example that you pay for the memory you use. Let's be very clear here: when you provision a VM anywhere in the world, you have to pick how much memory you require. You are charged for that memory, proportionally to the memory you require. If your app requires over 100x memory to run, that comes out of your wallet.
  - capableweb 5y ago
    > It's not an edge case Never said it was an edge case.... > when you provision a VM anywhere in the world, you have to pick how much memory you require Yes, thank you! That's exactly my point! You create a VM (or a dedicated instance) somewhere, they ask you for the memory usage up front. Usually they start at 128MB and go their way up from there. Even if you take the instance with the smallest amount of memory, you'll fit any of the benchmarked programs, effective making the "115.41 MiB Java vs 4.15 MiB Rust" statement not as important anymore. > You are charged for that memory, proportionally to the memory you require. If your app requires over 100x memory to run, that comes out of your wallet Hm, maybe on Lambda you pay more if the memory your app uses grows. But this is certainly not standard for "normal" hosting where you rent either a VM or proper instance. Then the memory grows until it cannot take any more memory, and the process either crashes, gets killed by OOM or does whatever operation you've designed it to take when running out of memory.
    - jalk 5y ago
      And AWS lambda cpu performance is proportional to mem setting https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/ https://aws.amazon.com/blogs/compute/operating-lambda-perfor...
      - capableweb 5y ago
        Giving further proof that if you actually care about increasing throughoutput + saving costs, you won't be anywhere near Lambda. Thanks for the additional resource and confirmation.
        rualca 5y ago
        You're insisting in a red herring that tries to misrepresent the actual problem and the whole point of this discussion. The whole point is that memory costs money, and the more memory you require, the more you pay. AWS Lambdas is a clear example that demonstrates this, but is not an isolated case. This is the case for all cloud providers selling VM time. All of them. Even bare metal providers charge you more for more memory. Isn't it clear that if your app requires more and more memory, that comes out of your pocket? Is this something that really warrants a debate?
        Chyzwar 5y ago
        The problem is that the only way to get more CPU, you need to assign more memory to lambda. Most node.js lambdas would have stable idle/low memory usage around 200MB but you get ~1/9of vCPU core, this have severe impact performance. You are forced to overprovision lambdas with more memory, even then performance is still very much a disappointment. People that sold promise of serverless framework should have a special place in hell.
    - overtomanu 5y ago
      memory may matter when you want to run lot of application instances via docker
    - 5y ago

by rualca 5y ago

capableweb 5y ago

Yeah, sure, that's one use case, to run it on AWS Lambda. Everyone does not, and if you really care about latency/throughoutput, you won't be anywhere near Lambda, and probably not even on AWS or any "cloud" for that matter. Paying for the amount of memory you use down to the MB, is hardly something everyone does, which makes it weird that you are now the third reply that assume this runs on AWS/Lambda.

rualca 5y ago
> Yeah, sure, that's one use case, to run it on AWS Lambda. It's not an edge case. It is a clear and irrefutable example that you pay for the memory you use. Let's be very clear here: when you provision a VM anywhere in the world, you have to pick how much memory you require. You are charged for that memory, proportionally to the memory you require. If your app requires over 100x memory to run, that comes out of your wallet.
- capableweb 5y ago
  > It's not an edge case Never said it was an edge case.... > when you provision a VM anywhere in the world, you have to pick how much memory you require Yes, thank you! That's exactly my point! You create a VM (or a dedicated instance) somewhere, they ask you for the memory usage up front. Usually they start at 128MB and go their way up from there. Even if you take the instance with the smallest amount of memory, you'll fit any of the benchmarked programs, effective making the "115.41 MiB Java vs 4.15 MiB Rust" statement not as important anymore. > You are charged for that memory, proportionally to the memory you require. If your app requires over 100x memory to run, that comes out of your wallet Hm, maybe on Lambda you pay more if the memory your app uses grows. But this is certainly not standard for "normal" hosting where you rent either a VM or proper instance. Then the memory grows until it cannot take any more memory, and the process either crashes, gets killed by OOM or does whatever operation you've designed it to take when running out of memory.
  - jalk 5y ago
    And AWS lambda cpu performance is proportional to mem setting https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/ https://aws.amazon.com/blogs/compute/operating-lambda-perfor...
    - capableweb 5y ago
      Giving further proof that if you actually care about increasing throughoutput + saving costs, you won't be anywhere near Lambda. Thanks for the additional resource and confirmation.
      - rualca 5y ago
        You're insisting in a red herring that tries to misrepresent the actual problem and the whole point of this discussion. The whole point is that memory costs money, and the more memory you require, the more you pay. AWS Lambdas is a clear example that demonstrates this, but is not an isolated case. This is the case for all cloud providers selling VM time. All of them. Even bare metal providers charge you more for more memory. Isn't it clear that if your app requires more and more memory, that comes out of your pocket? Is this something that really warrants a debate?
        Chyzwar 5y ago
        The problem is that the only way to get more CPU, you need to assign more memory to lambda. Most node.js lambdas would have stable idle/low memory usage around 200MB but you get ~1/9of vCPU core, this have severe impact performance. You are forced to overprovision lambdas with more memory, even then performance is still very much a disappointment. People that sold promise of serverless framework should have a special place in hell.
  - overtomanu 5y ago
    memory may matter when you want to run lot of application instances via docker
  - 5y ago