3 ms·

> Java is faster than (or certainly as fast as) C already for a similar development effort Last I heard, this only applies if you write C in Java (i.e., no obj

by adwn 10y ago

> Java is faster than (or certainly as fast as) C already for a similar development effort Last I heard, this only applies if you write C in Java (i.e., no object composition through references, basic arrays instead of ArrayList, avoid GC wherever possible). I remember a project some years back where a git client (?) was to be written in Java, and even with these techniques they only got to within 2x C performance. > for a similar development effort Well, then that defeats the main reason for using Java, doesn't it? The gist of that claim was that you could write idiomatic Java (with GC, small objects, etc.) and the JIT would use the information gathered during runtime to optimize the program on-the-fly to be faster than C. > Today, projects like Truffle/Graal can run pretty much any dynamic language within 3-5x slower than C. Do you have a source for that? Not doubting you, geniunely curious.

pron 10y ago
The JIT can and does do all that, and I am talking about idiomatic Java (I'm speaking mainly from the experience of migrating a >5MLOC soft realtime defense application from C++ to Java). Similar performance can be achieved for much less effort (although C would always beat Java given significantly greater effort), and this effect is more pronounced the larger and more concurrent the application is. The cost -- for large application -- is just significantly greater RAM consumption. For small/constrained applications there are other costs. As I said, the main barrier (which is currently being addressed) is memory layout of arrays-of-structs, whose fixing requires additions to the language semantics (which are being done). Perhaps that particular issue was a failed promise, but it's mostly a result of hardware changes that occurred 10 years after Java's introduction. As to Graal, this very recent talk has some nice demos: https://www.youtube.com/watch?v=N__8TBcaDTs https://www.youtube.com/watch?v=N__8TBcaDTs You can find more material here: https://wiki.openjdk.java.net/display/Graal/Publications+and+Presentations https://wiki.openjdk.java.net/display/Graal/Publications+and...
lmm 10y ago
> Well, then that defeats the main reason for using Java, doesn't it? The gist of that claim was that you could write idiomatic Java (with GC, small objects, etc.) and the JIT would use the information gathered during runtime to optimize the program on-the-fly to be faster than C. You can put the same amount of effort in and the Java will perform better than the C. Or you can require the same level of performance and the Java will take less effort than the C (with the possible exception of very extreme performance cases).
- mbrodersen 10y ago
  That is simply not true unless the C code is written by a C programmer inexperience in writing high performance C code (a Java programmer for example).

by adwn 10y ago

pron 10y ago

The JIT can and does do all that, and I am talking about idiomatic Java (I'm speaking mainly from the experience of migrating a >5MLOC soft realtime defense application from C++ to Java). Similar performance can be achieved for much less effort (although C would always beat Java given significantly greater effort), and this effect is more pronounced the larger and more concurrent the application is. The cost -- for large application -- is just significantly greater RAM consumption. For small/constrained applications there are other costs. As I said, the main barrier (which is currently being addressed) is memory layout of arrays-of-structs, whose fixing requires additions to the language semantics (which are being done). Perhaps that particular issue was a failed promise, but it's mostly a result of hardware changes that occurred 10 years after Java's introduction. As to Graal, this very recent talk has some nice demos: https://www.youtube.com/watch?v=N__8TBcaDTs https://www.youtube.com/watch?v=N__8TBcaDTs You can find more material here: https://wiki.openjdk.java.net/display/Graal/Publications+and+Presentations https://wiki.openjdk.java.net/display/Graal/Publications+and...

lmm 10y ago

> Well, then that defeats the main reason for using Java, doesn't it? The gist of that claim was that you could write idiomatic Java (with GC, small objects, etc.) and the JIT would use the information gathered during runtime to optimize the program on-the-fly to be faster than C. You can put the same amount of effort in and the Java will perform better than the C. Or you can require the same level of performance and the Java will take less effort than the C (with the possible exception of very extreme performance cases).

mbrodersen 10y ago
That is simply not true unless the C code is written by a C programmer inexperience in writing high performance C code (a Java programmer for example).