Hacker News Reader

Comment by axod | Hacker News Reader

>> "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.

View on HN

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.

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.

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.

> 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?

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.

"Yes Java can be faster than C in some situations."

Unless the person writing the C implementation is grossly incompetent, I would like to see even one example for that.

You can't see a situation where the JVM can optimize things, inline code, etc at runtime and beat a general C implementation? :/

I would say that any C programmer worth his salt (unlike me) knows how to profile the code under a meaningful workload and how to optimize it to be faster.

I remember I used the shortest possible integers and the register keyword in the late 80's far too many times to count.

The point of somewhat higher-level languages like Java (I refuse to say Java is a high-level language - it would be one in the late 80s, but not today) is not to make programs run faster, but to make it easier to make them run correctly.

A Java application will invariably use more much memory than C implementation of almost any non-trivial application. You can inline code all you want, but it'll never change that. The JVM isn't magical -- it's not going to solve all your performance problems. When you're allocating a million tiny little objects with all the necessary accounting you can't optimize that away.

BTW, if it's so obvious why haven't you still provided at least one non-trivial concrete example of Java faster than C?

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.

wrt value types, shouldn't it be partially solved by escape analisys? Cfr: http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-d...

not that it would matter much in the case anyway, I guess.

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.

'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

"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 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-perform...

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...

And measurements:

http://shootout.alioth.debian.org/help.php#java

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.

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

Reply on news.ycombinator.com