Java vs. C++
-
yes, but optimization is something that is not everytime clear/sure for the user...look at your words:
jhwurmbach wrote:
he optimizer should have taken care of this
the only way to know what appens after compile is to look to the assembler code...or, better, don't think to compare the same code written in different languages without considering optimizations, code-shortcuts, assembler translation, ... Optimization is a too wide chapter to think to understand everithing with only a sample code:(
Russell
Russell` wrote:
optimization is something that is not everytime clear/sure for the user
Sure. Mike Dimmik did his study while I was writing my reply. I got 19,3 and 3,4*10^-7 seconds in debug and relase, respectivly. I took this as "quite a lot" and "practically nothing" and asked where the 2,5 seconds came from. I doubt that there is a computer 10 times as fast as my double Xeon 2.4 Ghz...
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words -
Russell` wrote:
optimization is something that is not everytime clear/sure for the user
Sure. Mike Dimmik did his study while I was writing my reply. I got 19,3 and 3,4*10^-7 seconds in debug and relase, respectivly. I took this as "quite a lot" and "practically nothing" and asked where the 2,5 seconds came from. I doubt that there is a computer 10 times as fast as my double Xeon 2.4 Ghz...
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words -
Anyone have any idea if Java is faster than C++ at run time? This code was executed and it took java 2.5 secs to complete whereas it took c++ 11 secs. Any input is appreciated. thanks, long start_time = System.currentTimeMillis(); System.out.println("Starting... "); for (int i = 0; i < 1000000000; i++) { int j = 5; j++; j *= 2; j /= 2; j--; double k = 5.0; k++; k *= 2; k /= 2; k--; } System.out.println("Ending. Time taken: " + (System.currentTimeMillis() - start_time) + " milisec");
Thats because java has an internal piece of code that gets inserted secretly that resembles this... for (int i = 0; i < 1000000000; i++) // *************************** // Java specific internal code if ((bInVeryBigLoop==true) && (bCodeServesNoObviousPurpose==true)) { // User must be running a benchmark against c++ break; } // End java specific internal code // ******************************* int j = 5; j++; j *= 2; j /= 2; j--; double k = 5.0; k++; k *= 2; k /= 2; k--; }
-
Not sure i understand why this is not an fair assessment. Can you elaborate when you say that i am comparing apples to oranges?
For one, how can you verify that the loops were fully processed without some output of the value in the end? You need to modify a value on each iteration, and use the final value in some output in both systems to prevent optimizations in Java from throwing the whole loop away and not even processing it. You may be the victim of a false positive since it may not have processed things as you think in both environments. You need to understand what happens in optimized and debug modes to properly set up your benchmarks and to fully appreciate and digest the results of your tests. You can inadvertantly benchmark using debug mode so make sure, if you haven't already, to only benchmark in releasemode.
-
In fact, the optimizer should have taken care of this. It should, in fact, have made the int into a register. What went wrong?
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening wordsjhwurmbach wrote:
What went wrong?
answer:
jhwurmbach wrote:
should have
/\ || right there. Don't assume the compiler fixes everything. Compile time is the absolute worst time to try to figure out what a programmer "wants" to achieve and then attempt to get there. Some compilers do a better job than others, so it depends on which compiler you are using. Is that a Fuji apple or a Granny Smith? :) I am not saying every programmer has to learn what the compiler does with their code. But if you are actually concerned with, or absolutely need performance, then you MUST know what the compiler will do with your code. Hand tuning an algorithm might take half an hour and save you 75% of your execution time. A large error could save you considerably more. A compiler can only do so much with junk code before it also outputs junk. Compilers aren't mind readers and none that I know of have heuristic analysis to try to figure out what your intent was. Until they make a mind reading compiler, we're all in the same boat. A compiler actually listens to what we tell it, even when we want it to obey what we mean, not what we type.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
jhwurmbach wrote:
What went wrong?
answer:
jhwurmbach wrote:
should have
/\ || right there. Don't assume the compiler fixes everything. Compile time is the absolute worst time to try to figure out what a programmer "wants" to achieve and then attempt to get there. Some compilers do a better job than others, so it depends on which compiler you are using. Is that a Fuji apple or a Granny Smith? :) I am not saying every programmer has to learn what the compiler does with their code. But if you are actually concerned with, or absolutely need performance, then you MUST know what the compiler will do with your code. Hand tuning an algorithm might take half an hour and save you 75% of your execution time. A large error could save you considerably more. A compiler can only do so much with junk code before it also outputs junk. Compilers aren't mind readers and none that I know of have heuristic analysis to try to figure out what your intent was. Until they make a mind reading compiler, we're all in the same boat. A compiler actually listens to what we tell it, even when we want it to obey what we mean, not what we type.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
We were concerned with the speed of execution, and when the compilers optimisation did not kick in (as it should), I asked "Why?" On the whole, I agree. This is part of why the original posting was so sensless: What good is a fast nonsense-loop, when all Java-applications have a sluggish GUI anyway? :rolleyes::cool: When the application has a bottleneck you determine it and fix it. Probably with a design change or a different algorithm. But you certainly are not paied for doing the compilers work. It has to, and will, optimize code in a way I can not possibly do by hand.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words -
Thats because java has an internal piece of code that gets inserted secretly that resembles this... for (int i = 0; i < 1000000000; i++) // *************************** // Java specific internal code if ((bInVeryBigLoop==true) && (bCodeServesNoObviousPurpose==true)) { // User must be running a benchmark against c++ break; } // End java specific internal code // ******************************* int j = 5; j++; j *= 2; j /= 2; j--; double k = 5.0; k++; k *= 2; k /= 2; k--; }
This comes scaringly close to reality... :laugh:
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words -
0, if you build an optimized version of the C++ code (see my full answer below, but basically the C++ compiler works out that the body of the loop is a no-op and throws the whole loop away!)
Stability. What an interesting concept. -- Chris Maunder
-
We were concerned with the speed of execution, and when the compilers optimisation did not kick in (as it should), I asked "Why?" On the whole, I agree. This is part of why the original posting was so sensless: What good is a fast nonsense-loop, when all Java-applications have a sluggish GUI anyway? :rolleyes::cool: When the application has a bottleneck you determine it and fix it. Probably with a design change or a different algorithm. But you certainly are not paied for doing the compilers work. It has to, and will, optimize code in a way I can not possibly do by hand.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening wordsjhwurmbach wrote:
We were concerned with the speed of execution, and when the compilers optimisation did not kick in (as it should), I asked "Why?"
how do you know it did not kick in? it may have assumed you needed that code. Some people use hard coded timing loops without external references as timing loops. It all depends on which compiler you use, what options you set, and what assumptions you allow your compiler to use. Knowing what this means to your code is very important. If you, as some people have, used dead-code as a sleep, then you may not want that optimized. Does your compiler have an option to remove unused code? See, it is more than a "magic" compile and it works.
jhwurmbach wrote:
a different algorithm
exactly my point as a matter of fact. If you know your compiler optimizes certain algorithms faster than others, because it is able to understand the logic, you begin adapting your code algorithms to match the compiler without even knowing it. The problem with that is that when you compile the same code on a new compiler, suddenly the performance changes. The reason is either consciously or inadvertently you have tuned the code to match the optimization of that one compiler, not the new one. Knowing the strengths and weaknesses of your own compiler is not a bad thing. As I said, I understand that if you are not concerned with performance, you don't need to do this. But if you really are concerned with performance, writing code that cooperates with the optimization analysis of the compiler is certainly a good thing.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I don't think the Java-to-bytecode compiler has different options here. I'm more familiar with C#, where the C#-to-IL compiler
cscdoes have a/debugoption. This has the effect of inserting a certain number ofnopIL instructions to ensure that line number information lines up and that you can put a breakpoint on some lines that otherwise wouldn't be possible (for example on the closing brace of a block). Further, it emits aDebuggableAttributewhich the JIT compiler detects - this disables JIT optimizations to make the code easier to debug. I don't know if Java JIT compilers have similar options. Compiling a similar C# program with C# 2.0 gives 10.8s on my home computer with/debug:fulland 1.078 second with/debug:pdbonly. With/debug-it's 1.062s. I should say here that my home computer ran the unoptimized C++ version in 14.4s - it's a Core 2 Duo T7200-based laptop (2.0GHz) whereas my work computer is a P4 3.0GHz with HyperThreading enabled. It looks, from sticking a call toSystem.Diagnostics.Debugger.Breakat the top ofMainand looking at the disassembly in VS, like it's managed to eliminate the contents of the loop but not the loop itself; however, it's keeping and manipulating the loop counter variable in a register.Stability. What an interesting concept. -- Chris Maunder