Slashdot Mirror

> I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python.

Well, Python is a different game than Java or C#, which both have a much better JIT-compiler.

I mainly program in C++ (real-time data processing), but I feel hard-pressed to believe, that Java has to be severely slower than C++ in numeric computations. The Java implementations of FFT and LinPack suggest, that comparable performance should be possible. The SciMark 2.0 should also be more up to par, when you replace the synchronized Random in the benchmark with a Java implemented Mersenne Twister.

Amazing claims just plucked out of the air:

-Best virtual machine
Certainly not on performance: http://www.shudo.net/jit/perf/ Java smokes it.
Certainly not on platform support: linux, solaris, windows, Mac, Mainframe etc. supported by Java

-Best IDE
That is debatable:
www.netbeans.org
www.eclipse.org

-Click once
Java has had that for years. It's called web start. Where did MS get that idea.... ?

Java is already fragmented. The result of open sourcing Java will actually be consolidation, i.e. killing of competing VMs. And a huge open source test suite will greatly benefit all surviving JVMs, which is a good thing.

How can you not see this?

Javas problem is not that it might get fragmented, the problem is that it IS fragmented. Do something about it! Let Java free!

Might interest you: http://www.shudo.net/jit/perf/#scimark2

Then we run a simple benchmark on real data of the codes, and the C++ variant is 10x or faster than the Java variant.

This is simply bad coding. This kind of thing often happens when the Java is written in a more OOP way than the equivalent C or C++ applications. Even C++ can be made slow by such coding.

Java is not slow. There are some standard international benchmarks used to test language speed. One of them is Linpack:

http://www.shudo.net/jit/perf/

Typical results (MFLOP values - the higher the better):

C/icc (-O3 -xN) 402
C/Visual C++ (/Ox /G7 /arch:SSE2) 399
C/gcc (-O3 -funroll-loops) 393
Java/Sun JDK 1.5.0 Server VM 379
Java/Sun JDK 1.4.2 Server VM 379

Java is within a few percent of gcc speed, and pretty close to better C compilers.

I remember exactly the same arguments raised against C++ in the 80s - it was 'too slow' to use compared with C. It was all a matter of coding style.

http://www.usenix.org/publications/library/proceed ings/javavm02/full_papers/jacob/jacob_html/node12. html

http://www.shudo.net/jit/perf/

IBM's VM looks very favorable in these tests. You can get it for Linux (also available for windows and other platforms) here:

http://www-128.ibm.com/developerworks/java/jdk/lin ux/download.html

Enjoy!

Taft

People repeatedly demonstrate that Java is as fast as C.

Indeed.

They do this for the same reason that members of religious groups keep having to tell themselves that their prefered creator of the universe is better than anyone else's

Er - I thought demonstrating that Java is as fast as C is not a matter of faith... there is evidence.

Write some CPU intensive code in C and Java yourself and report back.

Righto. Here you are:

http://www.shudo.net/jit/perf/

And don't just write some silly benchmark that tests out a tiny part of the optimizer. Write some well rounded code that does a mixture of different things.

This sounds very much like the Intelligent Design debate - you get to define any code that anyone else writes that shows that Java can match C as 'not well rounded enough', so that you never lose the argument.

So when C starts to lose its advantage on the 'processor intensive' benchmarks (like those
above) you move the goalposts....

However, why not look at Hypersonic - it is full-featured SQL-compliant relational database written in Java - should be well-rounded enough, surely.

It is fast.

a few seconds?! even SWTed Eclipse begs to disagree. Many very useful perl batch scripts are done while most Java apps are still loading!

This is true. Java is not an appropriate language for for small apps that only take a few seconds (or milliseconds) to run. However, there are other performance issues with eclipse - SWT is not the fastest of systems.

Which run thoughroughly simplified GUIs and the like. Let's focus on real everyday stuff running on current desktop systems, ok?

This is irrelevant. The point was to show that Hotspot is not a CPU or memory hog. As for 'simplified GUIs', these platforms aren't simple at all - they have 3D drawing APIs, some of which are implemented in pure Java.

You can take a look here and compare for yourself:
http://shootout.alioth.debian.org/

Which I have seen, and is missing the point. As I have already discussed, the optimisation in Java takes some seconds to kick in. Most of what you are dealing with in these benchmarks is the startup time of the JVM. This is like comparing the performance of two different operating systems but neglecting to exclude the boot times.

In a recent Slashdot thread I showed that if you ran benchmarks like this for 5, 25, or 100x longer then Java easily caught up with C in most cases.

Here are some benchmarks that run longer and illustrate what I mean:
http://www.shudo.net/jit/perf/

decades?! Java itself is barely 2 decades old, JITting is a pretty newer technique and the "Hotspot" compiler has just came out a few years ago. I think you making things up in order to give your arguments some substance they lack...

No, you are misinterpreting me. I am not saying that Hotspot has been around for decades, I am saying that the optimisations it uses have.

The compilation time, the library loading times, the Garbage Collector thread cycles, some eventual runtime introspection techniques... the actual scenario is a lot worse than what you paint it to be.

You simply can't say this without evidence. Repeating that this 'must' impact performance is meaningless unless you can show that it actually does. I have already stated that the compilation time can be over with quickly, and the fact that Java can be used for high-performance real-time applications shows that garbage collection does not have an impact. After all, there are now modern garbage collectors that can be used with C and C++ - they usually have little impact when used in place of 'manual' memory handling, so which should things be any worse for Java?

Which also means the optimizer is up and running and consuming memory and cpu cycles.

Only 'every now and then', and as I have already discussed, the optimiser runs fine and with little impact on performance even in low memory and slow CPU systems.

"It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds."

hmm, perhaps this influenced the java benchmarks above? i don't know.

Absolutely. If those benchmarks were run for 10 or 100 times longer, I suspect the results would be very different. When I have tried one or two of them, they certainly have been.

well, then i guess this will likely be the longest running _dialogue_ *nobody* in slashdot has ever witnessed... :)

No - because I always beat opponents in the end - through boredom if nothing else!

Not a big fan of Java, slow,

No, especially not server side. Reaches within a few % of C++ speed in well-established benchmarks:
http://www.shudo.net/jit/perf/

bulky,

No. It can run within a few 100k on mobile devices. Non-GUI java apps can run in just a few MB.

not user friendly.

A vague term, which could mean anything.

Well get the lawyers out. Here are some Java vs. Net bencharks from a year ago:

http://www.shudo.net/jit/perf/ [shudo.net]


No offense, but that is not the current .NET technologies that developers like myself are using, nor the technologies they are being used in Vista, nor are these even the .NET technologies that are being used on the XBox 360.


Sorry I don't have time to write it myself, but here is one:
http://www.bytonic.de/html/jake2.html. A version of Quake in Java.

I was kind of excited, until you actually fact check the program. "Jake2 uses jogl for OpenGL graphics and joal for 3D sound."

This is a front end application using OpenGL for graphics and jaol.

I could write a Visual Basic application using OpenGL or DirectX as well that would perform just as well, this is NOT JAVA handling graphics, this is JAVA using OpenGL for graphics.

Do you not realize there is a 'difference'?

Part of the DirectX foundations and 'video' access itself is writeen in Managed .NET, This is NOT .NET just calling DirectX, but .NET is a part of what .NET is build with.

Using OpenGL or DirectX from any language does not mean the language itself is fast. I could actually harness DirectX from a very simple Visual Basic application, and do some incredible game processsing, does this mean Visual Basic is the best performaning development environment also?

Maybe you should find an example where JAVA has replaced OpenGL for graphics output, and then you would have a comparable argument, until then. Bzzz....

None currently exist my friend, since the current version of .Net technology's NDA prohibits benchmarking. If you magically have some, then I'm sure a lawyer would like to talk to you. 8P

Well get the lawyers out. Here are some Java vs. Net bencharks from a year ago:

http://www.shudo.net/jit/perf/

How about this challenge since you think what I said was nonesense, write us all a cute java application that can render full scenes in 3D in realtime at near toy story quality. Then I will say, yep I was wrong, .NET isn't the only managed development environment that can do this type of performance.

Sorry I don't have time to write it myself, but here is one:
http://www.bytonic.de/html/jake2.html. A version of Quake in Java.

Actually I would be happy to see a version of Solitaire in Java that the cards moving around the screen didn't drop a 3Ghz P4 to a crawl...

Perhaps you would like to back this up by giving the name of the specific solitaire program so we can test it and check the processor use while moving cards?

That's the thing that annoys me about a lot of Java performance talks. The folks who defend it provide a lot of theory, talk about xxx JVM being faster, XXX app being faster, roundabout arguments like that.

What theory? I am talking established fact. The newer JREs ARE faster. Let me show you some java numerical benchmarks:

http://www.shudo.net/jit/perf/

Java 1.5.x is faster than Java 1.4.x which is faster than Java 1.3.x

You can provide all the hypothesis and conjecture you want.

It is not hypothesis or conjecture. There are demo applications provided with each Java JDK. Try them. Time them.

Hundreds of millions of instructions per second on a heavily multi-pipelined CPU backed up by a gigantic multi-tiered cache system and a gigabyte of RAM, and this is the best I get?

This is tedious. I heard exactly the same arguments false arguments against C++ 20 years ago. There was a myth that C++ (as against assembler) was slow, so many users and developers had convinced themselves (after experiencing a few badly written apps) that it was, and that it could never be practical.

Cut the crap. My computer has 512MB DDR RAM, and each time I use a Java application it starts swapping LOADS. The computer is nearly UNUSABLE due to all swap usage.

Strangely, mobile devices can run java in just a few 100k. The Java 5.0 VM itself can run in just a few MB.

Write a simple Java 'hello world' program, and you will find it can run in just a few megabytes (use the -Xmx switch to set the max usage).

So the claim that your machine will swap 'each time you use a Java application' is provably nonsense.

I'll start Eclipse, to tell you how much RAM the JVM will use (it might be a shock for you!).

It's an IDE for goodness sake! They are some of the largest apps.

Mind you, the NetBeans IDE can run quite happily in moderate memory. In fact, if you look at the IDE config file for NetBeans 4.1 you will see that the IDE is by default not allowed to use more than about 90-100MB.

In fact, I have just started it giving it a maximum memory of 64MB.

Try it yourself! I am using Java 1.5.0_04 and NetBeans 4.1. The configuration file within the netbeans install directory is etc/netbeans.conf.

So, on a 512MB machine, it isn't causing swapping. (It never does on my PCs, which have this memory).

Saying Java is performing nearly as fast or even faster than C++ is BULLSHIT.

If it is, then it is bullshit backed by considerable evidence. Last year there was a study of java speed for numerical work, using the well-known Linpack benchmark:

http://www.shudo.net/jit/perf/

Java 5.0 usually came within 5-10% of optimised C++.

So, I am sorry, but you are plainly factually wrong.

If you don't believe me, again, try it yourself. The source code for these benchmarks is available.

You may also be interested to know that Java is now so fast it can be used for real-time device control and AI systems. Boeing use Java for robotic and autonomous experimental planes, and one of the entrants for this years robotic road race has its software entirely in Java.

Doing a quick google search it appears that C# often beats Java or shows comparable performance in most tests. That is unless you're a Java zealot who bases opinions on limited and unfair tests.

In real-world applications, C# matches up quite well to Java's speed.

For what kind of applications? If you are talking about pure speed, java is certainly not even 75% as fast as C...

Yes it is.

If you want to compete with some algorithm let me know - I'll do the C implementation and you'll do the java implementation, and then we'll see the difference...

This page includes results for a well-established benchmark for math processing - Linpack.

http://www.shudo.net/jit/perf/

It shows Sun's JDK 5.0 being more than 90% of the speed of C/C++.

Oracle, Slow?

Are you mad?

Sure, the instalation software is crap, but I dont think you can blame java directly.
If I wasn't at work I would do a little googling around for performance comparisons.
For reasons like your statement above I did some research a year ago as I was doing some java development to see just how slow java was, and, yes, the first many releases of java were quite slow, but the latest version are not.

Sure, its not as speedy as a C program, but its not designed to be. Ill take the developement cycle and portability ease in most situation that dont require absolute speed.

I have done solar simulations in java with advanced mathematics and OpenGL and they have been very speedy. Just need to do it proper.

Bah.
Here.
This is just one of many articles actually comparing performace: Take a look at the benchmarks, SciMark 2.0 (in Java, C# and C) being the easiest to deduce results.

Clearly Java is faster than even C in some cases, and almost always faster than C#. Momo doesnt even compare, so portability is very inefficient.

Java is awsome, for the right purposes. Dont bash it.

The net is littered with old pages filled with comparisons between C and Java running the 1.1 VM on Windows 95. These benchmarks were done years ago, and do not interest me.

More recent benchmarks are available that give more relevant results. The first thing to note is the sheer number of VMs tested in this benchmark alone, and the vast performance differences between them. Saying things like "this horrid VM system" means nothing - it's like you're complaining about "this horrid car". Which car?

VM to VM comparison handled by the SPEC JVM98 is not interesting in our discussion, though it does illustrate the point that not all VMs are equal. More interesting is the Scimark 2.0 in Java, C#, and C/C++. It is worth noting that, on average, C/Visual C++ comes out on top, but only by around 1-2%. In second place is 1.4.2 JDK, third Sun's 1.5.0 JDK (both server VMs). The top benchmarks are 329/324/316 respectively, and then we start plumetting into 266 for gcc/-O2, a handful of JDKs, and then C#/.NET(release) down at 240. That's native code, just so we're clear.

So, at least in that benchmark, Sun's Java VM is comparing quite nicely to both other VMs and native code.

Linpack is more interesting, because it was run for both 500x500 and 1000x1000. In 500x500, native code is indeed faster, by a good margin. The 1.5.0 VM is about 1/3 lower than native compiled C code. But looking at the 1000x1000, you'll see the the VMs and native code are neck and neck, barely any difference between them. That is where my statement about large scale applications came from, though doesn't really illustrate my point as well as I'd like.

The last benchmark, the Eratosthenes Sieve, simply demonstrates the vast differences between VMs, and that Java obliterates C#. No surprises there.

I hadn't seen this report before I posted here. I looked it up to make a point, and hopefully you can see my point. In no case is Java "running like a slug" compared to native code.

There are lots of other reasons why you experienced slowness in your applications. The GUI being used, your choice of VM (surprisingly, native compiled Java code using GCJ often underperforms bytecode run in a VM!), or perhaps, even the quality of the code being run. It is quite easy to program something in a sloppy way that will reduce performance.

So, I simply disgaree, and would very interested to hear of a benchmark in which a recent, performant Java VM vastly underperformed a native implementation of the same algorithm. To my knowledge, Java compares quite well in 95% of applications.

And for P2P, well, what can I say? We're not exactly taxing our systems with a P2P app, now are we? I would think it would be FAR more important that you can make a cross platform P2P solution than egding out and extra 2% performance on the GUI response time. After all, it *is* a network, and we want it running in as many places as possible.

Oh, and for the record, I'm not a Java zealot. I'm an open source/free software zealot, and for that reason, don't like the rather closed nature of Sun's VM and libraries. You can call me a Python zealot though, since Python is my language of choice for personal projecs. I only use Java for professional projects.

If you have a benchmark that compares the two VMs in a similar setup (e.g. Blackdown 1.4.2 HotSpot Client VM vs. Sun 1.4.2 HotSpot Client VM on the same machine) and Blackdown loses, then please mail me a link.

You are right, the benchmarks i saw are old. I don't really understand what the blackdown project is about, since other than having ports (the most useful would be the ppc port since java on mac linux is only done otherwise by ibm). The most recent java benchmark i have seen is here yet they don't address blackdown (but it says it was evaluated)

You guys need more marketing :) How about publishing those benchmarks? Or would that break a NDA or something?

Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.

No. It is to do with the practical ability to move code between VMs and JREs. The 'Java' brand indicates that you can do this. I don't know how to prove that Sun's VM passes the test, but I know that it does. Why? Because thousands of developers rely on the compatibility, and it works. You can label it 'marketing' if you like, but that does not remove its practical effectiveness. If it did not work, this would be a major news story and Java's reputation would crumble.

Anyone who wants to test any part of Java can join the JCP (it is free) and download the test tools.

It was not just me who said that Kaffe was incompatible - just take a look at that benchmark page:

http://www.shudo.net/jit/perf/

"Kaffe does not work correctly with the applet version of SPEC JVM98". That is just one example.

However, I have just seen a screenshot of Kaffe running Eclipse - that is impressive! But, as a commercial developer, I need that Java brand. I need to be able to guarantee (or at least foolishly believe that Sun guarantees) that the Java implementation will run my apps with no code changes and no problems. I can't risk putting major enterprise apps on Kaffe and just hope; no matter the quality of the coding.

Possibly, but gcj is not complete and suffers from its own problems. Additionally, it is much slower than the JRE from Sun. Look at the stats to see how various free and not so free runtimes perform. Note that the likes of Kaffe & GCJ run at a mere fraction of the runtimes from Sun & IBM.

99.99% of Java programmers couldn't care less about GCJ. The Java JIT'ers beat it hands down:
http://www.shudo.net/jit/perf/
Even MS C# beats GCJ. GCJ is one of the slowest Java implementations around. Even Mono is faster!

The problem is not the architecture but the OS. The perfomance impact on context switches is mostly in changing the memory space (TBL, cache flush). Just two people developed an OS that runs all programs in the same space, so the processor keeps running at full speed. It can do this because it's written in a safe language (Java, but could be C# or other) so nothing can write to arbitrary addresses.

Despite being written in Java by just two people instead of the thousands that wrote the Linux kernel and optimizing C compiler, it is 50% the speed doing actual work. For comparison, commercial JVMs generate code that ranges from 2x-5x faster than gcj (gcc's java compiler) so this OS could easily be much faster than Linux. The only hold-up is drivers and support for archaic C/UNIX style programs (they should put it into the linux kernel as a module and gradually replace linux code with sane OO code).

Sorry, Perl is a compiled language, not an interpreted language

You're half right - Perl is compiled into byecode which is interpreted.

can you say JIT ?

JIT compilers compile to machine code - Perl doesn't uses a JIT compiler.

If you want to compare the performance of 2 things, you don't do it by having a theoretical discussion of their features.

It should be fairly easy to accept that a JIT compiler is going to produce faster running code than a bytecode interpreter. Anyway, here are some benchmarks (sorry, no Perl).

Often the JVM will out-perform GCJ with a factor of 3. Check out the numbers on this page.

I fail to see why people want to run a GCJ compiled evrsion of a development tool and run at at one third of the speed of the JVM, just in order to save a few seconds of startup time.

Why use gcj? One might assume that compiling to native binaries is faster than using a JVM, but benchmarks don't agree.

My own tests have supported this conclusion. Implementing the same simple algorithim in Sun's Javac/Java, ecj/Java and g++/C++ shows that ecj's code is not only slower than g++'s, but slower than Javac's too. My theory is that java's arithmetic primitives involve additional semantic information (like the possibility of overflow exceptions) which ecj isn't smart enough to optimize away.

GCJ programs tend to use less memory than one in a JVM, but this is an area that future JVMs can improve upon (and in general, once people start using the same VM for multiple java programs, this will get better).

A quick scan seemed to indicate that Sun's HotSpot, IBM's JVM and GCJ all do very well.

• They tested an old version of gcj. gcj 3.1 beats the Sun and IBM JDKs on SciMark. It also wins on the "primes" test once you change it to use int and not long; this is a known gcc weakness.
• In general we haven't done a lot of performance tuning. There is still a lot of room for us to improve.
• You can see a much better (IMHO) comparison of gcj with other VMs here.
• Contrary to what one poster said, my understanding is that gcj has better I/O performance than the Sun JDK.
• It is true that gcj is missing AWT (though much progress has been made on that front recent, we still aren't there) and some other things. However, it is still useful for many things.