RE: Fibonacci and performance

[Jeff Sturm <jsturm at one-point dot com>]

On Tue, 1 May 2001, Anthony Green wrote:
> Jeff wrote:
> > That could be a problem.  It would be fine if m_l_f were initialized to
> > zero.
> 
> The original implementation had it initialized to zero.  Tom added what
> seemed like a good optimization at the time (initialization from the Class
> object).

Tom's modification essentially inlines the klass->state test from
_Jv_InitClass.  That's OK... the problem as I understand it is that the
test in _Jv_InitClass wasn't safe.

> Is it true that all we need to do is to introduce some kind of
> re-ordering barrier so that neither the compiler nor the hardware would
> reorder these instructions?

I think so.  There might be a cheaper way though.  I like Hans's idea of
using volatile where it helps, like Itanium.  Long term it'd be nice to
have better support in GCC for all multiprocessor architectures.

There are other tradeoffs.  I liked the original patch because the
automatic variable could be optimized away in many instances (in theory, I
didn't check).  Now that it is initialized to a non-constant it will
always take a register.  I took a look at some generated code today and it
is awful... at -O2 a basic block is still generated for every call to
_Jv_InitClass, even though most will never be called.  That warrants some
more investigation.

Reaching a good balance of size vs. efficiency is hard for all
machines.  Perhaps frontend optimizations like this should be sensitive to
optimization level, i.e. -Os, -O3, etc.

Jeff