• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# [java] Speed of Different Programming Languages

## Recommended Posts

EbonySeraph    122
Note: I put this post in another forum too but there probably aren''t many people who know Java in the other one''s so I am looking for an answer mostly for Java here. I know this should go in another forum but I want as many replies as possible. Even if you see a reply that is just what you are going to say, please add what you may have more. This question is for a research project I am doing in school: What is the speed difference between C, C++, and Java? I mean in depth detail. I heard something in a post a while ago about C vs C++ and someone said something about C functions calls being faster. If anyone can explain why that would be greatly appreciated. Also if any one knows Java can someone tell me about why Java is slower than the other two languages. Also if you have any history(thought I have some) about the languages feel free to throw some in. Or if anyone knows a web site that has all the info or significantly chunked peices of it. Please tell me the URL. Thanks for your help. "Ogun''s Laughter Is No Joke!!!" - Ogun Kills On The Right, A Nigerian Poem.

##### Share on other sites
GKW    200
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

##### Share on other sites
JavaJohan    122
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

##### Share on other sites
silencer    122
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

##### Share on other sites
snowmoon    122
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.

Sieggy    122

##### Share on other sites
Sieggy    122
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

##### Share on other sites
Guest Anonymous Poster
That article comparing the speed of Java and C++ is a mess. First, it''s called ''Why Java Will ALWAYS Be Slower than C++'' (my capitalization), yet the conclusion the author reaches is that ''Java, with the CURRENT LANGUAGE FEATURES, will never be as fast as C++.''. What is the author really saying here? That Java will always be slower than C++ or that the current version of Java is slower than C++?

That is an important distinction because one of the reasons he says that Java is slower than C++ is because Java does not have templates. However, the template specification for Java has already been posted and will be included in future versions of the language, so that argument does not support his thesis that Java will always be slower than C++ (you can avoid dynamic casts today by writing your own typed collections).

The article''s only truly valid argument, which I don''t think can be refuted by advances in compiler/optimizer theory or is not just bogus (such as the one about how Java''s greater memory requirement makes it ''more likely'' that the OS needs to swap memory to disk), is that C++ gives the program greater access to low-level features. This is also why C++ will never be as portable or safe as Java and why ASM will always be faster than C++.

Henry

##### Share on other sites
Sieggy    122

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

##### Share on other sites
bobatefrei    122
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!

##### Share on other sites
c_wraith    122
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.

##### Share on other sites
Sieggy    122
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