The myth of Java's slowness

[Joshua Cranmer]

Twice in the past week, c.l.j.p has seen two claims (actually, the same
one repeated twice) that "Java is slower than C." Outside of that, I am
continually pelted with complaints that "Java is so slow!" One example:

"Java is slow."
"Yes it is."
"Okay then, prove to me that it's slow."
"In the USACO [ an algorithmic programming competition ], the Java time
is scaled by a factor of 1.5 to be competitive."

The USACO problems are extreme:
* The time for a C program to run is 1 second.
Java is slow in the early part of its lifecycle; compare the same
metrics an hour or two into a program and the Hotspot optimizer will
make a noticeable difference.
* I believe that C is compiled with -O2.
Sun used to (still does?) provide an option to optimize Java code;
this was taken out because metering determined that the Hotspot
optimizer works better on unoptimized code.
* Problems are heavily IO-dependent.
This problem with metering has been explained in the other threads; I
am not going to repeat for the umpteen-th time.

A clearer example of what's going on here:
Planes are more efficient than rail, because a plane takes less time to
go between San Francisco and Washington, D.C. than a train would.

Obviously, this measure of "efficiency" is biased towards planes; I can
just as well bias it towards trains:
Trains is more efficient because it would take one train less time to
carry 10K tons of coal than a plane (the plane would have to go back and
forth over and over again; the train makes one trip).

Clearly, this shows the different design philosophies of air travel and
rail travel: air is optimized for high speed, whereas rail is optimized
for high capacity. Specifically metering one of these characteristics
gives heavily skewed results.

And that is why Java appears to be slow: people feed it problems
unwittingly optimized for native code (a combination of insufficient
teaching and misguided expectations). Java's full power comes in its
ability to easily achieve cross-platform effects. A Java fighter game
would have not only compatible source code, but compatible binaries for
both a Windows Vista dual-core machine as well as a Fedora Core 7 Linux
machine running on an AMD-64 chip. C cannot even use the same source
code, modulo complex configuration routines: an `int *' is a different
size on a 32-bit than a 64-bit machine.

Other areas of prowess are:
* Working across several regions of Unicode: C code needs to be
carefully handled to accept Japanese hiragana and Arabic characters at
the same time.
* Multithreading. Java has limited built-in multithread support; C code
does not.
* UI. Java provides a cross-platform UI set; C code does not.
* Dynamic method dispatch and runtime type information. C provides
neither without it having to be explicitly piped in; C++'s RTTI is, to
say the least, somewhat problematic.
* Memory management. C requires manual memory management, which makes it
easy to have poor memory benchmarks. Having some form of garbage
collection provided is becoming increasingly popular; Java has garbage
collection built-in (and improved for over a decade).

If I came up with a "benchmark" that showed that Java was the best in
handling multithreaded UI support using dynamic method dispatch that had
to handle Unicode properly, where the metrics were measured after the
programs had been running for a month, would you be surprised? Would you
cry foul that the "benchmark" was biased?

Just because C can print 1,000,000 lines of output 10 times faster than
Java doesn't mean that Java is slow. It just means that Java can't print
1,000,000 lines of output very quickly.

Measure the speed of C and of Java under most normal programs, and
you'll find that the difference between the two languages speed-wise is
negligible.

Please, don't give me another example of an esoteric, abnormal program
that no developer would ever include in one of his programs and use that
result to "prove" that Java is slow. I'll only respond by using another
similar program to "prove" that C or FORTRAN or PASCAL or whatever is slow.

 

[Kira Yamato]

Twice in the past week, c.l.j.p has seen two claims (actually, the same
one repeated twice) that "Java is slower than C." Outside of that, I am
continually pelted with complaints that "Java is so slow!" One example:

"Java is slow."
"Yes it is."
"Okay then, prove to me that it's slow."
"In the USACO [ an algorithmic programming competition ], the Java time
is scaled by a factor of 1.5 to be competitive."

The USACO problems are extreme:
* The time for a C program to run is 1 second.
Java is slow in the early part of its lifecycle; compare the same
metrics an hour or two into a program and the Hotspot optimizer will
make a noticeable difference.
* I believe that C is compiled with -O2.
Sun used to (still does?) provide an option to optimize Java code;
this was taken out because metering determined that the Hotspot
optimizer works better on unoptimized code.
* Problems are heavily IO-dependent.
This problem with metering has been explained in the other threads;
I am not going to repeat for the umpteen-th time.

A clearer example of what's going on here:
Planes are more efficient than rail, because a plane takes less time to
go between San Francisco and Washington, D.C. than a train would.

Obviously, this measure of "efficiency" is biased towards planes; I can
just as well bias it towards trains:
Trains is more efficient because it would take one train less time to
carry 10K tons of coal than a plane (the plane would have to go back
and forth over and over again; the train makes one trip).

Clearly, this shows the different design philosophies of air travel and
rail travel: air is optimized for high speed, whereas rail is optimized
for high capacity. Specifically metering one of these characteristics
gives heavily skewed results.

And that is why Java appears to be slow: people feed it problems
unwittingly optimized for native code (a combination of insufficient
teaching and misguided expectations). Java's full power comes in its
ability to easily achieve cross-platform effects. A Java fighter game
would have not only compatible source code, but compatible binaries for
both a Windows Vista dual-core machine as well as a Fedora Core 7 Linux
machine running on an AMD-64 chip. C cannot even use the same source
code, modulo complex configuration routines: an `int *' is a different
size on a 32-bit than a 64-bit machine.

Other areas of prowess are:
* Working across several regions of Unicode: C code needs to be
carefully handled to accept Japanese hiragana and Arabic characters at
the same time.
* Multithreading. Java has limited built-in multithread support; C code
does not.
* UI. Java provides a cross-platform UI set; C code does not.
* Dynamic method dispatch and runtime type information. C provides
neither without it having to be explicitly piped in; C++'s RTTI is, to
say the least, somewhat problematic.
* Memory management. C requires manual memory management, which makes
it easy to have poor memory benchmarks. Having some form of garbage
collection provided is becoming increasingly popular; Java has garbage
collection built-in (and improved for over a decade).

If I came up with a "benchmark" that showed that Java was the best in
handling multithreaded UI support using dynamic method dispatch that
had to handle Unicode properly, where the metrics were measured after
the programs had been running for a month, would you be surprised?
Would you cry foul that the "benchmark" was biased?

Just because C can print 1,000,000 lines of output 10 times faster than
Java doesn't mean that Java is slow. It just means that Java can't
print 1,000,000 lines of output very quickly.

Measure the speed of C and of Java under most normal programs, and
you'll find that the difference between the two languages speed-wise is
negligible.

Please, don't give me another example of an esoteric, abnormal program
that no developer would ever include in one of his programs and use
that result to "prove" that Java is slow. I'll only respond by using
another similar program to "prove" that C or FORTRAN or PASCAL or
whatever is slow.

Seriously, would you use java to write graphic intense applications or use C++?

Would you write the next 3D video game in java or in C++?

Would you write your next operatiing system in java or in C++?

Now go ahead and tell me these are just esoteric abnormal programs that
no developer would ever include.

 

[Daniel Pitts]

Seriously, would you use java to write graphic intense applications or
use C++?

I would choose Java of course, because it has a great (and constantly
improving) graphics library that is easy to use and portable between
Windows, Mac OSX, and the X platform (Linux/Unix)

Would you write the next 3D video game in java or in C++?

I don't write 3D video games. If I did, I'd probably start with Java,
using the Java 3D API that is forth coming.

Would you write your next operatiing system in java or in C++?

Actually, I probably wouldn't write it in either. I'd probably write
the Kernel portion in C (with a touch of assembly), and then implement a
JVM on top of that kernel and write the rest of it in Java.

Now go ahead and tell me these are just esoteric abnormal programs that
no developer would ever include.

Most programmers don't include those cases. If you're a game designer,
#1 and #2 might be interesting. If you're an OS designer, you might
worry about #3. Otherwise, those three examples (two of which I would
realistically choose Java over something else) are not that common.

To turn this around. How often do you write any of those?

 

[Lew]

I would choose Java of course, because it has a great (and constantly
improving) graphics library that is easy to use and portable between
Windows, Mac OSX, and the X platform (Linux/Unix)
I don't write 3D video games. If I did, I'd probably start with Java,
using the Java 3D API that is forth coming.
Actually, I probably wouldn't write it in either. I'd probably write
the Kernel portion in C (with a touch of assembly), and then implement a
JVM on top of that kernel and write the rest of it in Java.
Most programmers don't include those cases. If you're a game designer,
#1 and #2 might be interesting. If you're an OS designer, you might
worry about #3. Otherwise, those three examples (two of which I would
realistically choose Java over something else) are not that common.

To turn this around. How often do you write any of those?

In fact, Jake2, a Java clone of Quake, is 90-100% as fast as the C version.

 

[Christian]

On 2007-12-08 18:51:01 -0500, Joshua Cranmer <[email protected]>
said:

Seriously, would you use java to write graphic intense applications or
use C++?

Would you write the next 3D video game in java or in C++?

Would you write your next operatiing system in java or in C++?

Now go ahead and tell me these are just esoteric abnormal programs that
no developer would ever include.

We are back in the Airplane/Train section.
If you had a gigantic web-application would you write it in C++?
No not only abnormal programs ... its a question of what you want.
We often tend to advertise our language as the one for everything .. but
no language is.
The problme is sometimes just people bitching about other languages..
But we Java developers are happy with this, because:

"There are only two kinds of languages: the kind everybody bitches
about, and the kind nobody uses."
- B. Stroustrup

Oh isn't he wise? Listen to the Guru!

Christian

 

[Mark Thornton]

Seriously, would you use java to write graphic intense applications or
use C++?

Would you write the next 3D video game in java or in C++?

Would you write your next operatiing system in java or in C++?

All of those tasks have been done in Java. It isn't uncommon for games
to be at least partly in Java.

 

[Wojtek]

Kira Yamato wrote :

Seriously, would you use java to write graphic intense applications or use
C++?

If you have a cell phone, then most likely any games on it are written
in Java

 

[Arne Vajhøj]

Seriously, would you use java to write graphic intense applications or
use C++?

Would you write the next 3D video game in java or in C++?

Would you write your next operatiing system in java or in C++?

Now go ahead and tell me these are just esoteric abnormal programs that
no developer would ever include.

Actually only a very small fraction of programmers write
operating systems and games.

None of the mentioned apps would be written entirely in Java.

Not because of speed but because of the requirement for
hardware access.

The high level logic in games can be and has occasionally been written
in Java.

The low level graphical stuff can obviously not.

In theory huge parts of an operating system could be written in
Java.

Only the core parts that need direct access to hardware would
need something else.

It has never happen. But then the newest mainstream OS's are from
the early 90's, so there has not been much chance either.

MS did an OS with most of the code in C# as an experiment. It is
possible.

Arne

 

[Alan Morgan]

I don't write 3D video games. If I did, I'd probably start with Java,
using the Java 3D API that is forth coming.

[snip]

In fact, Jake2, a Java clone of Quake, is 90-100% as fast as the C version.

All benchmarks are dishonest. Some are dishonest in useful ways.

The framerates for these benchmarks are sky-high (except for the very
low end system). You are probably more bound by memory bandwidth and
video card performance than by CPU - so I'm not really surprised that
Java does well. It's worth noting that, on the low end system, Java
is being beaten by a much larger margin (although the benchmarks are
incomplete).

It's a really nice demo, but Quake II came out 10 years ago (jeez I'm
old). Is it really that surprising that today's technology can kick
the snot out of yesterday's games?

Alan

 

[Lew]

It's a really nice demo, but Quake II came out 10 years ago (jeez I'm
old). Is it really that surprising that today's technology can kick
the snot out of yesterday's games?

How is that relevant? If the code is pretty much a port of the "old game",
then they are comparable.

 

[Roedy Green]

And that is why Java appears to be slow: people feed it problems
unwittingly optimized for native code

But you are ignoring the fact you can also natively compile Java,
which is what I do for all the code I use internally. See
http://mindprod.com/jgloss/jet.html
Jet 6.0 is just out that supports JDK 1.6.0_03.

It takes the startup pain out of Java. Sun's Hotspot is optimised for
server side programs that run for weeks, so start up time is
immaterial.

 

[Thomas Kellerer]

Roedy Green, 10.12.2007 12:27:

But you are ignoring the fact you can also natively compile Java,
which is what I do for all the code I use internally. See
http://mindprod.com/jgloss/jet.html
Jet 6.0 is just out that supports JDK 1.6.0_03.

It takes the startup pain out of Java.

I tried to compile various programs (Swing, commandline) using the demo
version of Jet and none of them started quicker compared to starting
them using the JDK. My understanding is, that the startup time can only
be reduced if the number DLLs used by the JVM are reduced, and to my
knowleged JET does not bring it's own optimized JVM.

The second startup of a Swing application is usually a lot faster than
the first due to caching of the files by the OS (at least on Windows
this is the case).

Thomas

 

[Roedy Green]

Would you write your next operatiing system in java or in C++?

Look at the proliferation of Java in small devices like cell phones
and hand held units. Java-based OSes have enabled the explosion of
portable software.

You need tiny bits of assembler or C to poke device registers, but
most of an operating system is just housekeeping -- Java's forte.

The other thing is advances in optimisation mean HotSpot and Jet will
beat hand-coded assembler. It is a John Henry situation. Yes John
Henry could beat a steam engine with superhuman effort, but he could
not keep that up hour after hour. You can optimise using tricks that
would be obscenely unmaintainable when you let the compilers do it.

Consider something like a the code to do bit/blts. You pretty well
have to do that in assembler to make sure you generate optimal code
for the quirky hardware instructions. But your whole app does not
have to be.

 

[Lew]

Roedy Green:

I tried to compile various programs (Swing, commandline) using the demo
version of Jet and none of them started quicker compared to starting
them using the JDK. My understanding is, that the startup time can only
be reduced if the number DLLs used by the JVM are reduced, and to my
knowleged JET does not bring it's own optimized JVM.

The second startup of a Swing application is usually a lot faster than
the first due to caching of the files by the OS (at least on Windows
this is the case).

The newest Sun JVMs use class-sharing and other techniques to improve (at
least perceived) startup time for desktop apps. Whether or not they work is
another matter, but Sun's literature suggests that in their tests it makes a
difference.

 

[Mark Thornton]

In theory huge parts of an operating system could be written in
Java.

Only the core parts that need direct access to hardware would
need something else.

It has never happen. But then the newest mainstream OS's are from
the early 90's, so there has not been much chance either.

http://www.jnode.org

 

[ldv]

Roedy Green, 10.12.2007 12:27:



I tried to compile various programs (Swing, commandline) using the demo
version of Jet and none of them started quicker compared to starting
them using the JDK. My understanding is, that the startup time can only
be reduced if the number DLLs used by the JVM are reduced, and to my
knowleged JET does not bring it's own optimized JVM.

The second startup of a Swing application is usually a lot faster than
the first due to caching of the files by the OS (at least on Windows
this is the case).

Thomas

Well, it takes some effort to reduce the startup time with Excelsior
JET:

1. Before compilation, do an extensive Test Run in order to gather
information about the used classes.

2. Use the Global Optimizer (selecting the "Smart" preset on the
Classpath page may be enough.)

3. Use the Executable Image Optimizer.

Another point is that small applications often start slower, whereas
for large applications you can get up to 2x reduction in startup time
using the above technique.

If the above does not help, I am sure that Excelsior engineers would
love to hear from you. You may email them direct at java at excelsior-
usa.com

LDV