EGCS-971016: i686 Linux vs. SparcULTRA Solaris

EGCS-971016: i686 Linux vs. SparcULTRA Solaris

[Fred Richardson]

I've run a quick benchmark on a program I've been debugging for a
while.  It's very C++'ified and makes heavy use of the STL.  It also
does a lot of floating point.  Here are some run-time stats when the
input parameters are the same on both machines:


Solaris2.5  UltraSPARC 170  (192 MB RAM, 830 MB VIRTUAL):
    TIME:   557.43s
    SIZE:   190832K

Linux2.0    i686            (386 MB RAM, 1.04 GB VIRTUAL):
    TIME:   359.37s
    SIZE:   138012K

On both architectures, EGCS was built with 
    --with-gnu-as --with-gnu-ld --enable-shared --enable-haifa

The flags used for compiling on the i686 were:
    -m486 -funsigned-char -fno-exceptions -O6 -finline-functions
     -ffast-math -fomit-frame-pointer -funroll-loops 

The flags used for compiling on the Ultra were:
    -mcpu=ultrasparc -funsigned-char -fno-exceptions -O6
    -finline-functions -ffast-math -fomit-frame-pointer -funroll-loops 

This seems like a remarkable difference.  I find the allocation
differences really suprising.  But I can't say that I have any idea
of what's going on.  I'm hoping someone else will find this data-
point enlightening ;)

                -Fred

Re: EGCS-971016: i686 Linux vs. SparcULTRA Solaris

[Oleg Krivosheev]

On Thu, 16 Oct 1997, Fred Richardson wrote:

> I've run a quick benchmark on a program I've been debugging for a
> while.  It's very C++'ified and makes heavy use of the STL.  It also
> does a lot of floating point.  Here are some run-time stats when the
> input parameters are the same on both machines:
> 
> 
> Solaris2.5  UltraSPARC 170  (192 MB RAM, 830 MB VIRTUAL):
                               ^^^^^^^^^^^
>     TIME:   557.43s
>     SIZE:   190832K
              ^^^^^^^

> 
> Linux2.0    i686            (386 MB RAM, 1.04 GB VIRTUAL):
>     TIME:   359.37s
>     SIZE:   138012K
> 
> On both architectures, EGCS was built with 
>     --with-gnu-as --with-gnu-ld --enable-shared --enable-haifa
> 
> The flags used for compiling on the i686 were:
>     -m486 -funsigned-char -fno-exceptions -O6 -finline-functions
>      -ffast-math -fomit-frame-pointer -funroll-loops 
> 
> The flags used for compiling on the Ultra were:
>     -mcpu=ultrasparc -funsigned-char -fno-exceptions -O6
>     -finline-functions -ffast-math -fomit-frame-pointer -funroll-loops 
> 
> This seems like a remarkable difference.  I find the allocation
> differences really suprising.  But I can't say that I have any idea
> of what's going on.  I'm hoping someone else will find this data-
> point enlightening ;)

sure it is enlightening...

your Ultra program should swap quite a lot...
Or you're measuring disk performance ? ;)

regards

OK

EGCS-971016: i686 Linux vs. SparcULTRA Solaris

[Teemu Torma]

    From:  Fred Richardson <frichard@bbn.com>
    Date:  Thu, 16 Oct 1997 23:27:00 -0400

    The flags used for compiling on the Ultra were:
        -mcpu=ultrasparc -funsigned-char -fno-exceptions -O6
        -finline-functions -ffast-math -fomit-frame-pointer -funroll-loops 
    
This may be a bit off from the topic, but

It seems that -mcpu=ultrasparc generates sometimes slower code 
than -mcpu=supersparc, and gcc 2.7.2.1 is faster than egcs.

I ran some speed tests last week using Eric Young's libdes `speed'
program.  These were the results, without haifa, 
on Sun Enterprice 450 (248Mhz UltraSparc).  Of course this kind
of test is not a good general speed test, but still...

EGCS 971008 -O3 -mcpu=supersparc

set_key       per sec =    212606.48 (  4.7uS)
DES ecb bytes per sec =   2930562.93 (  2.7uS)
DES cbc bytes per sec =   2909686.20 (  2.7uS)
crypt         per sec =     12788.55 ( 78.2uS)

EGCS 971008 -O3 -mcpu=ultrasparc

set_key       per sec =    231505.91 (  4.3uS)
DES ecb bytes per sec =   3043186.47 (  2.6uS)
DES cbc bytes per sec =   3118386.32 (  2.6uS)
crypt         per sec =     12224.42 ( 81.8uS)

GCC 2.7.2.1 -O3 -msupersparc

set_key       per sec =    245225.03 (  4.1uS)
DES ecb bytes per sec =   3212060.54 (  2.5uS)
DES cbc bytes per sec =   3218404.89 (  2.5uS)
crypt         per sec =     13785.99 ( 72.5uS)

Quick analysis with quantify revealed that egcs spends more time
when doing shifting, or'ing, and'ing etc.  I guess something must
be broken in the optimizer.

Teemu

Re: EGCS-971016: i686 Linux vs. SparcULTRA Solaris

[Wolfram Gloger]

> Solaris2.5  UltraSPARC 170  (192 MB RAM, 830 MB VIRTUAL):
>     TIME:   557.43s
>     SIZE:   190832K
> 
> Linux2.0    i686            (386 MB RAM, 1.04 GB VIRTUAL):
>     TIME:   359.37s
>     SIZE:   138012K
...
> This seems like a remarkable difference.  I find the allocation
> differences really suprising.

[sorry, getting slightly offtopic]

If what you are reporting as `SIZE' is the maximum memory footprint of
the application, then I am not that surprised.  The malloc in Linux
libc and glibc (by Doug Lea) is heavily optimized for memory savings
(while remaining quite fast as well).  I haven't seen a malloc version
that performs better in this respect; see

  http://www.dent.med.uni-muenchen.de/~wmglo/malloc-slides.html

for some comparisons (Solaris isn't yet covered in my tests but will
be soon).  You might want to use Doug Leas malloc on Solaris as well
and check whether your SIZE goes down...

Regards,
Wolfram.
-- 
`Surf the sea, not double-u three...'
wmglo@dent.med.uni-muenchen.de

Re: EGCS-971016: i686 Linux vs. SparcULTRA Solaris

[Fred Richardson]

Wolfram-

>>  If what you are reporting as `SIZE' is the maximum memory footprint of
>>  the application, then I am not that surprised.  The malloc in Linux
>>  libc and glibc (by Doug Lea) is heavily optimized for memory savings
>>  (while remaining quite fast as well).  I haven't seen a malloc version
>>  that performs better in this respect; see

Thanks for the tip!  Indeed this solves the allocation problem.  Here
are my new set of stats:

Solaris2.5  UltraSPARC 170  (192 MB RAM, 830 MB VIRTUAL):
     TIME:   547.24
     SIZE:   138224K

Linux2.0    i686            (386 MB RAM, 1.04 GB VIRTUAL):
    TIME:   359.37s
    SIZE:   138012K


Now memory allocation is about the same on both platforms (no real
suprise since the malloc package is now the same).  But the speed is 
still an issue.  I probably need some UltraSPARC changes to the
optimizer (does anyone know if there are any out there?).

            Thanks,

                -Fred