[*sigh*] I didn't really want to get into this one deeply. Why does
everyone insist on taking and ripping apart even the illustrative
examples. :(
Right, simple answer all in one mail.
Bo Nygaard Bai wrote:
> I would have to disagree with you on that Justin. But only because
> the first loop runs count times and the second runs count-1 times.
> So I'll assume you meant:
>
> for (int i = 0; i < count; i++)
>
> Old hackers makes mistakes too, ehh [:-)]
Actually, no, you made the mistake. Take a look carefully at the loop
invariant part. The instrucion is exactly:
--i >= 0
i is set as the loop pre-condition, then the invariant is calculated.
The first instruction is --i. The variable i is decremented *before* it
is used, therefore the real value of i first time through the loop is
actually count - 1. ie, both loops execute the same number of times. If
the loop condition was i-- then the variable i is checked for the other
conditions ( >= 0 ) and then it is decremented after use (try doing this
in a real application where you use i for accessing an array and see how
quickly you start generating exceptions and then try to debug why).
> The key to the trick is the way the compare (CMP) and branch (BGE)
> instructions are tied together. The branch looks at some flags inside
> the CPU to know if it should jump. The CMP instruction sets these
> flags depending on the result of the comparison.
While this is a partial answer, the other half lies in the way that most
CPUs, both modern and ancient have their instruction sets organised.
Almost every CISC CPU you care to mention has a specific instruction
usually called something like
DCNZ - which is roughly translated as Decrement register and then
compare the value to be [not equal to | less than ] zero. That is, a
specific, optimised, single instruction explicitly designed for loop
invariant calculations. I don't have any reference books handy, but IIRC
the x86 CPU core executes this in 7 clock cycles. If you were to do the
equivalent in normal instructions, it jumps to about 14 clock cycles, if
you have the increment loop, about 20. The net effect, on very tight
loops that you will find in the core of most 3D graphics applications,
is a very significant performance increase. On some really old Z80 code
I wrote it used to be an extremely significant performance increase (LED
billboard rendering etc).
****But****, if you start doing silly things like huge array index
operations or anything that jumps you out of the cache then the effect
is lost and a waste. You have to examine exactly what you are doing in
code to know whether it is going to be any benefit.
Now, the interesting thing to note is that this sort of optimisation in
Java is almost non-existant. IIRC, there is no equivalent java opcode
(been a long time since I've looked at it). A good JIT compiler may pick
up this construct, and certainly hotspot type dynamic compilers will and
so you will still gain some performance boosts *in some situations*. It
is not guaranteed, but you certainly don't get any decreases.
If people are really interested in knowing some basic performance
optimisations, the SGI guys run a course every year a Siggraph called
Advanced Rendering Optimisations (I think). It goes through all sorts of
interesting stuff, of which maybe half are applicable to Java/Java3D
coding. Simple things like increment v decrement loops, loop
unravelling, array index access etc etc.
FWIW, making 4 simple changes to the average piece of code would yield a
25% performance increase without creating any maintainability
nightmares.
--
Justin Couch http://www.vlc.com.au/~justin/
Freelance Java Consultant http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
