Hi!!! ...after reading a few debates on the net about execution speeds, is C++ really faster than Java? ...It appears that some believe it is and that others believe it depends on the job of the application... any views? Its just some research I am doing for my project! To see which language to use! ...Im doing a real-time monitoring user interface to interface with some low level C audio effect algorithms that I have written!
Thanks for any opinions!
Many junglists take pride in their belongin to what may be referred to as a globalised drum & bass subculture, as a subculture though, it is not nearly as distinct at gothic or punk!
This gets asked alot, yes c++ is and can be alot faster
http://www.jelovic.com/articles/why_java_is_slow.htm
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
As with most things programming-related, it depends on the skill level of the coder, the algorithms used in the particular program, the platform it's executed on, and a host of other details. Benchmarks of various applications on various platforms put Java above C++ in a few areas but C++ tends to win out most of the time. If you're going to be doing some sort of time-critical application on x86-based architecture, Java is not the way to go.
Code:cout << "Language comparisons are dumb"; echo("Language comparisons are dumb"); PRINT "Language comparisons are dumb" alert ("Language comparisons are dumb")
thanks! ...For my final year undergrad project, I'm doing a real-time audio effects processor; this uses some specialised DSP hardware that connects to the host machine via parrellel cable; I know this is not great because its damm slow! ...the host machine runs a GUI that the user uses to select an effect and gives full control over effect variables so they can warp the signal however they fancy! this GUI has to be a real-time monitoring system and sends messages to the DSP board about the changes if any in the parameters so the DSP then changes the effect! ...the effects are all C algorithms stored in the DSP boards memory!
However, for my write-up, I have to explain why I have chosen C++ over Java for the GUI; the real reason is because I hate java, I think it sucks!
...But I can't write this! ... I have to give a few good reasons why I have chosen C++ over say Java or other OO's!!! so am just comparing speeds, but it seems as if some ppl believe Java is faster than C++, but most vice versa! however, I can't seem to find that key reason why Java would be slower! ...I will continue to search the net!!!
...and my operating system is Win XP, Pentium 4
Many junglists take pride in their belongin to what may be referred to as a globalised drum & bass subculture, as a subculture though, it is not nearly as distinct at gothic or punk!
What kind of effect/DSP hardware?Originally Posted by bobthebullet990
Are you making vst plugins?
I see no particular reason why you can't state lack of familiarity with Java as your reason for choosing C++. Add to that perhaps that low-level programs are in C++ for speed reasons (and yes, for low-level programs such as signal processors, C++ is faster) and interfacing with Java would have been more complicated than interfacing with C++.
C++ and Java are in many ways so similar that often it's really just a matter of taste which one you choose. De gustibus non est disputandum. If the people evaluating your work have any clue, they'll know that.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
The fact that you prefer C++ is a perfectly good reason for you to be using it. You should always use the language you are most comfortable with, unless there is a huge advantage to using the other language.
Interpreted java is slower because the byte code has to be translated into machine code at runtime, an extra step that C++ does not have. But this does not apply with Just-In-Time Compiled java programs.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
nope... its an external DSP board, the Texas Instruments 6711 DSK, but with the PCM3003 Audio daughter card to get sampling rates of 48khz cause onboard codecs are only 8khz which isn't good for audio effects!!!
Its similar in the idea to a professional effects unit, such as the EFX1000 by pioneer, but obviously nowhere near the complexity and functionality of that thing!!! ...but the idea is for streaming audio, either for DJ use or even guitar effects! ...It has an input port, for the input data obviously, and an output port... for the output audio, connect this to ur amp and u have an effects unit!
Its only so I could try something new; DSP programming and understand a bit more about audio effects, as my hobby is DJ'ing! so it is very interesting for me!
Many junglists take pride in their belongin to what may be referred to as a globalised drum & bass subculture, as a subculture though, it is not nearly as distinct at gothic or punk!
In general, C++ is faster than java. Sure you can do contests with average C++ coders against experienced java coders and the java coders would win.
You need experience to write fast code in Java,
you need experience to write correct code in C++
In general, C++ is faster than java. Sure you can do contests with average C++ coders against experienced java coders and the java coders would win.
You need experience to write fast code in Java,
you need experience to write correct code in C++
C++
Java (v1.5.0)Code:real 0m0.023s user 0m0.002s sys 0m0.002s
Code:real 0m0.313s user 0m0.138s sys 0m0.030sC++ blows Java away in every single execution speed category where the programmer isn't totally STUPID.Code:#include <iostream> using namespace std; int main() { for( int i = 0; i < 1000; i++ ) { if( i % 2 == 0 ) { cout << i << " is an even number! " << endl; } } return 0; } final class even_numbers { public static void main( String[] args ) { for( int i = 0; i < 1000; i++ ) { if( i % 2 == 0 ) { System.out.println( i + " is an even number! " ); } } } };
Where Java blows C++ away is that in Java, there is a very comprehensive API for doing many, many things (and very quickly--in terms of coding them) compared to the rather limited "standard library" that comes with C++.
For example, if you wanted to write a network-centric app in C++ that goes out, grabs a web page contents and displays it--all starting from only what the standard library provides--you would code away for a month of Sundays. In Java, you could write it in about 8 lines of code...inside of 10 minutes all with just the "standard library" that ships with the JDK.
However, after your months of toil with C++, the execution speed would still be very much faster than it would be within the Java environment, assuming that the programmer wasn't a total moron.
However, bobthebullet990, the prinicpal argument that I'd use in my paper wouldn't be execution speed, it would be that C++ gives you low level access to the hardware whereas Java provides it solely through the JNI, which is then implemented in (usually) C code.
And, for anyone who wants to continue the argument of which language is faster/slower/better/worse, just remember that the JVM is written in C!
:davis:
Rubbish. There are some programmers who are stupid enough to believe that though, or to believe that your test case is representative of the complete range of problems that might be tackled by C++ or Java programmers in the real world.
I have seen numerical benchmarks where professionally written Java code convincingly out-performed professionally written C++ code (and, in one case, both were outperformed by a Fortran code written by an amateur). Which just goes to show that all higher level languages have their strengths and weaknesses.
That doesn't enter the performance argument though. There is also the fact that, although the scope of the Java libraries is much broader than the scope of the C++ libraries, the quality of implementation is often much lower.
Again, this is a productivity argument, not a performance argument.
And it is invalid: all one needs to do is obtain a suitable library and the same things can be done in C++. There is a large number of good quality C++ libraries, frameworks, and development tools available, either commercially or freely available, that allow rapid development of thigns like you describe. Just as there is a large number of Java libraries, frameworks, and development tools available to do things that aren't supported by Java out of the box.
Programmers (whether they use Java or C++) who would do such months of toil without seeing if alternatives are available, would probably be classified as morons by some.
I agree that execution speed should not be a principle argument, but hardware access is irrelevant to the majority of programmers in the real world.
The argument I suggest is one based on engineering trade-offs between several factors: one of which is execution speed.
All that says is that C is designed for some things that Java is not.And, for anyone who wants to continue the argument of which language is faster/slower/better/worse, just remember that the JVM is written in C!
The first C compiler was written in assembler, and the first C++ compilers were written in C just like the JVM. So, extending the absurdity of your argument, we should all be doing development in assembler. But it takes considerably more expertise to write efficient assembler or machine code than it does to write efficient C.
Last edited by grumpy; 01-09-2007 at 10:24 PM.
...and, so from now on, we'll do nothing but take your word for everything, since you've seen it. In other words, if you're going to bring it up, site the resource or leave it alone, since it is worthless without the sitation.
My example was trivial, but showed an order of magnitude of difference in speed execution between Java and C++.
Your argument about performance versus productivity and having available 3rd party libraries available for C++ have nothing in common with my lines of thought. It is a "pay in advance" or "pay as you go" kind of tradeoff. It has nothing to do with researching the "buy versus build" cost associated with 3rd party libraries. Even your argument doesn't account for the "total cost of ownership" of 3rd party libs when, after you buy and factor in support costs AND something still is broken or doesn't work as intended and is not adequately supported for your project needs...what then wise guy?
C++ blows Java away. If you believe otherwise, show me. My simple little example demonstrated very clearly that the "same code" in Java is an order of magnitude slower than the code in C++.
What say you of:
...which is the same code I posted previously without the printed statements for either.Code:C++ real 0m0.002s user 0m0.002s sys 0m0.000s Java real 0m0.146s user 0m0.082s sys 0m0.020s
What part of execution speed don't you understand?
If you're trying to say that it is possible for someone to manufacture some element of Java code that runs more clickly than some element of C++ code, who cares? If my car blows yours off the road, hey bubba, you're the loser in the race. What it sounds like you're trying to say is that Java's "valve springs" open more quickly, even though the car lost the race due to being 10x slower...WHO CARES? Java is a dog compared to C++. Show me the code where it is faster than C++ or try not to let your foot get stuck in your mouth while trying to tell me what you've "seen."
:davis:
Oh my its decided! java is slower!
What do *you* think you're actually testing here? this is nothing more than a I/O system test of 1 java and c++ implementation.
And then, this just shows that you are a mediocre java programmer:
For instance, have you any idea what this line is doing?
System.out.println( i + " is an even number! " );
You're using way more objects and dynamic memory allocations than is necessary. Those not needed 1000 objects may trigger a garbage collection sweep which will of course make you app slower.
Try rewriting it with StringBuffer and Stringbuffer.append and give the results again
Last edited by Laserve; 01-10-2007 at 01:13 AM.
Get Stuffed! Don't try to act like I don't know what is happening "behind the scenes" simply because I used it in the manner shown in my "test." I started programming in Java with JDK v.71 on Solaris before it was supported on any other platforms. Did you happen to notice that I also wrote it without any output? C++ is still way faster. Some would argue due to the JVM startup time. I don't care why, C++ and Java side by side, C++ will always be faster.
Having discussed, at length, the thinking and activities that went into the creation of the Java programming language with James Gosling, I can say for sure that it wasn't ever meant to be a "better C++" as was offered by CornedBee. In fact, Gosling told me that the "best aspects of many" languages were borrowed from for the creation of Java, which was in response to my observerations of how Objective C-like it was in terms of GC, "import" vs include, "mother-of-all-objects" and single inheritance/interfaces.
So, the bottom line is Java is for those who can't program in C++!
As for being a mediocre Java programmer, at least I know that Java is capitalized!
...but, since you're the expert Java programmer and I'm simply mediocre, maybe you'll realize that there isn't even a need for a StringBuffer and the append call?!
Java is a DOG WITH FLEAS...if you need speed, you need C!Code:final class even_numbers { public static void main( String[] args ) { for( int i = 0; i < 1000; i++ ) { if( i % 2 == 0 ) { //System.out.println( i + " is an even number! " ); System.out.print( i ); System.out.println( " is an even number! " ); } } } }; real 0m0.185s user 0m0.135s sys 0m0.034s C++ real 0m0.017s user 0m0.002s sys 0m0.002s Java using StringBuffer (not printing the contents of the SB) real 0m0.138s user 0m0.082s sys 0m0.018s Java using StringBuffer (printing the contents of the SB) real 0m0.189s user 0m0.134s sys 0m0.024s
And, since you're the world's gift to Java, maybe you'd be happy to learn that the JDK documentation recommends using StringBuilder over StringBuffer in single threaded applications. I'll quote the JDK documentation:
"Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations."
:davis:
