Forum:

Performance

if-else

Greenhorn

Posts: 7

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Which is going to be faster?

[Ajith Kallambella added code tags ]
[This message has been edited by Ajith Kallambella (edited October 31, 2000).]

Ajith Kallambella

Sheriff

Posts: 5782

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I think the first prototype (1) is faster than the second unless the <code>continue</code> statement has no overheads.
In version (1) the loop implicitly continues after execution of some_code_1 OR some_code_2. Whereas in version (2) with each time the if condition evaluates to true, the </code>continue</code> is explicitly called.
I am not a performance guru, so I may be wrong

Ajith

Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).

Jack Shirazi

Author

Posts: 96

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

There is a common misconception that what you write is what gets translated into Java bytecodes. This is not the case. The compiler is at liberty to mangle the code in whatever way it sees fit, as long as the bytecodes that come out are functionally identical to the source code functionality. Normally, the compiler tries to optimize the code. In the case of these two loops, you can never say which will be faster, since the two loops are functionally identical and it is up to the compiler how to convert them into bytecodes.
Using the Sun 1.3 compiler on these two loops, I get identical bytecodes. This means that <em>for that compiler</em> the loops have identical speed (they <em>are</em> identical). Another compiler might compile these loops differently (though I doubt it). This issue can matter for more complex code, but simple code is generally treated in the same consistent way by most compilers.

raj koura

Greenhorn

Posts: 11

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

i think the first code is going to run faster. the continue statement in the second code is certainly going to have some overheads. the while loop contains a jump and continue will have another.
it is not true that java compiler mangles the source code to suit its convenience.
raj koura

Frank Carver

Sheriff

Posts: 7001

I like...

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I'm with Jack.
The bit you have to always remember is that Java does not execute your source code. The Java Compiler first converts your source code to bytecodes, and at this point it is free to generate whatever bytecodes it likes which have the same explicit functionality as your source code.. Then a JVM executes the bytecodes, and the JVM is also free to compile, pipeline, or optimize the execution of the bytecodes, again as long as it has the same explicit functionality.
The explicit functionality is the same for the two examples given. They both have a loop which executes one of two blocks based on specified criteria. How that is expressed in Java (or, indeed in any of the otrher languages which compile to bytecodes) is immaterial.

Read about me at frankcarver.me ~ LinkedIn ~ Frank's PhD research

Jack Shirazi

Author

Posts: 96

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

You can test this very easily for yourself. Compile the two versions into different methods or classes, then use the javap dissassembler with the -c option to see the Java assembler bytecodes. You'll see that the two loops compile identically.

Samuel Wolfe

Greenhorn

Posts: 12

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Can we put an OR-ELSE statement in there to preserve our own particular, peculiar little versions of our code?

Peter Haggar

author

Posts: 106

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Originally posted by Jack Shirazi:
There is a common misconception that what you write is what gets translated into Java bytecodes. This is not the case.

In theory this is not the case, but in practice today with most compilers it is. I have not tried all compilers, but all that I have tried generate very similar bytecode that is essentially what you write.

The compiler is at liberty to mangle the code in whatever way it sees fit, as long as the bytecodes that come out are functionally identical to the source code functionality. Normally, the compiler tries to optimize the code. [/B]

Again, I haven't tried all Java compilers, but the ones I have tried don't optimize anything beyond the most trivial cases. Yes, they fold constants, eliminate dead code (but only if the expression evaluates to false at compile time), and choose a more efficient switch construct when it's obvious. However, most don't go out of their way at all. None that I have seen inline, unroll loops, perform CSE, remove loop invariants, or many other trival optimizations.
Java compilers are no where near where C/C++/Fortran compilers are with optimization. Virtually all of the optimization is happening at runtime with JITs and Hotspot. One thing that bugs me is that JITs and Hotspot are performing simple optimizations at runtime that could be done at compile time. On the flip side, there are some things that you can do at runtime that you can't do at compile time that JITs and Hotspot do a good job on.
I've been told that Sybase has a Java compiler that performs quite a few optimizations, but I have not tried it. Jack, do you know about this or another bytecode compiler that does a good job?
Peter Haggar
------------------
Senior Software Engineer, IBM
author of: Practical Java

Senior Software Engineer, IBM
author of: Practical Java

Jack Shirazi

Author

Posts: 96

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

No. I know that DashO aimed to try to do these basic kinds of optimizations. But I never tried to decompile any DashO optimized code.
At one point Sun said they intended to roll basic optimizations in, but then they went backward and took out the ones they had. Then I understood there was some concept of having the basic free SDK compiler, and a not-free decent compiler. But that never happened either. I don't know why no one seems to be adding these really basic optimizations into their compilers.
Bill Venners once pointed out to me that because the JVM was virtual, there was no way of determining the actual speedup of many of these optimization on the processor they will run on. But on the other hand, I would have thought that the tried and trusted optimizations would work in practice.
--Jack http://www.JavaPerformanceTuning.com

Kirk Pepperdine

Author

Posts: 71

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Originally posted by Jack Shirazi:
[B]No. I know that DashO aimed to try to do these basic kinds of optimizations. But I never tried to decompile any DashO optimized code.
My experience with DashO is that you do get a fairly decient performance boost from it. (min of 10% IME).
I while back, I found a race condition between the garbage collector and anothe specialized internal process. The basis for the discovery was that we could influence who would win the race by either using Jikes or the JDK to compile with. These compilers definetly produce different byte codes from the same source. In this case, Jikes produced a more optimized version of the byte code.
Sparc CPU's (as well as others), but not all, are pipelined. If you look at the assembler that is produced by the compiler you'll quickly discover that many instructions are issued out of order. This is to take into account different hold issues and to calculate just in time delivery of results (so no one waits). My guess is that it would be difficult to optimize for different types of CPU's. That would be best left up to the JIT or HotSpot engine.
Kirk

Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0672324261/ref=jranch-20" target="_blank" rel="nofollow">Ant Developer's Handbook</a>

Peter Haggar

author

Posts: 106

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Originally posted by Jack Shirazi:
No. I know that DashO aimed to try to do these basic kinds of optimizations. But I never tried to decompile any DashO optimized code.

I haven't done this lately, but when I did it a while back, I wasn't impressed. Things could be better now though.

Bill Venners once pointed out to me that because the JVM was virtual, there was no way of determining the actual speedup of many of these optimization on the processor they will run on. But on the other hand, I would have thought that the tried and trusted optimizations would work in practice.

In theory, this is true. There is no common cost model for JVMs. The JVM spec says nothing about how much time an individual bytecode, or sequence of bytecode, should take. The only guarantee is what it does to the runtime stack, etc. Given this, you can't guarantee that rearranging bytecode will give a performance boost on different VMs.
In practice, however, I have been able to do it successfully. By rearranging the source code to generate more efficient bytecode, I have gotten some good speedups, in addition to making the .class file smaller. This tells me that the runtime optimizer was not performing the optimization. The caveat is that as runtime optimization technology improves (JITs/Hotspot), sometimes your efforts are wasted because they perform that optimization. They also have the advantage of knowing the processor they are on and can therefore optimize for it, although, this is happening at runtime.
Programmers in the embedded space who are using Java are very interested in better and smaller bytecode. They don't have space for JITs, much less Hotspot (to Sun's credit, they don't consider Hotspot an embedded solution.) Therefore, they are running fully interpreted and an optimized bytecode stream is very important to them.
Peter Haggar
------------------
Senior Software Engineer, IBM
author of: Practical Java

Senior Software Engineer, IBM
author of: Practical Java

Jack Shirazi

Author

Posts: 96

posted 25 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I checked through my stuff, and found that Jove (by instantiations) also claims to do all lots of classic optimizations. But is compiles to executables, not bytecode, so there's no way of verifying it.
--Jack http://www.JavaPerformanceTuning.com

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.