[java] Speed of Different Programming Languages

Anyone want to bet me that everyone that responds to this post in the other forum will say that java is interpreted and that it is always slower than c, blah blah blah?

You can tell the people who only use MS''s version of java because that is the response they always give. Even though ms provides a jit. Just In Time compiling compiles java to machine code. That''s right, machine code just like C or C++. You also shouldn''t compare C to java since c isn''t a object oriented language. As a bonus new java compilers can actually rearrange code to make it faster as it runs, which in certain cases actually makes java code run faster than c code. Of course the area where java blows other languages out of the water is development time. The number usually quoted is %30 faster.

The fanatic is incorruptible: if he kills for an idea, he can just as well get himself killed for one; in either case, tyrant or martyr, he is a monster.
--EM Cioran

Opere Citato

Hi EbonySeraph!

First of all; are you considering Java as an implementation language for your research project? If so, I could give you some hints to webpages and so on. Or are you going to write about the speed differences between C, C++ and Java? In that case I must say that you shouldn´t compare C with either Java or C++. The C programming language is not an Object Oriented language like C++ and Java. (Actually, C++ is a hybrid language, which let you write both C functions and C++ methods.)

If you compare speed differences between these language you should also take other factors into account. Java contains several types of runtime controls that are not a part of C++ or C. For example, Java checks if you get outside an array. Thus, you get some more, but it cost some performances. There are lot of more "bonus stuff" in Java, that you do not get in C++ nor C.

Also, as mentioned earlier if you compare an implementation langugage for a project, you should also take into account the development time.

Regards
Johan

Everything has a cost...



When you consider just in time compilers and hot spot like on-the-fly code optimzers, it becomes evident the only real speed loss comes from the garbage collection process. But one could say that garbage collector makes your development faster and your code memory leak free. So basically the time you gain with C++ at running time, means you spend more time at development and it gets more complex.



Also, I once saw an article at http://www.javaworld.com about the difference between C++ and Java when considering time to instanciate a new object. In fact it is an article about object-recycling mechanisms to actually deal with this speed loss over C++. I can''t remember the exact URL anyway. But as far as I remember it was saying something like the time to instanciate an object in Java in more than three times the time for C++.



Java is not the best language so far and I believe it will take time before Java will be able to catch with C in every situation. But I think for your study you should try and compare the gain in speed of each language for the same piece of code for the last 5 years. I mean I imagine (I said "imagine" because it is just speculation here) the execution time of the same piece of code of the same machine has been greatly improved in Java since the JDK 1.0.2, at least more than the same piece of code in C for the same period of time.



That''s what I think about speed and languages. Anyway, I just love coding in Java and since I discovered it three years ago, I just decided to code everything in Java (even if I used to be a C "geek" fanatic). I am so much in a habit to use Java (where everything is provided and you just code) that sometimes when I need to code in C (for school mainly) I think of it as an archaic language. And that''s another point : the speed of deployment. In java your deployment time is null, provided you just need a working Java runtime environment. You don''t need to configure/recompile and so which is another gain of time.



I hope all I said makes any sens.





Herve

Hmm...

Ok, as far as I can uderstand the industry as a whole ( general numbers no fcts ) is that well tuned java is ~10-30% slower on average then C. There are also meny cases where java can perform the same task faster then ansi c code do. It''s way of handeling data and dynamic compilation to asm is why it can be faster. Calling virtual methods in OO can be costly, because each call requires at least one lookup, and at least one paramater to call the other function. It does add up, but thanks to Hot Spot those small functions whose startup costs eat a large portion of there execution time are often inlined so the cost is almost LESS then that of the C counterpart.

The other side of the coin that makes Java appealing is despite the 10-30% speed decrease, the freebies ( garbage collection, bounds checking, ... ) make java developemnt up to 50% faster ( assuming trained personel ) than the same sized C application.

Devils advocate: ( hey I''m a libra )

Java''s main weekness is not the language or the compiler, but in many of the support libraries. The are designed to hide too mich of the underlying system, making it more difficult to take advantage of tuning that''s availible in C programs. Java''s IO is not the best, in fact one of the hardest things is getting data into and out of the Java heap ( memory space ). note: Java.nio in 1.4 should make IO in java up to twice as fast, as it will no longer be necessary to copy external memory ( from libraries, system resources, file buffers,... ) into the java heap before your program can act on them. Java.nio also add a rich library of non-blocking IO channels, as well as a way of mapping IO so that the process can be automated by the system to be as fast as possible ( map this file channel to this network socket and do your stuff ).

Historicly languages also take time to develop, java has hit a real stride with the Java2 realease. It''s very big in the server market, and it''s popularity is growing in the client market. It''s really starting to come into it''s prime as a language. There are many addons that are popping up, and many exciting new features on the horizion.

You can alleviate many of the IO, and library problems by developing with platform specific libraries ( see demomaker thread ). I personally stay away from them because If I can scrape by with just pure ( or very close to it ) java, my applications will be portable directly to the macintosh, solaris, and linux with 0 modifications ( or any other java2 platform ). With the beta of 1.4 out there are almost no features that are missing from java2 ( there are still a few that sun just can''t seem to get right ).

Good luck, and if you have any other questions keep asking.

My humble $0.02,

The speed issues have been explored it seems but I just wanted to iterate one point (also already said): don''t forget deployement time. While not perfect Java brings consistent looking code and object oriented focus that''s much better thought out than MFC. Personally, I''ve enjoyed learning it. You''ll pay in speed but that is improving. You''ll be able to right better apps quicker and that is really what it comes down to.

Sieggy

The reason why java can be so much slower then c++, even when complied into machine code, is all the excess things it does to make the app stable and clean. Like stated before, it checks the end of arrays, well that''s only a small portion of what java does to help out. If you have a pointer pointing to some obj in memory, and you change what the pointer is pointing. So nothing is pointing to that obj, java automatically frees that space up. C and C++ on the other hand let the memory stay resevered. All this backend checking slows down the language because it makes sure that all this error control is in place. While in C and C++ the programmer can write his/her own control routines. While this saves memory (in being clean and not having variables keeping track of pointers and so on or unrelease memory) and dev time while c and c++ have always run faster because the application dosen''t do clean up unless it''s programmed. While c and c++ take alot of dev time and can be messy code, as far as i''m concerned i''d rather use c(mainly because i focus on game programming which needs speed).

Well I think Java is by far the nicest and easiest language to code in and has been Object Orientented from the begining. Being new it doesn''t have the hang ups that all the older languages do.

But soon computers will be so fast that it won''t matter what lang you code in....

On that note, the p4 1.4ghz pc I brought yesterday runs The new
Chaoslab verson 2 beta (not yet online) all in real time even with over 8 renders which are now all at 320x240....

:-)

Well most of the stuff I was gonna say has already been said, which is cool, but one other thing to consider is neither C nor C++ is ''ground zero'' as far as speed is concerned. If you''re using Windows, find the masm assembler and you''ll be horrified at just how bloated everything(?) else is. There really is alot of misinformation on that.

The only thing I''ll add to this is the fact it really depends on the platform and implementation vs the language itself. When MS was touting VJ++, it actually proved FASTER then VC++ in at least one benchmark. (Programming Microsoft Visual J++ 6.0, Microsoft Press, pg 16-21) I''m not sure what machine they were using but on my old AMD K6-2 it was even more skewed toward VJ++.

Another issue about java''s speed in graphical applications is the design of AWT and Swing. Both apparently use a rather inefficient underlying graphics engine to display components, and that''s something Sun plans on fixing for the J2SE 1.4 Beta 2. And as 1.4 also supports concurrent GC, a lot of the pauses caused by GC in 1.3 won''t be there anymore.

The speed of java comes almost entirely from the runtime system. If you look at the bytecode, it''s VERY clear that a java compiler that compiles to bytecode can''t do a lot of optimization. Some is possible, but not a lot. Therefore, almost all of the optimization is done at loadtime and runtime. This can be good, because advances in runtime systems are proceeding a lot faster than advances in compiler optimization. There will probably always be a speed penalty of some sort, but it will become less and less apparent as runtime systems advance.

Neither C/C++ or any high level language is going to as fast as hand tuned assembler. Virtual functions were criticized when C++ became popular as adding too much overhead. Point, these discussions, while indeed valid, have become irrelevant as computing power and the demand for better languages rise.

Java, unfortunately, has not quite reached such a point yet. As much as I love the language, doing games with the graphics caliber of Unreal Tournemant, Sacrifice, or the soon to be released Dungeon Siege is not yet possible. However, the language is improving and will continue to do so. That combined with the insanely powerful, and cheap computing power will hopefully open the doors up for Java.

I loved working with C++ and got reasonably proficient in it but I think Java has numerous advantages over it - its definitely a very enjoyable language to work with. Again, we are little early in the game (no pun intended) but believe there is a lot in favor for us in the future.

Sieggy

Edited by - Sieggy on August 9, 2001 7:36:12 AM

Just a little twist and I''m sorry I don''t have more details I just remember reading this a couple months back. Anyhow, typically we question the ability of intrepreted code vs. native code. While this does not quite equate to a jvm, HP actually uses an interpreter for their native code in newer releases HP-UX. The idea is that the interpreter can adjust the code to the current state of the machine thereby getting more "efficient" execution - something that cannot be done at compile time since you don''t know the machine''s conditions at executable time. Supposedly they can increase code by a third over plain compiled native. Again, sorry I don''t have more info. However, things like this make it clear that their a lot more optimization possibilities ahead for Java. If HP actually has that working its a rather intriguing concept.

Sieggy

In term of excution time, C/C++ will ever be faster than Java, because he is made for performance since Java is designed for portability and "assistance to programmers". By this, I mean that he provide some help (like Garbage Collector, range checking) and a lot of API (written in C++/asm for performance, in most case).

I think that Java can be very usefull for web developpement, but I don''t like it.

Why? Because he is another layer to the hardware. To access to material, we have: Java ByteCode -> interpreter/Just in time compiler -> Java API -> Native API -> drivers -> hardware

Computers become more and more powerfull, but software become more and more slow!!

The concept of Java (absolute portability) is great, but it would be better if we have a C++ universal API collection*!

*: for game there is also SDL+OpenGL+OpenAL+BSD socket, but there is no standard GUI API!

Generics (templates, from a C++ perspective) in java, whenever they''re released, won''t involve a speed increase. They aren''t implemented as code transformations with a preprocessor, but as a language extension that adds some extra compile time type safety, and reduces the number of casts necessary. However, that''s only in the sources. The compiled files will look just the same as they always have, with casts and runtime checking in place. Java was designed to be a 100% safe language at runtime, no matter where the compiled class files came from. That means that it can''t assume the .class files are safe, and so have to verify them.

To bobatefrei:
The java API is written almost entirely in java. The few pieces that aren''t are mostly written in C. I don''t understand why your chain had the java API as separate from the other parts, because it isn''t. About 90% of it is java bytecode. The rest is native code, written as native API calls, for the most part. I also don''t understand why you have native APIs separate from hardware drivers. Hardware drivers are the concrete implementation of abstract native APIs.

Just a question: Isn''t dynamic casting rather expensive in Java? Templates, while they can be a pain, solves that resolution in compile time. Casting is crucial in some object oriented patterns so you can''t get away from it completely but I was curious if someone knew more of the costs it came with.

Sieggy

I''m standing by my previous assertion.

Prototype for JSR014: Adding Generics to the Java(TM) Programming Language

JSR-000014 Adding Generics to the Java(TM) Programming Language