5 ms·

Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower m

by unoti 13y ago

Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower memory usage (often like 10x) than most of the other languages there, such as Scala. This can be very important depending on what your application is. For me, using Go for game world servers was my choice because I can do so much more simulation per dollar of server RAM.

dom96 13y ago
That doesn't only apply to Go and C, it most likely applies to all of the languages in the benchmark which do not rely on the JVM.
candybar 13y ago
Is this actually true on a marginal basis, especially in comparison to Go? My understanding was that JVM languages have a larger constant upfront memory footprint, but the difference isn't necessarily an increasing function of workload (perhaps of program size). Edit: Also, how is this relevant for anything other than Scala specifically? It seems odd for C and Go to end up on one side and C++, Rust, D and Nimrod to be on the other side, if memory consumption is a big concern.
- unoti 13y ago
  Generally, yes. Try some examples to see. I've done a lot of comparisons of game world simulators written in Go and Scala, accomplishing similar things with radically different memory footprints. I think the difference has to do with the fact that everything you do in Scala produces tons of little objects for anonymous functions and loop iterators and so on. For many applications this doesn't matter, especially with how cheap RAM is. But for some applications, such as mobile games and rented server space where your profitability is a function involving RAM cost per user, this can be very significant.
  - kasey_junk 13y ago
    This is absolutely true if you are writing idiomatic Scala code (especially if you are using their collections api). That said, you can lower your memory requirements dramatically using pretty standard high performance JVM techniques in Scala much as you can in Java. I've designed server systems in scala that produce no garbage for weeks at a time. This can be a good option if you have some small subset of your system that needs to be memory sensitive/high performance without having to lose the benefits of the JVM in the rest of the system.
Symmetry 13y ago
I would bet that C++ and Rust and D and really any language that doesn't have a large runtime and doesn't generally box it's variables would also have less memory usage.
- pjmlp 13y ago
  Just to list a few forgotten ones that have faded away that could also fit the bill: - Modula-2 - Modula-3 - Ada - Turbo/Apple/Object Pascal - Delphi - Oberon, Active Oberon, Oberon-2, Component Pascal
  - deleted 13y ago
    [deleted]
logicchains 13y ago
Although it wouldn't really be relevant for the level generation we're doing unless the memory usage was outrageous, I'm open to including memory usage in the table for comprehensiveness's sake. What would you say is the best way to measure ram usage on Linux; is there something as simple as 'time ./ThisExecutable' is for measuring time?
- mastensg 13y ago
  Try the time command (not the shell builtin): $ command time -f 'max resident:\t%M KiB' ls / bin etc initrd.img.old lib32 media proc sbin tmp vmlinuz boot home iso lib64 mnt root srv usr vmlinuz.old dev initrd.img lib lost+found opt run sys var max resident: 968 KiB
  - logicchains 13y ago
    Thanks, I've included max resident memory statistics on the benchmark.
- gtani 13y ago
  this is a really good writeup (summing up Private_Dirty, Shared_Dirty for some pid's: http://tech.brightbox.com/posts/2012-11-28-measuring-shared-ram-usage/ http://tech.brightbox.com/posts/2012-11-28-measuring-shared-... https://news.ycombinator.com/item?id=4842782 https://news.ycombinator.com/item?id=4842782
levosmetalo 13y ago
What's important is the marginal memory usage. I'd rather pay 20-30MB of JVM memory tax upfront it it levels up with C/C++ for long running process and lowers the possibility of a memory leak and memory corruption.
- Aloisius 13y ago
  If it was just the 20-30 MB JVM tax, I might be with you. But in applications that allocate and deallocate a lot of memory, the GC of every JVM implementation I've used also hoards memory from the system (well there are a few implementations that give it back, but they cause app performance to nosedive). If you're building a piece of software that needs to co-exist with other memory intensive processes, the JVM's policy of taking memory and rarely giving it back can cause unnecessary swapping. Heaven forbid you need to run multiple JVMs on the same machine (like with hadoop). Then you start having to do silly things like specifying how much memory your app is allowed to use which makes me feel like I'm on classic MacOS.
  - AlisdairO 13y ago
    This is a big issue for me too. IIRC the next version of the JVM will allow you to specify a target memory usage as well as a max, which will encourage it to GC more after memory spikes. You should be able to return some of this to the system without too much penalty (as long as the spikes aren't too frequent...).
    - levosmetalo 13y ago
      No need to wait for the "next gen" GC. Right now you can specify min percentage of free space in a heap that triggers giving back memory to the OS. Yes, you need to specify a few more GC parameters, but it's certainly doable to force JVM to behave this way. I used this approach in the past to keep memory usage lean. I had some spikes in application that required a lot of memory, so had to keep Xmx high, but configured the app to trigger deallocation to the OS when there's more that 20% of free memory. Worked like a charm even on and old ere 1.5 Sun JVM.
logicchains 13y ago
The benchmark now includes maximum resident memory usage. Go does indeed perform quite well (at least with 6g), using around 30MiB, compared to around 25/26MiB for the non-garbage-collected languages. Scala is memory-heavy, as expected, and Rust seems to use a surprising amount of memory for some reason.
- dom96 13y ago
  Don't forget about Nimrod which performs extremely well for a garbage collected language. And D which does too.
  - logicchains 13y ago
    True. I didn't actually realise the Nimrod implementation was garbage collected, I just assumed for some reason it managed memory in a hidden manual way like the C++ implementation. Note that garbage collection may not actually occur in this benchmark; for the single threaded benchmark at least, the Go runtime didn't make a single call to the GC, so D and Nimrod might be similar.

by unoti 13y ago

dom96 13y ago

That doesn't only apply to Go and C, it most likely applies to all of the languages in the benchmark which do not rely on the JVM.

candybar 13y ago

Is this actually true on a marginal basis, especially in comparison to Go? My understanding was that JVM languages have a larger constant upfront memory footprint, but the difference isn't necessarily an increasing function of workload (perhaps of program size). Edit: Also, how is this relevant for anything other than Scala specifically? It seems odd for C and Go to end up on one side and C++, Rust, D and Nimrod to be on the other side, if memory consumption is a big concern.

unoti 13y ago
Generally, yes. Try some examples to see. I've done a lot of comparisons of game world simulators written in Go and Scala, accomplishing similar things with radically different memory footprints. I think the difference has to do with the fact that everything you do in Scala produces tons of little objects for anonymous functions and loop iterators and so on. For many applications this doesn't matter, especially with how cheap RAM is. But for some applications, such as mobile games and rented server space where your profitability is a function involving RAM cost per user, this can be very significant.
- kasey_junk 13y ago
  This is absolutely true if you are writing idiomatic Scala code (especially if you are using their collections api). That said, you can lower your memory requirements dramatically using pretty standard high performance JVM techniques in Scala much as you can in Java. I've designed server systems in scala that produce no garbage for weeks at a time. This can be a good option if you have some small subset of your system that needs to be memory sensitive/high performance without having to lose the benefits of the JVM in the rest of the system.

Symmetry 13y ago

I would bet that C++ and Rust and D and really any language that doesn't have a large runtime and doesn't generally box it's variables would also have less memory usage.

pjmlp 13y ago
Just to list a few forgotten ones that have faded away that could also fit the bill: - Modula-2 - Modula-3 - Ada - Turbo/Apple/Object Pascal - Delphi - Oberon, Active Oberon, Oberon-2, Component Pascal
- deleted 13y ago
  [deleted]

logicchains 13y ago

Although it wouldn't really be relevant for the level generation we're doing unless the memory usage was outrageous, I'm open to including memory usage in the table for comprehensiveness's sake. What would you say is the best way to measure ram usage on Linux; is there something as simple as 'time ./ThisExecutable' is for measuring time?

mastensg 13y ago
Try the time command (not the shell builtin): $ command time -f 'max resident:\t%M KiB' ls / bin etc initrd.img.old lib32 media proc sbin tmp vmlinuz boot home iso lib64 mnt root srv usr vmlinuz.old dev initrd.img lib lost+found opt run sys var max resident: 968 KiB
- logicchains 13y ago
  Thanks, I've included max resident memory statistics on the benchmark.
gtani 13y ago
this is a really good writeup (summing up Private_Dirty, Shared_Dirty for some pid's: http://tech.brightbox.com/posts/2012-11-28-measuring-shared-ram-usage/ http://tech.brightbox.com/posts/2012-11-28-measuring-shared-... https://news.ycombinator.com/item?id=4842782 https://news.ycombinator.com/item?id=4842782

levosmetalo 13y ago

What's important is the marginal memory usage. I'd rather pay 20-30MB of JVM memory tax upfront it it levels up with C/C++ for long running process and lowers the possibility of a memory leak and memory corruption.

Aloisius 13y ago
If it was just the 20-30 MB JVM tax, I might be with you. But in applications that allocate and deallocate a lot of memory, the GC of every JVM implementation I've used also hoards memory from the system (well there are a few implementations that give it back, but they cause app performance to nosedive). If you're building a piece of software that needs to co-exist with other memory intensive processes, the JVM's policy of taking memory and rarely giving it back can cause unnecessary swapping. Heaven forbid you need to run multiple JVMs on the same machine (like with hadoop). Then you start having to do silly things like specifying how much memory your app is allowed to use which makes me feel like I'm on classic MacOS.
- AlisdairO 13y ago
  This is a big issue for me too. IIRC the next version of the JVM will allow you to specify a target memory usage as well as a max, which will encourage it to GC more after memory spikes. You should be able to return some of this to the system without too much penalty (as long as the spikes aren't too frequent...).
  - levosmetalo 13y ago
    No need to wait for the "next gen" GC. Right now you can specify min percentage of free space in a heap that triggers giving back memory to the OS. Yes, you need to specify a few more GC parameters, but it's certainly doable to force JVM to behave this way. I used this approach in the past to keep memory usage lean. I had some spikes in application that required a lot of memory, so had to keep Xmx high, but configured the app to trigger deallocation to the OS when there's more that 20% of free memory. Worked like a charm even on and old ere 1.5 Sun JVM.

logicchains 13y ago

The benchmark now includes maximum resident memory usage. Go does indeed perform quite well (at least with 6g), using around 30MiB, compared to around 25/26MiB for the non-garbage-collected languages. Scala is memory-heavy, as expected, and Rust seems to use a surprising amount of memory for some reason.

dom96 13y ago
Don't forget about Nimrod which performs extremely well for a garbage collected language. And D which does too.
- logicchains 13y ago
  True. I didn't actually realise the Nimrod implementation was garbage collected, I just assumed for some reason it managed memory in a hidden manual way like the C++ implementation. Note that garbage collection may not actually occur in this benchmark; for the single threaded benchmark at least, the Go runtime didn't make a single call to the GC, so D and Nimrod might be similar.