Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby. And some of our tests.
Demystify Java performance Myth
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I wasn’t surprised by the math performance. I was able to get break even performance of C versus Java back in the JDK 1.2 days. I was surprised by some of the other results. What’s the problem with Swing and other GUI code then? Could it be the initial compilation that has to be done each and every time the app runs before it becomes native speed? Should Java do a compile once option like the .NET CLR to get around this issue?
a) The Javalobby thread actually compares the 1.5 runtime with the 1.4.2 runtime. C isn’t mentioned anywhere.
b) The Java vs C benchmark that tries to benchmark a method call is, for all intents and purposes useless. A method call on the server VM isn’t going to be 10x faster than in C. What’s probably happening is the VM is optimizing out the method call.
Otherwise, these benchmarks don’t show us anything new. We already know Java is fast enough, faster than C in some cases. What would be more interesting is the memory consumption, but that’s another story entirely.
I was surprised by some of the other results. What’s the problem with Swing and other GUI code then? Could it be the initial compilation that has to be done each and every time the app runs before it becomes native speed?
Swing is fairly overengineered and is I/O bound at startup because it has to load a lot of classes. That is why Swing apps have slow startup times and one of the ways to optimize this is to use lazy instantiation[1].
[1] http://www.javaworld.com/javaworld/javatips/jw-javatip67.html?
Examples that pure calculation code can be efficiëntly executed mean nothing. Those can be mathematically analysed and compiled into as efficiënt assembler code as C code can be.
Just find some hard stuff, like trees of ringbuffers etc. Or simply strings and text processing. Or simply a compiler. Or just find an example that stresses the memory management.
There is NO way Java can be competitive in these tasks. It simply is the wrong language for it.
I did not look close at the benchmarks suggesting that “java” is faster than “C” or “C++”. But whatever they show, they do not indicate that “java” is faster. That is impossible. Theoretical reasons for this are for example that all java implementations (all that I know and not counting the library side) are written in C. Something which is written in C can not be faster than C.
Another thing is the extraneous interpretive step in program execution which happens (mostly) with java. The overhead of program interpretation done by the virtual machine can not get below zero.
Then there is the missnaming of things in the document linked as “here are”: It was not tested C++ against java, but rather one particular implementation of C++ against one implementation of java. Documents like such as this one are not very respectable.
P.S:
Maybe the times with gcc are worse because gcc does not automatically inline functions at -O2, and the code does not employ the inline keyword as far as I can see.
P.P.S:
See this quote in “here are”:
On the other hand, -O3 performs space-speed tradeoffs, and -O performs fewer optimizations. Thus, for these tests, I think -O2 was the best choice.
Does not let one think that the author is competent. For these few lines of code, of course you would easily trade space for speed.
I was just reading about Quick Silver primitives collection http://www.churchillobjects.com/c/13003.html.
I had heard about problems in Java because of memory overhead related to averything being an object. Quick silver implements many Java colletions using primitives which is very useful in some cases.
Yep.
Speaking of language pls. take a look at:
http://sources.redhat.com/rhug/
and search for ecj. That is one Java->Byte code compiler written in Java that kiss ass as getting it vs Jikes (C++).
Just to inform that such piece of engineering can be accomplished in java.
These contrived tests continue to be ridiculous.
How about an real test – write a web browser that renders XHTML 1 compliant pages.
The story seems to suggest that Java is on par or even faster than C. Where does it ever say that?
The FreeTTS paper claims (in the abstract) that they got better performance with their Java engine than another engine “using similar algorithms written in C”. However, in the rest of the paper, they are continously optimizing the Java engine, without listing any changes to the C engine. This makes _very_ suspicious that, in their final results, they are comparing apples to oranges.
I’ll skip the Java vs. C++ comparison – I have yet to see a compiler that generates C++ code that is as efficient as it could be (as in, looking at the instructions it generates, I can easily point out inefficiencies).
The JavaLobby article doesn’t even ever mention C. They are comparing Java 1.5 to Java 1.4. Proofreading, anyone?
Of the other linked tests, one of them doesn’t mention C, but shows C++ to be quicker than both Java and C#, and the other shows C to outperform Java.
There are certain optimizations that can be done at runtime that cannot be done at compile time. You can get some of those optimizations with profiling, but optimizations across shared libraries, for example, are not possible with static compilation.
Also, there are certain cases where garbage collecting is faster than new/delete or malloc/free. For example, if your program allocates many short-lived small objects, a stop-and-copy GC would free all the dead objects in one go, much faster than delete or free would free them each individually.
Correct me if I am wrong, but Java is a language as is C. THE JVM may be written in C and the compiled to produce the JVM.
But for speed you are really comparing the binary code produced by the C compiler versus that of the JVM.
Performance?
Please inform me if it can compile faster than Turbo Pascal.
Compiling is a task that is not efficiently done in Java.
… Something which is written in C can not be faster than C.
Another thing is the extraneous interpretive step in program execution which happens (mostly) with java. The overhead of program interpretation done by the virtual machine can not get below zero….
This point has been beaten to death a million times. Java isn’t purely interpreted. A JIT was introduced in 1997 with the advent of Java 1.1.
Current VMs profile code at runtime before optimizing them into machine code. This is something that a statically compiled language can’t do. Certain C++ compilers try to emulate these features by introducing profile guided optimizations (PGO). Thus you only get slow performance during startup and the subsequent warm-up period when the VM is profiling code.
To claim that Java can’t run faster than C (or C++) because its written in those languages doesn’t make sense. Its like saying steel can’t be tougher than iron or carbon because its made from them (ok, bad analogy…).
Performance?
Please inform me if it can compile faster than Turbo Pascal.
Compiling is a task that is not efficiently done in Java.
No, but it compiles a lot faster than C++ or even C. This is rather subjective but it seems to hold true for GCC and MSVC on my machine.
first dam spell checker, it should be “kicks”.
Anyway the point was Java as a language can be used to write very fast compilers as the guys at Eclipse & Red Hat proved.
Second I haven’t used Turbo Pascal in ages and I don’t think it will even run on a recent CPU as it had an ugly clock related bug. Even more the Turbo Pascal compiler will compile Pascal code as ecj will compile Java code so comparing them will not make sense.
So, I just pointed out that a compiler written in Java can be efficient compared to one written in C++
Your assumption that, because the jvm is written in C, no java program can be faster than a C equivalent is wrong. For certain situations, runtime optimizations can beat anything the static analysis done by a compiler would achieve. Read this: http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html , then you’ll understand why.
There are a few replies to my post which seem to misunderstand it a bit.
At Anonymous (IP: —.client.comcast.net):
All what you write is true, but it does not contradict what I have stated. Of course if you analyze program input at runtime you can optimize certain parts of the code. But this does not render away a preceding step of program/bytecode interpretation. And this preceding step can not consume less than zero time.
(Check llvm for a C++ implementation which does runtime optimization)
At Wee-Jin Goh:
For your second point, please read above. And, there are no statically compiled *languages*, there are only statically compiled *programs*. I for one would be very grateful if there were be more good C++ interpreters for example.
For you first point, I did not say there don’t exist JITs. I know there are. But a JIT is just another example of the issue I discussed. A JIT minimizes the time spent for program interpretation, but it does not eliminate it.
For your final point, I stand by my assertion. If you use C to implement something, your performance is bound to C. Look at one extreme case, in where some program (written in java for example) can be optimized to one single dump of output to the console, without any additional computations being done. The Optimizer would have done a perfect job. But still, the console output routine is written in C. So the java program can not be faster than a C program which executes the same dump.
At flynn:
No offense intended, but you did not read carefully enough. I did not speak of runtime optimization. Compare with the above, I hope that will help to clarify.
The link you gave is interesting, nonetheless…
(Btw., what you named an “assumption”, is, technically spoken, not an assumption but a whole implication)
While I agree that with the exception of very specialized cases Java will never be faster than C, I believe you are making some false assumptions, yes assumptions. You take for granted that because the JVM is written in C that no Java application can be faster than C. Where this assumption is false is that a jvm can optimize the code to a certain extent. By your argument a C compiler, say gcc, could never compile itself with different optimizations to run faster.
Second a JIT compiler does increase the up front cost of execution of a program but the whole point of JIT is to increase the overall speed, thus mitigating the cost by performance improvement over the runtime of the application. (llvm uses a JIT compiler as well BTW)
As far as the first link, the performance imporvements likely have little to nothing to do with the performance characteristics of Java. The code was tightened and optimized which is where the performance difference came from. Java may or may non have made the optimizations easier but I would argue it has little to do with the efficiency of the compilation.
For you first point, I did not say there don’t exist JITs. I know there are. But a JIT is just another example of the issue I discussed. A JIT minimizes the time spent for program interpretation, but it does not eliminate it.
What does a JIT do? It compiles bytecode into native code. Sure, it doesn’t eliminate the overhead of a VM, but that’s only during the first time the method is invoked. Subsequent invocations will not be interpreted.
For your final point, I stand by my assertion. If you use C to implement something, your performance is bound to C. Look at one extreme case, in where some program (written in java for example) can be optimized to one single dump of output to the console, without any additional computations being done. The Optimizer would have done a perfect job. But still, the console output routine is written in C. So the java program can not be faster than a C program which executes the same dump.
That reasoning is flawed. Why then does Java manage to beat C in numerical computing? After all, Blackdown JVM on Linux is compiled with GCC, yet it manages to perform better than GCC on equivalent numerical code (discount trigonometry since Java 1.4 implementation is flawed).
Your assumption will hold true if all the JVM did was perform a one-to-one mapping of each Java function call to an equivalent C function call. But that is not the case. The JVM generates native code and as such is completely independent of the compiler used to produce the JVM.
I do agree with your previous assertion that this is benchmarking an implementation of Java with an implementation of C++. There is nothing inherent in either language that would make them slow.
I usually find Java programs fast, except for an occasional GUI program, but even that seems to be the fault of the programmers, since some Java GUI programs are perfect.
But if multiple programs are running multiple VM’s on my system – that seems to be an issue. Am I off base?
Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby.
I’m sure Java 1.5 has improved, and I’m sure you could optimize Java and pure .Net code to be pretty fast as has been done here – by not doing very much.
Ultimately, that doesn’t prove a damn thing because producing a usable, efficient application, set of applications or a desktop is on the other side of the universe compared to this. You can’t just perform pointless bubble sorts and come up with average times because that’s not what people will be using Java for.
The killer is developing a large application, with all of the memory and resource requirements that entails, and not only that, but running three or four of them on the same computer at the same time (or heaven forbid – an entire desktop). That is the acid, human test, and Java is very, very, very, very slow here. Do people still not understand that?
Can a VM-based environment cope with that? Probably not, but .Net has not been proven in such a scenario at all yet and people are not touching Java on the client because they just haven’t been able to do it. If it was good enough in these scenarios then rest assured, people would be using it. Java may well have been improved more recently, but the opportunity has been lost. Benchmarks like this are not going to change that.
nedit (www.nedit.org) and jedit (www.edit.org)
which one is the faster ? (I don’t mean the one with the most option), I meant the one which is the faster as you type into
the window, as you scroll the content… (nedit if you ever wonder)
maybe java is fast but nor its gui backend is under X11…
I know I’m talking about gui backend of java and not of the java core… if just for talking, people love flamming about benchmark, so do I….
The story seems to suggest that Java is on par or even faster than C. Where does it ever say that?
Blanket comment from Java vs C comparison:
comment: java (Suns standard JVM) is much more fast than the C-code compiled with standard gcc.
Fantastic grasp of English there
.
You’re right though. Looking carefully at some of these the findings and results doesn’t reflect what they are saying.
If it was good enough in these scenarios then rest assured, people would be using it. Java may well have been improved more recently, but the opportunity has been lost. Benchmarks like this are not going to change that.
I’m a java developer for a growing company, and let’s just say that we’re porting over our current in-house desktop applications from VB6 to Java. Java runs fine on the desktop (Swing and SWT) and I’ve been using Java desktop programs for a few years. Why are we porting? Because Java is honestly one of the most extensible, well-built and mature languages that you can use for business applications. You can write almost anything in Java, for almost any platform, and you can still keep a single code base. That is far more valuable to businesses than people’s perception that java is slow.
I installed the latest version of the Ipedo database a few days ago. It takes over 550MB of memory without any databases loaded. When I load a large document (10MB) into the database, my entire dual Opteron system comes to a halt as the “made with Java” database goes into memory fits. CPU usage spikes and the machine is not responsive for nearly 5 minutes. Memory usage spikes at nearly 800MB for some unknown reason.
Java performance is an oxymoron. Sun funds Java because it sells more hardware. It’s that simple.
Many above have stated things about how runtimes often beat static languages on certain things where the runtime is highly optimized. This is certainly true, however when I have discussed things about Java with people who are very familiar with it and adament that it is God’s gift to coding (maybe not that zealous) they constantly remind me it is a Virtual Machine and not a runtime. I also once found on Sun’s site that they were designing a physical Java machine. So, my thoughts today are that Java may be the ultimate CISC; even though it’s virtual?
Thoughts?
You can run multiple Java Programs at the same time and have them all perform well, but it is going to cost you quite a bit more memory than the equivalent in C/C++. For instance at any given time I have eclipse, a JAVA SameTime application, and knopflerfish with multiple custom bundles open at the same time. All of them perform well, but the memory usage is high, ~300MB total, I still have 500+ MB free though so it is not a problem. On my Linux client memory usage is higher at around 600MB but again I still have plenty of memory so it is not a problem. Cut the memory down to 512MB though and I would have problems on Linux, and possibly Windows.
So an XML Database that I assume is written in Java does not perform well so Java will never perform well? Bashing memory usage I can agree with. Bashing UI performance, especially in Linux, I can agree with to a lesser extent. But blanket bashing of Java performance I do not agree with.
Ah well, I guess everyone is entitled their opinion.
I tried the fibo code from http://www.kano.net. I test on a FreeBSD 4.10-STABLE system
with GNU G++, TenDRA (www.ten15.org) and JDK v1.4.2. I did not know how to get
TenDRA to compile the C++ code, so I had to convert it to C for TenDRA.
My results from worst to best:
JDK v1.3.1
# time java fibo 45
1836311903
java fibo 45 262.53s user 0.05s system 99% cpu 4:22.86 total
GCC v2.95.4 (-O2)
# time ./a.out 45
1836311903
./a.out 45 34.64s user 0.01s system 99% cpu 34.703 total
GCC v3.3.4 (-O2)
# time ./a.out 45
1836311903
./a.out 45 32.30s user 0.00s system 99% cpu 32.469 total
JDK v1.4.2
# time java fibo 45
1836311903
java fibo 45 22.05s user 0.02s system 99% cpu 22.151 total
TenDRA CVS
# time ./a.out 45
1836311903
./a.out 45 20.26s user 0.01s system 99% cpu 20.293 total
If you use C to implement something, your performance is bound to C. Look at one extreme case, in where some program (written in java for example) can be optimized to one single dump of output to the console, without any additional computations being done. The Optimizer would have done a perfect job. But still, the console output routine is written in C. So the java program can not be faster than a C program which executes the same dump.
If you extend your reasoning to its logical conclusion then yes all programs that run on linux are bound by kernel performance or glibc performance. That assembly program that you hand optimized is still bound by whatever glibc and system calls you decide to use. So basically your analogy is meaningless.
Yes, you do have a startup cost for the JIT. There’s nothing preventing you from going to java source to machine code though. What do you think GCJ does?
If you want to be critical of Java performance, then be critical where it really counts, such as memory footprint and (getting better) but somewhat still sluggishness performance of swing.
I would hope that after the release of 1.5 that Sun and others concentrate on memory optimizations(VM sharing anyone) and Swing(Can I get some decent fonts please).
I use SWT for my java gui programs and I’m quite pleased with it. Maybe the API isn’t as elegant as Swing’s, but at least I can get decent native fonts as well as other native widgets and I can compile my entire application to native with GCJ.
Something which is written in C can not be faster than C.
False.
For example, I can write an interpreted BASIC program that generates and assembles optimized assembly code. The code generated by my BASIC program is full speed assembly–much faster than the same task could be accomplished if written natively in BASIC.
So how does using BASIC to do that limit the final code output in any possible way? This is like saying a particular text editor has an effect on the runtime speed of your code.
Howdy
Does anyone know if this was killed off?
Also i just have to comment on this article … Sun needs to remove ALOT of bloat from the Java API`s and do a little bit more for optimisation, the flexability is there, the semantic sugar is too and all we need now is some performance tune ups.
And for those C/C++ fan boys, go code a full transaction management system in C/C++ and then in Java and come back and post about how a little bit of speed is worth the pain you went through!
yes.. java is fast but it is not well optimized enough AS ALL CROSS PLATFORM LANGUAGES IN NATURE, like .NET and the many others. It usually lags the load on the machine when the initial application loads more than other non-cross platform languages that require a VM.
lets be realistic, from the very nature of how java works, it cannot be more efficient than C/C++ in most (and common) contexts. Just compare Eclipse vs. Anjuta. Anjuta runs A LOT faster on the same machine. For any type of performance-oriented work using java be border-line idiotic. Java has its selling point, true cross-platform compatibility. It was never supposed to be faster, and to claim so is ridiculous.
Is that there is tons of room for optimizing current ‘c’ and ‘c++’ compilers out there. From a common sense analysis standpoint c/c++ should always be more efficient at what it does than java. No JVM overhead, no array bounds checking, no need to run JIT on the fly.
I would like to see comparisons about the total number of dollars and man hours put on development of c/c++ compilers verses what’s been put into java and JVMs. Especially numbers for the past 10 years.
lets be realistic, from the very nature of how java works,
At least give some examples. I suppose you are referring to bounds checking, checked exceptions, heap allocation… Bounds checking can be optimized much of the time and heap allocation is very fast in Java, but yes there are performance hits that are hard to overcome.
Frankly, I would rather do most of my application work in Java or C# and write performance critical sections in C if need be. I’ve had enough of C++. To me, it’s too much of a pain in the ass when working with other people to be enjoyable.
Just compare Eclipse vs. Anjuta. Anjuta runs A LOT faster on the same machine
That’s like comparing Emacs to Notepad. There is no comparison. Eclipse has a real-time parser for java with a top-notch architecture and even has a full-fledged parser for C/C++ which anjuta doesn’t even have yet.
Java is pretty fast and getting faster all the time. Remember, 10 years after C++ came out, many developers considered it slow and stuck with C.
Like I said, I’ve done enough C++ in my lifetime that I don’t want to touch it anymore. Java, C#, and straight C is good enough for me.
“And for those C/C++ fan boys, go code a full transaction management system in C/C++ and then in Java and come back and post about how a little bit of speed is worth the pain you went through!”
A good c/c++ coder will be experienced with it and get it done surprisingly quickly. Yes it takes longer irreguardless as you will see them likely rewrite quite a bit of code that’s already in the libraries the java coder is using; but this “machine cycles are growing exponentionally so lets save human time and waste machine time” argument is just no good. Using the proper language for the job is important.
I can turn your whole argument on it’s head and come back with:
“Why would you waste your time with Java when you can do it in less time in python with only a minimal speed loss?”
And if it’s Windows, you can probably do it in even less time in Visual BASIC (*shudder*).
I just compiled and ran all the tests (except the 2 that required data files). For c++ I changed one test to instantiate the classes on the stack and not the heap, in a few I changed all the post increment to pre increment (probably doesn’t matter really). I also explicity inlined the non virtual functions.
I used these flags for gcc
-march=athlon-mp -O3 -pipe -m3dnow -msse -fomit-frame-pointer -funroll-loops -falign-functions=4
(yes i know, some of these flags are redundant)
In each case I compared gcc with the *best* of either client or server jvm’s. Neither the client nor server JVM consistently beat out the other.
g++ lost fibo, hash2, methcall narrowly (scored between the 2 jvm’s in all cases)
g++ won heapsort, objinst, sieve narrowly
g++ won hash, ackerman, strcat, matrix by 1.4 – 3x faster
g++ won nestedloop, random by 6x – 7x.
I could do more analysis on these and post more numbers, but I think I’ve thrown enough doubt to make people legitimately question his claims of java speed superiority.
gcc-3.3.3
jdk_1.4.2-rc1
Isn’t it a performance cost that all java programs inherently are running as threads?
“So, I just pointed out that a compiler written in Java can be efficient compared to one written in C++”
No, it cannot. The processes involved it compilers are very sensitive to memory management heuristics and they are allways limited by the performance of the memory manager, not by code generation. A language with manual memory management will allways win from a language with automatic memory management, no matter how good the heuristics are.
If you don’t want to compare against Turbo Pascal, compare against Delphi. It compiles only 2 times slower than TP. GCC is a bad example, it is the slowest compiler I know of.
Now if Sun could Java memory usage levels below the ridiculous into the acceptable it’ll be better still.
And no, throwing more RAM at your computer does not solve the issue – that’s a crap solution.
@Brian
You’re running Java on an Athlon. Sad to say but the current implementation of the Sun VM runs a lot better on the P4 due to the SSE2 beckend.
“A language with manual memory management will allways win from a language with automatic memory management, no matter how good the heuristics are.”
It is NOT true that manual memory management will ALWAYS win speedwise. In some cases, yes, in others, no. But it is NOT true that automatic memory management will ALWAYS win speedwise. Arguments on that are pointless — the choice depends on the task needed to be solved.
Not speaking of Java, note also that you do not need to be forced to choose between manual and automatic memory management.
. The truth is that for best performance, you
well, i think JSP/servelets is fast and the server side. damn fast. I used it here, i mean damn.
I haven’t had similiar success with java desktop apps. but there really isn’t a solution or viable alternative that is faster since its cross platform.
The only problem on the server is the resources it takes up. The new specifications of Java address that. The performance and load have increased greatly as java has been updated by sun. I still believe sun should donate Java to an “open organization” like SPARC International.
Open the source, but make it unforkable since people want to fork it. Have the organization funded by IBM, Jboss, Sun, etc. all the companies who actually have investments in it. It makes no sense for sun to spend the money to please others when they aren’t making much.
Howdy
“Why would you waste your time with Java when you can do it in less time in python with only a minimal speed loss?”
Good point .. if the performance is acceptable why not use it?
Horses for courses my friend as I`ve posted many times here :0)
I am really just so sick of fanboys saying “if it`s Java it`ll be slow” or “they should of used C/C++”.
If you need to start mangling byte code or rewriting a VM to gain enough speed from a Java app to be usefull then maybe C/C++ would be worthwhile, untill then the mana from heaven that is Java is more then worthwhile to use.
As someone mentioned, Java is written in C or C++. Before the execution Java is compiled by HotSpot or Jit into native machine code, comparable to one generated by C++ compiler.
It is not quite a suprise. I used to generate assembler code by Borland C/C++ compiler in the old days. If the code was a little bit more complicated I found C/C++ generated ASM code more optimized. That was the case because I have written structured, humanly logical assembler code, while compiler utilised optimization that made almost unreadable, but smaller and faster.
I think that the same case might be with Java HotSpot. It can generate better code than human programmer, especially if the programmer is either slopy or does not try to optimize C++ code, like excessive use of unneccessary variables, for example.
Optimization swithces, like -O2 in case of GCC is, in fact a group of switches, a many people do not go deeper to analyze
what is optimized in particular.
um, you do realize he was using java 1.5 right? not 1.4.2
I have programmed in Basic for 6 years, then I have programmed in both assembler and C but I found C to be too slow (Borland C) so I sticked to assembler. Then I met Perl, and later Java. When I had my first encounter with Java (in 1997) it was really slow and I didn’t really care about how appropriate OOP was. Then in 2002 I met JDK 1.3 and I was sold.
According to me, these tests “insde the JVM” doesn’t make much sense. Since JDK1.3 internal computations were already very fast in Java. The problem with JAVA is its interaction with the “outer world”, i.e. hard disks, screen devices and so on.
According to me, Eclipse feels as fast as any heavy Visual C++ + MFC application considering that for every letter you type it makes hundred of integrity controls. Imagine an application like Outlook Express written in Java+SWT. It would be as fast as the native C++ version. The startup time might be longer, but that’s all. We all know that Java is already fast in server side. Resin performs better than almost any other application server either in Java or other programming language just by using better I/O.
Swing is slow. I understand Swing’s philosophy “port getPixel() putPixel() and you will get a GUI in any target OS”. That sounds very nice but we don’t have Swing in all platforms… official releases are only for Windows, Linux and Solaris. Apple does its own port. There’s no updated Swing-based Java on other platforms.
I want to like Swing but it feels slow, and I hate Metal, even if they don’t use the native peers they should produce some Mozilla quality results. It’s possible. Qt also produces interesting results using such approach.
In any case, Java is a bless for programmers, it allows a much more organized way of programming that other languages, it’s better documented, etc. Almost any program could be written in Java except extreme performance software such as sound drivers or dvd players.
What’s the sense of doing 30% faster code with half the memory requirments when programmers have to work at least twice the time, and processor and memory costs cost probably less than a week of coding time. ($200 for 1GB of memory)
We have to accept that 1GB of memory is “a lot of memory” but it doesn’t cost anymore “a lot of money”. Anyway, JVM-sharing would be a killer feature
His tests were definitely done with 1.4.2
But that was off the second link, not the main one.
I don’t have the code for the first test handy.
Here’s an interesting article about shared classes.
http://www-106.ibm.com/developerworks/java/library/j-shared/?ca=dgr…
The jist of it is that you don’t share VMs, but instead a master vm loads system classes into shared memory which worker VMs share.
Hmm, apparently Class Data Sharing(CDS) which is based on Apple’s Java Shared Archive implementation has made it into Sun’s J2SE.
”
For your final point, I stand by my assertion. If you use C to implement something, your performance is bound to C. Look at one extreme case, in where some program (written in java for example) can be optimized to one single dump of output to the console, without any additional computations being done. The Optimizer would have done a perfect job. But still, the console output routine is written in C. So the java program can not be faster than a C program which executes the same dump.
That reasoning is flawed. Why then does Java manage to beat C in numerical computing? After all, Blackdown JVM on Linux is compiled with GCC, yet it manages to perform better than GCC on equivalent numerical code (discount trigonometry since Java 1.4 implementation is flawed).
”
I do not think my reasoning is flawed. Your counter example is not really one. Your example states that the java program is somehow “better” optimized than the C program. Of course then you will have a speed advantage of java. I was talking about the lower bound of execution time. And this bound is somehow determined by characteristics of C, if the JVM is implemented in C.
Actually, the description of the scenario should even make this clear: “A C program interprets some sort of bytecode.” – This should make it clear that the bytecode is just another form of data input to the C program. Data like any other. It is reasonable that the C program interprets this data in the least time consuming way. If that includes of just in time compiling parts of the bytecode into native machine code, that is fine, but it does not somehow falsifies the fact that it is still a running C program, which interprets something other.
Brian, how did g++ beat Java in your Ackermann test? What code did you use?
I tried it with the code from “The Java is Faster than C++ and C++ Sucks Unbiased Benchmark”, and java -server ackermann 13 ran in 28 seconds, while the g++ Ackermann with your optimization settings (except athlon-xp instead of mp) ran in 78 seconds.
By memoizing (caching the function parameters and result) the Ackermann function in the C++ version I was able to get it to run in 0.8 seconds. Doing the same to the Java version made it run in 4 seconds.
If that includes of just in time compiling parts of the bytecode into native machine code, that is fine, but it does not somehow falsifies the fact that it is still a running C program, which interprets something other.
Once the bytecode gets compiled into machine code, how is that still considered input to a C program? Its is running directly on the hardware by passing whatever interpretation the VM might otherwise provide. The counter example I gave just demonstrated this. They were running an equivalent algorithm, and Java is faster than C. The code was no more optimized for Java than it was for C. You can get that code from http://www.aceshardware.com/Spades/read.php?article_id=154 if you don’t believe me and want to take a look at the code yourself.
Others have also pointed out the mistakes in your reasoning.
Java performance Myth?
The only Java Performance Myth is the pertutual argument put forward by javaphiles that Java Swing performance is now (or
“since recently”) acceptable.
“The only Java Performance Myth is the pertutual argument put forward by javaphiles that Java Swing performance is now (or
“since recently”) acceptable.”
But it IS acceptable (since recently:-).
Just tried out the 1.5 beta with some Swing apps and I think it’s definitely faster and certainly acceptable. I agree it used to be slow, but a lot has changed…
Once the bytecode gets compiled into machine code, how is that still considered input to a C program?
It is input. You can not really argue against that. The bytecode can not compile itself. It needs the help of another program.
Its is running directly on the hardware by passing whatever interpretation the VM might otherwise provide.
It was compiled beforehand.
The code was no more optimized for Java than it was for C.
This is an entirely subjective estimation, it does not prove anything. (To me it sounds rather strange to say two programs are equally optimized if one of them runs faster than the other, btw.)
If you want a counter-counter example look at this:
http://www.mit.edu/iap/2004/inside-c/day3/fibonacci.cc
This computes fibonacci numbers at compile time. This for sure will be faster than the java implementation of your benchmark. So your example does not demonstrate that java exceeds a speed limit.
El Psedunymo,
Do you understand that when something is JIT’d that it is machine code that is running and not being interpreted by a C program?
Do you understand that when something is JIT’d that it is machine code that is running and not being interpreted by a C program?
Yes, a JIT will compile bytecode into machine code, so that bytecode translation only happens once, and does not have to be repeated. Additionally only required parts of the code will be translated. Thus a JIT will minimize the amount of time spent for bytecode interpretation. I do not argue something else.
Additionally only required parts of the code will be translated
That is a function of a particular implementation, not of the java specifications itself.
Some JVM implementations might JIT all the bytecode. Some might JIT most of it, and use something like HotSpot technology to optimize critical paths at runtime.
Or you have something like GCJ that translates java source code into machine code the first time.
> [java being faster than C] is impossible. Theoretical
> reasons for this are for example that all java
> implementations (all that I know and not counting the
> library side) are written in C.
So you’re saying that an assembly language program compiled with an assembler written in C is somehow bound by the speed of C, right?
Get a clue!
“But wait,” you might say, “that program is compiled before it is run, so it is not bound by the speed of C!” Well, then just include the compilation step in the program! Now you have a program written in C that compiles and executes a program written in an assembly language. The program will run just as fast, minus the initial compilation. “But wait,” you might say, “the total time must still be bound by the speed of C now that the compilation step is included.” Wrong! The compilation step is the only thing bound by the speed of C and it is in no way related to what the actual program does, hence the total time of a program written in another language than C is in no way bound by the speed of C just because it is JIT compiled with a compiler written in C.
> Something which is written in C can not be faster than C.
How can you not realize that a program compiled with a compiler written in C might not be written in C? Java is not “something which is written in C” even though it might be compiled by something written in C. However, what language a compiler is written in does in no way dictate the speed of the programs it compiles.