DiskMan wrote:
> Well this was a question I posted sometime ago and didn't get an answer... I
> went ahead and compiled GCC-4.0.1 and ran a few speed tests, Compaq C still
> dusts it... Hell, in comparison to older releases of GCC there's no speed
> diff at all unless you compare to something ancient like GCC-2.96. Well I
> can dream.... Will L G
>
>

post your speed tests. and what did you recompile in order to get this
increase in speed?

I used it on OpenSSL [which is optimized for the Alpha to begin with] and
ran openssl speed rsa and the like... Then I compared the results to one
another and to a previous post [pulled up in google news]. Will L G

PS oh, just google for alpha openssl speed rsa


"uNiX pSyChO" wrote in message
news:ej9bq2-mhu.ln1@xsssvr.xssnet.com...
> DiskMan wrote:
> > Well this was a question I posted sometime ago and didn't get an
answer... I
> > went ahead and compiled GCC-4.0.1 and ran a few speed tests, Compaq C
still
> > dusts it... Hell, in comparison to older releases of GCC there's no
speed
> > diff at all unless you compare to something ancient like GCC-2.96. Well
I
> > can dream.... Will L G
> >
> >
>
> post your speed tests. and what did you recompile in order to get this
> increase in speed?

Welp, just tried it on GTK, Fluxbox and GCC-4.0 isn't bad.. I notice a
little bit of a speed kick with GTK over the 'regular' compile while Fluxbox
is outrageously snappy but I've yet to test it with another compiler. There
might be a little 'something' to GCC-4.0 afterall... have to test it on a
few more apps and see how it performs... Will L G

"uNiX pSyChO" wrote in message
news:ej9bq2-mhu.ln1@xsssvr.xssnet.com...
> DiskMan wrote:
> > Well this was a question I posted sometime ago and didn't get an
answer... I
> > went ahead and compiled GCC-4.0.1 and ran a few speed tests, Compaq C
still
> > dusts it... Hell, in comparison to older releases of GCC there's no
speed
> > diff at all unless you compare to something ancient like GCC-2.96. Well
I
> > can dream.... Will L G
> >
> >
>
> post your speed tests. and what did you recompile in order to get this
> increase in speed?

" DiskMan" writes:

> Welp, just tried it on GTK, Fluxbox and GCC-4.0 isn't bad.. I notice a
> little bit of a speed kick with GTK over the 'regular' compile while Fluxbox
> is outrageously snappy but I've yet to test it with another compiler. There
> might be a little 'something' to GCC-4.0 afterall... have to test it on a
> few more apps and see how it performs... Will L G

Test something that's heavy on floating point, like povray.

--
Måns Rullgård
mru@inprovide.com

Now thats an idea... I have povray compiled with CCC... just test it against
GCC-4.0.1 and see what it can do... Good idea...
"Måns Rullgård" wrote in message
news:yw1xbr4xwcd6.fsf@inprovide.com...
> " DiskMan" writes:
>
> > Welp, just tried it on GTK, Fluxbox and GCC-4.0 isn't bad.. I notice a
> > little bit of a speed kick with GTK over the 'regular' compile while
Fluxbox
> > is outrageously snappy but I've yet to test it with another compiler.
There
> > might be a little 'something' to GCC-4.0 afterall... have to test it on
a
> > few more apps and see how it performs... Will L G
>
> Test something that's heavy on floating point, like povray.
>
> --
> Måns Rullgård
> mru@inprovide.com

" DiskMan" writes:

> "Måns Rullgård" wrote...
>> " DiskMan" writes:
>>
>> > Welp, just tried it on GTK, Fluxbox and GCC-4.0 isn't bad.. I
>> > notice a little bit of a speed kick with GTK over the 'regular'
>> > compile while Fluxbox is outrageously snappy but I've yet to test
>> > it with another compiler. There might be a little 'something' to
>> > GCC-4.0 afterall... have to test it on a few more apps and see
>> > how it performs... Will L G
>>
>> Test something that's heavy on floating point, like povray.
>
> Now thats an idea... I have povray compiled with CCC... just test it against
> GCC-4.0.1 and see what it can do... Good idea...

I remember having to use -mieee when compiling povray with ccc.
Otherwise the rendered images would look quite weird. Unfortunately,
-mieee can slow things down a bit. Is that flag still required?

--
Måns Rullgård
mru@inprovide.com

Na I didn't use mieee, thought about it though... I do have a few probs with
the CCC/GCC, they will segfault if you use the 'wrong' option in the
povray.ini file. Haven't found a good way around that one... Normally it
will segfault on something called "Parsing 20K tokensSegmentation fault" and
another, something about calculating floats... I don't happen to have a copy
of that one. It affects both CCC and GCC by the way...

Here are the flags that I used to 'decrease' the chances of segfault:
CC="ccache ccc" CXX="ccache cxx" \
CFLAGS="-O5 -inline speed -fast -mtune=pca56 -w -pipe" \
CXXFLAGS="-O5 -inline speed -mtune=pca56 -w -pipe -std ansi \
-ansi_alias -float -fp_reorder -assume trusted_short_alignment \
-ansi_args -intrinsics -D_INTRINSICS -D_FASTMATH -D_INLINE_INTRINSICS \
-nousing_std -D__USE_STD_IOSTREAM" \
./configure \
COMPILED_BY="Will L G " \
--build=alphapca56-alpha-linux-gnu \
--sysconfdir=/etc \
--prefix=/usr \
--enable-static \
--enable-shared \
--disable-dependency-tracking \
--with-x \
--enable-watch-cursor \
--disable-optimiz

"Måns Rullgård" wrote in message
news:yw1xhdelod6b.fsf@inprovide.com...
> " DiskMan" writes:
>
> > "Måns Rullgård" wrote...
> >> " DiskMan" writes:
> >>
> >> > Welp, just tried it on GTK, Fluxbox and GCC-4.0 isn't bad.. I
> >> > notice a little bit of a speed kick with GTK over the 'regular'
> >> > compile while Fluxbox is outrageously snappy but I've yet to test
> >> > it with another compiler. There might be a little 'something' to
> >> > GCC-4.0 afterall... have to test it on a few more apps and see
> >> > how it performs... Will L G
> >>
> >> Test something that's heavy on floating point, like povray.
> >
> > Now thats an idea... I have povray compiled with CCC... just test it
against
> > GCC-4.0.1 and see what it can do... Good idea...
>
> I remember having to use -mieee when compiling povray with ccc.
> Otherwise the rendered images would look quite weird. Unfortunately,
> -mieee can slow things down a bit. Is that flag still required?
>
> --
> Måns Rullgård
> mru@inprovide.com

(Top-posting worked around.)

> "Måns Rullgård" wrote in message
>>
>> I remember having to use -mieee when compiling povray with ccc.
>> Otherwise the rendered images would look quite weird. Unfortunately,
>> -mieee can slow things down a bit. Is that flag still required?

On 2005-07-23, DiskMan wrote:
> Na I didn't use mieee, thought about it though... I do have a few probs with
> the CCC/GCC, they will segfault if you use the 'wrong' option in the
> povray.ini file. Haven't found a good way around that one... Normally it
> will segfault on something called "Parsing 20K tokensSegmentation fault" and
> another, something about calculating floats... I don't happen to have a copy
> of that one. It affects both CCC and GCC by the way...

Just in case a bit of tribal knowledge has gone away, back
in the days of RedHat 7.2 on Alpha, it was necessary to use
-mieee when compiling any serious floating point program.
Without that option, a gradual underflow situation will
cause a fault. However, it was a floating point exception,
not a segmentation fault--although the description by
DiskMan does leave a little doubt about that observation.

At the time I asked about the -mieee option, the experts
around at that time said it would slow down the program. I
didn't do a lot of benchmarking, but I did make a few speed
measurements, and I never saw a significant slowdown.

If in doubt, why not compile once with and once without,
then run both programs on the same input and compare results
and CPU time?

Robert Riches
spamtrap42@verizon.net
(Yes, that is one of my email addresses.)

(I miss my Alpha...)

"Robert M. Riches Jr." writes:

>> "Måns Rullgård" wrote in message
>>>
>>> I remember having to use -mieee when compiling povray with ccc.
>>> Otherwise the rendered images would look quite weird. Unfortunately,
>>> -mieee can slow things down a bit. Is that flag still required?
>
> On 2005-07-23, DiskMan wrote:
>> Na I didn't use mieee, thought about it though... I do have a few
>> probs with the CCC/GCC, they will segfault if you use the 'wrong'
>> option in the povray.ini file. Haven't found a good way around that
>> one... Normally it will segfault on something called "Parsing 20K
>> tokensSegmentation fault" and another, something about calculating
>> floats... I don't happen to have a copy of that one. It affects
>> both CCC and GCC by the way...
>
> Just in case a bit of tribal knowledge has gone away, back
> in the days of RedHat 7.2 on Alpha, it was necessary to use
> -mieee when compiling any serious floating point program.
> Without that option, a gradual underflow situation will
> cause a fault. However, it was a floating point exception,
> not a segmentation fault--although the description by
> DiskMan does leave a little doubt about that observation.

The floating point exception without -mieee is not the only thing that
can go wrong. It's a while ago, so I can't remember the details
exactly, but I compiled povray with ccc and all optimizations turned
on. The result worked fine for most images, but some had strange
errors in them. On the chess board sample included, all the pieces
came out as colored blobs. IIRC, it was related to the use of focal
blur.

> At the time I asked about the -mieee option, the experts
> around at that time said it would slow down the program. I
> didn't do a lot of benchmarking, but I did make a few speed
> measurements, and I never saw a significant slowdown.

Using -mieee can cause a significant slowdown. How much depends on
the application. The documentation for the option might give some
clues:

-mieee
The Alpha architecture implements floating-point hardware
optimized for maximum performance. It is mostly compliant with
the IEEE floating point standard. However, for full compliance,
software assistance is required. This option generates code fully
IEEE compliant code _except_ that the INEXACT-FLAG is not
maintained (see below). If this option is turned on, the
preprocessor macro `_IEEE_FP' is defined during compilation. The
resulting code is less efficient but is able to correctly support
denormalized numbers and exceptional IEEE values such as
not-a-number and plus/minus infinity. Other Alpha compilers call
this option `-ieee_with_no_inexact'.

--
Måns Rullgård
mru@inprovide.com