compiler speed

[Stefan Reinauer]

Hi,

I played a bit with different gcc versions on Alpha and I
noticed that when executing the FIB test from
http://home.iae.nl/users/mhx/fib.html in paflof, results
are _a lot_ slower with gcc 3.1.1 than with 2.96 (SuSE 7.1
Alpha release) Not only is the 3.1.1 binary about 20%
bigger,
it also 22% slower.

The test:
HEX
: FIB ( x -- y ) RECURSIVE
        DUP 2 > IF DUP  1- RECURSE
                SWAP 2- RECURSE +  EXIT
        THEN    
        DROP 1 ;

28 FIB
BYE

The results:
gcc 2.96 binary
        real    1m55.642s
        user    1m55.479s
        sys     0m0.014s

gcc 3.1.1 binary
        real    2m21.763s
        user    2m21.533s
        sys     0m0.027s

Where does this come from? Is the code generated by gcc 3.x really that
slow, compared to 2.96? Do we make some assumptions that might cause
this? (How badly do gotos break code flow analysis for example?)

What can we do against this? Having more prim words will speed up the
whole thing, but probably not really make it easier for the compiler to
optimize.

Comments?

Stefan..

Stefan Reinauer wrote:
> Hi,
>
> I played a bit with different gcc versions on Alpha and I
> noticed that when executing the FIB test from
> http://home.iae.nl/users/mhx/fib.html in paflof, results
> are _a lot_ slower with gcc 3.1.1 than with 2.96 (SuSE 7.1
> Alpha release) Not only is the 3.1.1 binary about 20%
> bigger,
> it also 22% slower.
>
> [snip...snip]
>
> Comments?

22% difference is "like nothing" for me. A factor of 10 is "a lot" for me.

Sorry ;-)

Regards

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Klaus Seegebarth  [020618 12:08]:
> 22% difference is "like nothing" for me. A factor of 10 is "a lot" for me.

Agreed. As Parag said - A problem that needs the wrong thing to be done
20% faster is not very common. So issues like this can be looked at when
we have a system running..

Stefan

[Segher Boessenkool]

Klaus Seegebarth wrote:
> Stefan Reinauer wrote:
> > Hi,
> >
> > I played a bit with different gcc versions on Alpha and I
> > noticed that when executing the FIB test from
> > http://home.iae.nl/users/mhx/fib.html in paflof, results
> > are _a lot_ slower with gcc 3.1.1 than with 2.96 (SuSE 7.1
> > Alpha release) Not only is the 3.1.1 binary about 20%
> > bigger,
> > it also 22% slower.
> >
> > [snip...snip]
> >
> > Comments?
>
> 22% difference is "like nothing" for me. A factor of 10 is "a lot" for me.

1% speedup is a nice optimization, and 2% slowdown is a serious performance
regression.

22% slowdown is just awful.  Try compiling with -O2 or -Os (not -O3), and
playing with the several optimization switches (esp. some of the jump
optimization passes seem to cause more trouble than help).

I'll try to find out what's going on here exactly.

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

Segher Boessenkool wrote:
> > > [snip...snip]
> 1% speedup is a nice optimization, and 2% slowdown is a serious performance
> regression.
>
> 22% slowdown is just awful...

Hello Segher,

no flame war please, i appreciate Your work :-)
If you add "IMHO" to your statements, i will accept :-)

I only wanted to point out, that i have different needs than You.

My fastest and my slowest CPU differ by a factor of 1000 (100 000 % !)
in speed. Why should _i_ waste my time to look for 22% ?

As all my computers live inside a machine in a production
environment, the 3 most important items for me are reliability,
reliability and reliability. A major influence on reliability
is the amount of energy consumed, so what i am really interested in
is a gcc-switch, which optimizes to minimum energy per task.
A faster completion of a task only leads to longer idle periods :-)

Just my 2 EuroCents

Klaus

Please continue to look for 1% speedups, dont feel offenced, 
that i dont need them :-)

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

Klaus Seegebarth wrote:
> Segher Boessenkool wrote:
> > > > [snip...snip]
> > 1% speedup is a nice optimization, and 2% slowdown is a serious performance
> > regression.
> >
> > 22% slowdown is just awful...
>
> Hello Segher,
>
> no flame war please, i appreciate Your work :-)

i'm not flaming, i'm just stating facts ;)
> If you add "IMHO" to your statements, i will accept :-)
>
> I only wanted to point out, that i have different needs than You.

that's fine, of course.  and yes, there's more to good code than just
speed.
> My fastest and my slowest CPU differ by a factor of 1000 (100 000 % !)
> in speed. Why should _i_ waste my time to look for 22% ?

with the current state of paflof, it's easy to get it to speed up
at least 4x or so.  i'm not concerned with optimizing it just yet,
because "premature optimization is the root of all evil", as
everyone knows.  i'm just wondering why upgrading compiler version
causes a 22% slowdown, which is awful.  i'm esp. interested in this
because the cause for the slowdown is no doubt tightly related to
the threading model paflof uses, and there is no such thing as
premature design.  i need to make sure that gcc can do a good job
on paflof's indirect threaded interpreter.
> As all my computers live inside a machine in a production
> environment, the 3 most important items for me are reliability,
> reliability and reliability. A major influence on reliability
> is the amount of energy consumed, so what i am really interested in
> is a gcc-switch, which optimizes to minimum energy per task.
> A faster completion of a task only leads to longer idle periods :-)

well, during bootup a computer draws more power than during normal
operation, so to minimize power consumption, the bootup phase has to
be as short as possible; so paflof has to be as fast as possible q.e.d.

(hehe.  just kidding.  speed is not all that important for this, but
we don't want to have it run much slower for no good reason).

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Klaus Seegebarth  [020624 10:06]:
> As all my computers live inside a machine in a production
> environment, the 3 most important items for me are reliability,
> reliability and reliability. A major influence on reliability
> is the amount of energy consumed, so what i am really interested in
> is a gcc-switch, which optimizes to minimum energy per task.
> A faster completion of a task only leads to longer idle periods :-)

this is true in embedded systems for all tasks except booting.
There it means in case of a failure you can reduce the time until the
machine is able to fulfill it's tasks in 22% less time.
Still it's easy to outperform most of the commercial firmware stuff
without problems.

Stefan

Stefan Reinauer schrieb:
> Klaus Seegebarth  [020624 10:06]:
>
> [snip...snip]
> > A faster completion of a task only leads to longer idle periods :-)
>
> this is true in embedded systems for all tasks except booting.
> There it means in case of a failure you can reduce the time until the
> machine is able to fulfill it's tasks in 22% less time.

Yes, absolutely true :-)

But i never used more than 10 minutes of my day for booting 
(except the old VAX/VMS days). So a speedup of 22% will only
save me 2 minutes and some seconds. Thats why i say: _i_ dont care.
I want to save one _hour_ per day, this is what counts for me :-)

And that is why i am arguing: please make it simple enough,
that i can really _use_ it. If it gets too complicated, i will
need more time to make it running than i will gain by its usage.

Sorry for beeing so obstinate ;-)

Thanks

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..