Speed of C++

Originally Posted by bobthebullet990

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!!!

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.

Originally Posted by Daved

>> You sure can see past the apparent sttrictness of my previous post.
I felt that your exaggeration was misleading and offered my take on the subject. "Arrays are evil" statements are fine, IMO, because in 99% of cases that is true and in many cases the beginner doesn't realize that the number is that high. However, identifying which solution is more appropriate for a given problem is perfectly acceptable, and hyperbolic statements implying that speed never matters in such a discussion are just wrong. Speed does matter and should be taken into consideration even if the final resolution is that the speed difference is negligible.

Well, I suspect Mario's tongue was firmly in cheek when he wrote his post. But his basic message is right: people tend to focus much more on speed/performance of an application than is really necessary.

That is true of developers, hence the phenomenon of premature optimisation. That causes problems because it often turns out that premature optimisations often, in the long run, do not optimise performance at all because a compiler (which is designed with knowledge of the target machine) can often do it better than a human -- and also because, in worst cases, some premature optimisers sacrifice correctness to achieve speed and that causes a future maintenance nightmare. Professionals will focus on getting the application running correctly and then, with the help of tools like profilers, find the hot spots in an application. In other words, the performance optimisation is performed late in the development cycle, not early.

End users will focus on speed/performance when they don't need to. And, by doing so, they sacrifice their own productivity. With a word processor, for example, the speed of a particular operation rarely matters as much as the higher level features offered by the tool (eg being able to reduce errors due to typos, misspelling, grammar, incorrect referencing, ability to do backups, etc etc). But users will tend to complain about things like slow startup, speed of saving a file to disk, etc etc. Performance of such things CAN be important, but users emphasise them much more in problem reports than is necessary -- they are functions for which correctness is more important than speed. In worst cases, in some problem domains, I've encountered end users who insist on "real time performance" (by which they mean things like "instantaneous response to a GUI", not the real technical meaning) and, when given a choice between correctness and performance, will always choose performance. Despite formal analysis in those domains, in some cases, which shows that correctness is necessary for mission success, human safety, etc. My basic message is that, even when users focus on performance, the developer is doing them a disservice by catering to them.

In the (relatively rare) cases where performance is really important, it is skill of the developer that is most important. In practice, C++ will often be faster than Java, simply because it doesn't have overheads such as a virtual machine and the compiler has more opportunities to optimise for performance by getting closer to the target machine. There are also performance issues as the Java library is not as heavily optimised as the standard C++ or C libraries that are associated with most good quality compilers. The "safety" in Java usually comes at a cost -- and one of those costs is usually performance. On the other hand, in some areas, a Java application will be faster than a C++ application because Java is optimised for some types of application that C++ isn't. Consider things like distributed component frameworks (aka Beans) and it often turns out that a suite of applications written in Java will, collectively, outperform a comparable suite of similar applications written in C++ because the Java frameworks are better optimised for distributed work and more directly accessible to the developer (the balance, however, is pulled back to C++ by use of good-quality libraries, such as CORBA ORBs, written in C++). Run time techniques in Java (eg JIT) can also result in performance gains for certain types of Java applications in comparison with C++.

But, in the wider world, choice of language is not that important. I would bet in favour of a skilled developer, in either language, over an unskilled developer in the other language --- any day. Both in terms of achieving performance by squeezing the most from the tools (should that be required) and correctness.

Originally Posted by Laserve

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++

Code:

real    0m0.023s
user    0m0.002s
sys     0m0.002s

Java (v1.5.0)

Code:

real    0m0.313s
user    0m0.138s
sys     0m0.030s

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! " );
            }
        }
    }
};

C++ blows Java away in every single execution speed category where the programmer isn't totally STUPID.

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:

Just out of curiosity, what happens if you optimize by replacing "i < 1000" by "i != 1000" and "i % 2" by "i & 1"? (I don't have the JDK installed.)

Originally Posted by :davis:

C++ blows Java away in every single execution speed category where the programmer isn't totally STUPID.

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.

Originally Posted by :davis:

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++.

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.

Originally Posted by :davis:

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.

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.

Originally Posted by :davis:

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.

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.

Originally Posted by :davis:

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.

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.

Originally Posted by :davis:

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!

All that says is that C is designed for some things that Java is not.

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.

Originally Posted by grumpy

I have seen numerical benchmarks where professionally written Java code convincingly out-performed professionally written C++ code....

...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:

Code:

C++
real    0m0.002s
user    0m0.002s
sys     0m0.000s

Java
real    0m0.146s
user    0m0.082s
sys     0m0.020s

...which is the same code I posted previously without the printed statements for either.

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:

Why should I go find one for you? This topic is a total waste of bandwidth. Go grab a search engine and do your own search.

You want to prove Java is faster? I can find a benchmark to prove it. You want C++ to be faster than Java? I can find a benchmark to prove that too.

I can find a benchmark out there to prove anything I want. That's why they're all worthless.


Quzah.

Originally Posted by robatino

Just out of curiosity, what happens if you optimize by replacing "i < 1000" by "i != 1000" and "i % 2" by "i & 1"? (I don't have the JDK installed.)

Here is another example:

Code:

C++

int main()
{
    int i = 0;
    do
    {
        ++i;
    } while( i != 1000 );
}

real    0m0.001s
user    0m0.000s
sys     0m0.001s

Java

final class speed
{
    public static void main( String[] args )
    {
        int i = 0;
        do
        {
            ++i;
        } while( i != 1000 );
    }
}

real    0m0.142s
user    0m0.077s
sys     0m0.026s

:davis:

I can prove that C++ is slower than C++. Did you know that?

Not all compilers are created equal. The point is, your "benchmarks" are a joke.


Quzah.

Originally Posted by quzah

Why should I go find one for you? This topic is a total waste of bandwidth. Go grab a search engine and do your own search.

You want to prove Java is faster? I can find a benchmark to prove it. You want C++ to be faster than Java? I can find a benchmark to prove that too.

I can find a benchmark out there to prove anything I want. That's why they're all worthless.


Quzah.

I like the sited (from your Wikipedia link):

http://www.jelovic.com/articles/why_java_is_slow.htm

...or:

"Why Java Will Always Be Slower than C++

by Dejan Jelovic"


...and, if this topic is such a waste of bandwidth, why are you contributing to it?


:davis:

Because I have plenty of bandwidth to waste.


Quzah.

Please stop asking this stupid question.

We don't care which is faster. If you want to use Java then go ahead. Why do all the Javaaites always insist on trying to making everyone see thing their way. Maybe they think they have to in order to justify the existence of such a horrid language.

Dunno.

Originally Posted by bobthebullet990

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

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.

Oh my its decided! java is slower!

Originally Posted by :davis:

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! " );
            }
        }
    }
};

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

I like Java, I prefer C++, I like Perl, I dislike Python.

What does that mean in the grand scheme of things? Eh, nothing.

I hate performance tests like the above, yay your implementation of C++ can count faster than your implementation of Java. And yes, C++ will most likely outperform Java by far every time in that test. How about you write the same exact thing in ASM, and LISP, Perl, that way we can hit each type of language and in truth, compare and create absolutely useless information.

Java's perk is that it can be 'compiled' once and run everywhere, it is a higher level language than C++ and isn't meant to fill the shoes of it, it is meant to have portability, good OOP design from the ground up, and lots of built-ins.

Sure you can write the same program in both of them, then try to optimize them as much as you can, then compare speed. But, really is that the only measure of a program? What about deadlines? Preferred technology by manager/bean counters? The target platform(s)?

There are too many variables to define one as the superior language, last time I checked, speed isn't everything. Programs getting completed and maintained, now that is something that is important, and that depends on the programmer(s), if they aren't happy with the language (and it is a home project) don't expect the program any time soon.

I prefer C++, but I have intentionally used Java so that I didn't have to worry much about the portability of my code and my friends with Macs could use my application too.

So how about every stops stroking their epeen's in an effort to see has the larger one, they are tools, different tools are better for different jobs.