Compaq C vs GCC-4.0.1 - Linux

This is a discussion on Compaq C vs GCC-4.0.1 - Linux ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Compaq C vs GCC-4.0.1

  1. Compaq C vs GCC-4.0.1

    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



  2. Re: Compaq C vs GCC-4.0.1

    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?

  3. Re: Compaq C vs GCC-4.0.1

    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?




  4. Re: Compaq C vs GCC-4.0.1

    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?




  5. Re: Compaq C vs GCC-4.0.1

    " 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

  6. Re: Compaq C vs GCC-4.0.1

    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




  7. Re: Compaq C vs GCC-4.0.1

    " 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

  8. Re: Compaq C vs GCC-4.0.1

    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




  9. Re: Compaq C vs GCC-4.0.1

    (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...)

  10. Re: Compaq C vs GCC-4.0.1

    "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

+ Reply to Thread