Java vs. C++
-
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