Skip to main content

Cliff Click on Java-vs-C Performance

Cliff Click has a terrific post on Java-vs-native-code performance. Recommended.

Cliff is the Chief JVM Architect at Azul Systems, was the lead designer behind Hotspot's server JIT compiler, and is an all-around smart guy. His main drawback is that he (apparently) gets dragged into flamewars on YouTube's comment section.
Labels:

Comments

Isaac Gouy said…
Yes he's "an all-around smart guy" but that doesn't mean he isn't "being sloppy in the numbers I report here"; it doesn't mean he isn't being sloppy in his comments about the benchmarks game.
September 19, 2009 at 9:36 AM
Jeremy Manson said…
Without having dived into this too much, I do know that Cliff understands statistics pretty well. My guess is that examples he gave are more to prove a point than to demonstrate something conclusively.

My own opinion about the benchmark game is that it is (frankly) rather a waste of time. When I am deploying a server, I'm very interested in whether the code I have written can meet latency and throughput targets on the JVM in question, and not terribly interested in what SPECjbb2005 says. My experience is that the folks in charge of determining performance priorities for the JDK are more interested benchmarks than the average user's requirements.
September 20, 2009 at 5:33 PM
Isaac Gouy said…
> My guess is that examples he gave are more to prove a point than to demonstrate something conclusively.

The trouble is he's trying to make several different points and his arguments conflict with each other.

His Java can be just as fast as C point conflicts with his too short to show something interesting point.

His different code ... so all the results have to be carefully inspected point is just as true for any Java vs C comparison that he makes.


> the benchmark game is that it is (frankly) rather a waste of time

Is it possible you are over-generalizing from your current level of experience and workaday tasks, rather than considering a broader range of inexperience and mistaken notions and ordinary ignorance?


> When I am deploying a server...

As in your application is the ultimate benchmark.
September 21, 2009 at 10:32 AM
Jeremy Manson said…
Is it possible you are over-generalizing from your current level of experience and workaday tasks, rather than considering a broader range of inexperience and mistaken notions and ordinary ignorance?

Anything's possible.

The fact is that Java *can* be just as fast as C in practical applications (depending, of course, on the practical application in question). I've seen this in practice (much to the surprise of some of my C++-developing colleagues).

My opinion is that benchmarks are far too replied upon for JDK and JVM development. I know for a fact that there are optimizations in a variety of JVMs and JDKs that are targeted to improving benchmark numbers, from which few people will see an improvement in practice. Honestly, at this point, I think Sun's Java implementation's performance is good enough that in the short term, I would rather see JVM implementors focus on correctness and stability.
September 21, 2009 at 10:44 AM
Isaac Gouy said…
> Anything's possible.

You are over-generalizing from your current level of experience and workaday tasks, rather than considering a broader range of inexperience and mistaken notions and ordinary ignorance.

The comments I see show people looking at the benchmarks game are surprised how fast Java is compared to C.

The comments I see show people have little or no basis for their notions about how relatively fast or slow programs written in different languages might be - it's outside their experience.


> The fact is that Java *can* be just as fast as C in practical applications...

I don't have a problem with that as a claim - the problem is that the claim isn't demonstrated, instead we have Cliff Click showing "a simple Sieve of Eratosthenes".


> optimizations in a variety of JVMs and JDKs that are targeted to improving benchmark numbers

There is of course a tradition of compiler writers doing that - JVM implementors no doubt focus on what they find interesting and amusing as much as they can.
September 21, 2009 at 1:35 PM
Jeremy Manson said…
It doesn't sound as if we are disagreeing about anything, so I'll let your comments stand as written.
September 21, 2009 at 3:32 PM
Anonymous said…
It is rather interesting for me to read the post. Thanks for it. I like such themes and everything that is connected to them. I would like to read more soon.
November 17, 2009 at 7:51 AM
Post a Comment

Popular posts from this blog

Double Checked Locking

I still get a lot of questions about whether double-checked locking works in Java, and I should probably post something to clear it up. And I'll plug Josh Bloch's new book, too. Double Checked Locking is this idiom: // Broken -- Do Not Use! class Foo {   private Helper helper = null;   public Helper getHelper() {     if (helper == null) {       synchronized(this) {         if (helper == null) {           helper = new Helper();         }       }     }   return helper; } The point of this code is to avoid synchronization when the object has already been constructed. This code doesn't work in Java. The basic principle is that compiler transformations (this includes the JIT, which is the optimizer that the JVM uses) can change the code around so that the code in the Helper constructor occurs after the write to the helper variable. If it does this, then after the constructing thread writes to helper, but before it actually finishes constructing the object,
107 comments
Read more

What Volatile Means in Java

Today, I'm going to talk about what volatile means in Java. I've sort-of covered this in other posts, such as my posting on the ++ operator , my post on double-checked locking and the like, but I've never really addressed it directly. First, you have to understand a little something about the Java memory model. I've struggled a bit over the years to explain it briefly and well. As of today, the best way I can think of to describe it is if you imagine it this way: Each thread in Java takes place in a separate memory space (this is clearly untrue, so bear with me on this one). You need to use special mechanisms to guarantee that communication happens between these threads, as you would on a message passing system. Memory writes that happen in one thread can "leak through" and be seen by another thread, but this is by no means guaranteed. Without explicit communication, you can't guarantee which writes get seen by other threads, or even the order in whic
176 comments
Read more

Date-Race-Ful Lazy Initialization for Performance

I was asked a question about benign data races in Java this week, so I thought I would take the opportunity to discuss one of the (only) approved patterns for benign races. So, at the risk of encouraging bad behavior (don't use data races in your code!), I will discuss the canonical example of "benign races for performance improvement". Also, I'll put in another plug for Josh Bloch's new revision of Effective Java (lgt amazon) , which I continue to recommend. As a reminder, basically, a data race is when you have one (or more) writes, and potentially some reads; they are all to the same memory location; they can happen at the same time; and that there is nothing in the program to prevent it. This is different from a race condition , which is when you just don't know the order in which two actions are going to occur. I've put more discussion of what a data race actually is at the bottom of this post. A lot of people think that it is okay to have a data
53 comments
Read more