4 ms·

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to

by axod 17y ago

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C. As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs. I don't understand why people are optimizing source control :/ fast vs fast meh I don't think it's an issue really.

fauigerzigerk 17y ago
The post specifically mentiones Java's implementation of memory mapped files, Java's lack of value types and Java's lack of unsigned types. These are very different areas but none of them can be solved by on the fly optimizations or longer running processes.
- riffraff 17y ago
  wrt value types, shouldn't it be partially solved by escape analisys? Cfr: http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-do-escape-analysis-default http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-d... not that it would matter much in the case anyway, I guess.
  - fauigerzigerk 17y ago
    Yes I think you're right that it should help a little in some cases. But the big issue with the lack of value types is memory usage (not in the case of jGit), which isn't solved by escape analysis.
richardw 17y ago
'Modern JVMs can make on the fly optimizations based on the runtime profile' That's something I've heard ever since hotspot came out, but it's not a silver bullet to beating C/C++ etc. Here are some server tests. Some are comparable, some are definitely not: http://shootout.alioth.debian.org/u64q/java.php http://shootout.alioth.debian.org/u64q/java.php
- jbellis 17y ago
  "Sometimes no-warmup is important (see comments above about pacemakers), but more often a short warmup period is irrelevant to the overall application. If I'm using an IDE, I expect a largish loading period... but then I'm using the IDE all day. I don't use an IDE for 0.1 sec. If warmup is NOT important to the application, then allow the JVM a warmup period before comparing performance numbers. Many of the benchmarks in the language shootout at http://shootout.alioth.debian.org http://shootout.alioth.debian.org fall into this camp: too short to measure something interesting. Nearly all complete in 1 minute or less." http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-perform...
  - igouy 17y ago
    The replies I post never seem to appear on that blog so here they are: http://www.reddit.com/r/programming/comments/9ic0x/java_vs_c_performance_again/c0d1qxr http://www.reddit.com/r/programming/comments/9ic0x/java_vs_c... And measurements: http://shootout.alioth.debian.org/help.php#java http://shootout.alioth.debian.org/help.php#java
- fauigerzigerk 17y ago
  What you link to are tests using the server VM but without warmup. You need to select "Java 6 steady-state" to get the warmup. [Edit] Actually the state-state one averages over multiples restarts including JITed and non-JITed runs.
  - igouy 17y ago
    See how little difference that "warmup" makes for these tiny programs - with the obvious exception of the binary-trees program - http://shootout.alioth.debian.org/help.php#java http://shootout.alioth.debian.org/help.php#java
jerf 17y ago
You're bringing theory to a shootout based on facts. Hypothesizing that Java might be faster with a strong enough headwind doesn't make the actual, factual JGit run faster or C-git run slower. I mention this because programmers seem prone to this, and letting theory trump fact is a great way to make sure that you never learn anything.
- deleted 17y ago
  [deleted]
- zootm 17y ago
  It's a pretty specific shootout, of course; the reasons brought up for JGit's relative slowness are not issues present in most applications, they're specific to certain realms of system. Unsigned number support is a major headache about Java when doing low-level work, in particular. I think it's also important to note that the slowness is relative to an incredibly fast C implementation - taking twice the time sounds painful, but in reality the pauses caused by Git are barely perceptible as-is, and double of that is not likely to be very annoying.
- axod 17y ago
  I was countering the headline, which wasn't correct. Java isn't slower than C in general. It may be in specific cases, for specific programmers, etc but that's not what the headline stated. The title takes one specific application in a particular niche, used in a certain way which a particular programmer can't get to run fast enough, and concludes that Java isn't fast enough. Faulty logic. The argument about JGit vs C-git for me isn't something I feel you can learn anything from.
  - wvenable 17y ago
    > Java isn't slower than C in general. Really? In general? That statements seams worse than the original headline. Is Java faster than C for anything?
    - axod 17y ago
      It completely depends. Both are silly generalizations. Yes Java can be faster than C in some situations. Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes. Depends if you're a master assembly programmer who hand optimizes everything.

by axod 17y ago

fauigerzigerk 17y ago

The post specifically mentiones Java's implementation of memory mapped files, Java's lack of value types and Java's lack of unsigned types. These are very different areas but none of them can be solved by on the fly optimizations or longer running processes.

riffraff 17y ago
wrt value types, shouldn't it be partially solved by escape analisys? Cfr: http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-do-escape-analysis-default http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-d... not that it would matter much in the case anyway, I guess.
- fauigerzigerk 17y ago
  Yes I think you're right that it should help a little in some cases. But the big issue with the lack of value types is memory usage (not in the case of jGit), which isn't solved by escape analysis.

richardw 17y ago

'Modern JVMs can make on the fly optimizations based on the runtime profile' That's something I've heard ever since hotspot came out, but it's not a silver bullet to beating C/C++ etc. Here are some server tests. Some are comparable, some are definitely not: http://shootout.alioth.debian.org/u64q/java.php http://shootout.alioth.debian.org/u64q/java.php

jbellis 17y ago
"Sometimes no-warmup is important (see comments above about pacemakers), but more often a short warmup period is irrelevant to the overall application. If I'm using an IDE, I expect a largish loading period... but then I'm using the IDE all day. I don't use an IDE for 0.1 sec. If warmup is NOT important to the application, then allow the JVM a warmup period before comparing performance numbers. Many of the benchmarks in the language shootout at http://shootout.alioth.debian.org http://shootout.alioth.debian.org fall into this camp: too short to measure something interesting. Nearly all complete in 1 minute or less." http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-perform...
- igouy 17y ago
  The replies I post never seem to appear on that blog so here they are: http://www.reddit.com/r/programming/comments/9ic0x/java_vs_c_performance_again/c0d1qxr http://www.reddit.com/r/programming/comments/9ic0x/java_vs_c... And measurements: http://shootout.alioth.debian.org/help.php#java http://shootout.alioth.debian.org/help.php#java
fauigerzigerk 17y ago
What you link to are tests using the server VM but without warmup. You need to select "Java 6 steady-state" to get the warmup. [Edit] Actually the state-state one averages over multiples restarts including JITed and non-JITed runs.
- igouy 17y ago
  See how little difference that "warmup" makes for these tiny programs - with the obvious exception of the binary-trees program - http://shootout.alioth.debian.org/help.php#java http://shootout.alioth.debian.org/help.php#java

jerf 17y ago

You're bringing theory to a shootout based on facts. Hypothesizing that Java might be faster with a strong enough headwind doesn't make the actual, factual JGit run faster or C-git run slower. I mention this because programmers seem prone to this, and letting theory trump fact is a great way to make sure that you never learn anything.

deleted 17y ago
[deleted]
zootm 17y ago
It's a pretty specific shootout, of course; the reasons brought up for JGit's relative slowness are not issues present in most applications, they're specific to certain realms of system. Unsigned number support is a major headache about Java when doing low-level work, in particular. I think it's also important to note that the slowness is relative to an incredibly fast C implementation - taking twice the time sounds painful, but in reality the pauses caused by Git are barely perceptible as-is, and double of that is not likely to be very annoying.
axod 17y ago
I was countering the headline, which wasn't correct. Java isn't slower than C in general. It may be in specific cases, for specific programmers, etc but that's not what the headline stated. The title takes one specific application in a particular niche, used in a certain way which a particular programmer can't get to run fast enough, and concludes that Java isn't fast enough. Faulty logic. The argument about JGit vs C-git for me isn't something I feel you can learn anything from.
- wvenable 17y ago
  > Java isn't slower than C in general. Really? In general? That statements seams worse than the original headline. Is Java faster than C for anything?
  - axod 17y ago
    It completely depends. Both are silly generalizations. Yes Java can be faster than C in some situations. Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes. Depends if you're a master assembly programmer who hand optimizes everything.