Archived

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

EbonySeraph

[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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sieggy    122
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

Share this post


Link to post
Share on other sites
LOWORBIT    122
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).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
>> 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. >>

Well, if a Java programmer wants to prevent the garbage collector from freeing up the memory of a certain unused object then they can just keep a bogus reference around for the object until the execution of the program reaches a stage where it is more appropriate to free up the object (just as C and C++ do). There are a lot of allocation-related optimizations like this in Java and I hear that Sun''s Hotspot compiler is getting pretty good at doing quick object allocation.

It''s quite hard to fairly compare the speed between the three languages. In order to do that you really need to know most of the optimizations and effective programming styles that can be applied to each of the languages.

Henry

Share this post


Link to post
Share on other sites
Chaoslab    116
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....

:-)

Share this post


Link to post
Share on other sites
Ajatar    122
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++.

Share this post


Link to post
Share on other sites
c_wraith    122
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
IMO, Java will maybe, one day, be as fast as C. I personally don''t think so, but I won''t say "it can''t be" either. I, however, do believe than it will never be as fast as *properly* written C++ (ie using almost exclusively templates). This article explains why (note : I didn''t write this) :
http://www.jelovic.com/articles/why_java_is_slow.htm.

Note than I''m not saying that Java isn''t a good language. I just don''t think it was designed with speed (of execution) in mind, but rather with portability and speed/ease of development.

My 0.02$

Share this post


Link to post
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 this post


Link to post
Share on other sites
Guest Anonymous Poster   
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Yes, the new template package in Java will solve two problems, type-safety for collections and removing expensive dynamic casts. I don''t know where c_wraith get the idea that they won''t involve a speed increase since removing dynamic casts will certainly speed up programs that depend heavily on collections. The problem can already be solved today by writing typed collections but that does require extra work and is an ugly solution (even though it is made a lot easier by the fact that Sun releases the source code for their collection framework). Sure, the JVM still needs to be sure that all casts that it allows are in fact valid but using typed collections allows the JVM to optimize away those checks once the code has been validated (I read that it''s also possible for it to optimize away certain dynamic casts if it knows that only one special type is used in a collection).

My main objection against the proposed Java template package is that it doesn''t go far enough and involve primitive types.

Henry

Share this post


Link to post
Share on other sites