4 ms·

3x might be a bit too much today, but it's definitely slower than C. Also to be considered is the VM overhead, not just the executed code. Here are some benchm

3x might be a bit too much today, but it's definitely slower than C. Also to be considered is the VM overhead, not just the executed code. Here are some benchmarks; I'll leave to the experts out there to confirm or dismiss them. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

robocat 7y ago
However the memory usage difference is astonishing for some of those benchmarks - using 1000x more memory is only acceptable for some situations.
- iainmerrick 7y ago
  This may be overly cynical, but don’t you have it backwards? 1000x greater memory usage is acceptable for most applications. There are only a few applications for which it isn’t acceptable. Just look at all the massive apps built on Electron. People wouldn’t do that if it wasn’t effective.
  - wool_gather 7y ago
    Wouldn't you say there's a difference between "effective" and "getting away with it"? If non-technical users see that their daily computing lives are made more complicated (because of lowered performance) by having n Electron apps running at the same time, they may not understand the reasons, but they will certainly choose a different solution that has the features they need, where available.
    - iainmerrick 7y ago
      Wouldn't you say there's a difference between "effective" and "getting away with it"? I used to think that but now I’m not so sure. :(
- igouy 7y ago
  — default JVM allocation ~35 MB looks astonishing for tiny programs that don't allocate memory — memory usage is less different for tiny programs that do allocate memory: reverse-complement, k-nucleotide, binary-trees, mandelbrot, regex-redux
- squarefoot 7y ago
  Agreed, and ironically the most widely used Java platform (Android), despite its VM optimizations, is the one which would benefit the most from running only native code. I mean, those 1GB RAM 7 years old slow as molasses phones getting dust into drawers or being littered into landfills would scream if they didn't have to run everything behind a VM.
  - yc12340 7y ago
    Make no mistake — Android isn't memory hungry because of Java alone. Android 4 used to comfortably fit in 1Gb of RAM, but Android 10 no longer can run on such devices. Both old and new versions use JVM, but newer Android has a lot of "helpful" system services, such as "Usage Statistics" service [1] and "Autofill Servide" [2]. Google's spyware is becoming more invasive and thus more memory-hungry. 1: https://developer.android.com/reference/android/app/usage/UsageStats https://developer.android.com/reference/android/app/usage/Us... 2: https://developer.android.com/reference/android/service/autofill/AutofillService https://developer.android.com/reference/android/service/auto...
anarazel 7y ago
Really depends on the domain. There's some things that are a lot easier to make scale up in a language with a great concurrent gc, because that makes writing some lock free data structures quite fundamentally easier (no complicated memory reclamation logic, trivial to avoid ABA problems).
- pkolaczk 7y ago
  GC makes it easier to write, but not necessarily better. Modern state-of-the-art Java GCs operate a global heap, so you often pay for what you do not use. In languages like Rust or C++ your can build small locally GCed heaps, where you can limit GC overhead to just a few particular structures that need GC, not everything. Therefore other structures like caches don't affect GC pause times. And the "hardness" of writing lockless structures is strongly offset by libraries, so unless you're doing something very exotic, it is rarely a real problem.
  - BenFrantzDale 7y ago
    “GC makes it easier to write.” I disagree. GC means I don’t get deterministic destruction which means I can’t use RAII properly.
    - pkolaczk 7y ago
      The post was about writing lockless structures. With lockless RAII is of no use. See ABA problem. RAII is awesome in other places.
kllrnohj 7y ago
> 3x might be a bit too much today, but it's definitely slower than C. If anything the gap is increasing not shrinking. JVM is terrible at memory access patterns due to the design of the language, and designing for memory is increasingly critical for maximum performance on modern systems. All the clever JIT'ing in the world can't save you from the constant pointer chasing, poor cache locality, and poor prefetching. The gap won't shrink until Java has value types. Which is on the roadmap, yes, but still doesn't exist just yet. The problem with those benchmarks is if you look at the Java code you'll see it's highly non-idiomatic. Almost no classes or allocations. They almost all exclusively use primitives and raw arrays. Even then it still doesn't match the performance on average of the C (or similar) versions, but if you add the real-world structure you'd find in any substantial project that performance drops off.
- wool_gather 7y ago
  When you say "value types" in this context, you mean "copy-only types"?
  - kllrnohj 7y ago
    I mean "value types" https://www.jesperdj.com/2015/10/04/project-valhalla-value-types/ https://www.jesperdj.com/2015/10/04/project-valhalla-value-t... & http://cr.openjdk.java.net/~jrose/values/values-0.html http://cr.openjdk.java.net/~jrose/values/values-0.html I don't know what you mean by "copy-only types." I'm not finding any reference to that terminology in the context of language design.
    - wool_gather 7y ago
      Ah, thanks for the link; I wasn't sure what it meant in the context of Java, since it's possible to get value semantics using a class. Sorry about the confusion. I meant for the quotes around "copy-only" to indicate that it wasn't really a standard term, but I marked "value types" the same way, so that didn't really work. By "copy-only" I meant something you couldn't have more than one reference to: every name (variable) to which you assign the data would have its own independent copy.

robocat 7y ago

However the memory usage difference is astonishing for some of those benchmarks - using 1000x more memory is only acceptable for some situations.

iainmerrick 7y ago
This may be overly cynical, but don’t you have it backwards? 1000x greater memory usage is acceptable for most applications. There are only a few applications for which it isn’t acceptable. Just look at all the massive apps built on Electron. People wouldn’t do that if it wasn’t effective.
- wool_gather 7y ago
  Wouldn't you say there's a difference between "effective" and "getting away with it"? If non-technical users see that their daily computing lives are made more complicated (because of lowered performance) by having n Electron apps running at the same time, they may not understand the reasons, but they will certainly choose a different solution that has the features they need, where available.
  - iainmerrick 7y ago
    Wouldn't you say there's a difference between "effective" and "getting away with it"? I used to think that but now I’m not so sure. :(
igouy 7y ago
— default JVM allocation ~35 MB looks astonishing for tiny programs that don't allocate memory — memory usage is less different for tiny programs that do allocate memory: reverse-complement, k-nucleotide, binary-trees, mandelbrot, regex-redux
squarefoot 7y ago
Agreed, and ironically the most widely used Java platform (Android), despite its VM optimizations, is the one which would benefit the most from running only native code. I mean, those 1GB RAM 7 years old slow as molasses phones getting dust into drawers or being littered into landfills would scream if they didn't have to run everything behind a VM.
- yc12340 7y ago
  Make no mistake — Android isn't memory hungry because of Java alone. Android 4 used to comfortably fit in 1Gb of RAM, but Android 10 no longer can run on such devices. Both old and new versions use JVM, but newer Android has a lot of "helpful" system services, such as "Usage Statistics" service [1] and "Autofill Servide" [2]. Google's spyware is becoming more invasive and thus more memory-hungry. 1: https://developer.android.com/reference/android/app/usage/UsageStats https://developer.android.com/reference/android/app/usage/Us... 2: https://developer.android.com/reference/android/service/autofill/AutofillService https://developer.android.com/reference/android/service/auto...

anarazel 7y ago

Really depends on the domain. There's some things that are a lot easier to make scale up in a language with a great concurrent gc, because that makes writing some lock free data structures quite fundamentally easier (no complicated memory reclamation logic, trivial to avoid ABA problems).

pkolaczk 7y ago
GC makes it easier to write, but not necessarily better. Modern state-of-the-art Java GCs operate a global heap, so you often pay for what you do not use. In languages like Rust or C++ your can build small locally GCed heaps, where you can limit GC overhead to just a few particular structures that need GC, not everything. Therefore other structures like caches don't affect GC pause times. And the "hardness" of writing lockless structures is strongly offset by libraries, so unless you're doing something very exotic, it is rarely a real problem.
- BenFrantzDale 7y ago
  “GC makes it easier to write.” I disagree. GC means I don’t get deterministic destruction which means I can’t use RAII properly.
  - pkolaczk 7y ago
    The post was about writing lockless structures. With lockless RAII is of no use. See ABA problem. RAII is awesome in other places.

kllrnohj 7y ago

> 3x might be a bit too much today, but it's definitely slower than C. If anything the gap is increasing not shrinking. JVM is terrible at memory access patterns due to the design of the language, and designing for memory is increasingly critical for maximum performance on modern systems. All the clever JIT'ing in the world can't save you from the constant pointer chasing, poor cache locality, and poor prefetching. The gap won't shrink until Java has value types. Which is on the roadmap, yes, but still doesn't exist just yet. The problem with those benchmarks is if you look at the Java code you'll see it's highly non-idiomatic. Almost no classes or allocations. They almost all exclusively use primitives and raw arrays. Even then it still doesn't match the performance on average of the C (or similar) versions, but if you add the real-world structure you'd find in any substantial project that performance drops off.

wool_gather 7y ago
When you say "value types" in this context, you mean "copy-only types"?
- kllrnohj 7y ago
  I mean "value types" https://www.jesperdj.com/2015/10/04/project-valhalla-value-types/ https://www.jesperdj.com/2015/10/04/project-valhalla-value-t... & http://cr.openjdk.java.net/~jrose/values/values-0.html http://cr.openjdk.java.net/~jrose/values/values-0.html I don't know what you mean by "copy-only types." I'm not finding any reference to that terminology in the context of language design.
  - wool_gather 7y ago
    Ah, thanks for the link; I wasn't sure what it meant in the context of Java, since it's possible to get value semantics using a class. Sorry about the confusion. I meant for the quotes around "copy-only" to indicate that it wasn't really a standard term, but I marked "value types" the same way, so that didn't really work. By "copy-only" I meant something you couldn't have more than one reference to: every name (variable) to which you assign the data would have its own independent copy.