Speed tests - G4-400 and PIII-600

Speed tests - G4-400 and PIII-600

[Stephane GEORGES]

I've made speed tests on programs running on my LinuxPPC on G4-400 Mhz AGP,
and on Pentium III 600 Mhz.

Both machines have same disks performances (with hdparm, about 20 Mo/s).

GCC versions:
    - on Intel : egcs-1.1.2-24
    - on PowerPC: egcs-1.1.2-12c

Bogomips:
    - on Intel : ~ 600
    - on PowerPC: ~ 800

The test programs are dealing with run-length images processing.

I was disapointed by the fact that the Intel machine ran 25% faster
than the PowerPC machine.

I thought that a G4-400 was worth a PIII-800 ...
Maybe gcc including Alvitec patches will provide better performances ...

--

/====================================================================/|
| Stephane GEORGES                     |                             ||
| DALiM SOFTWARE GmbH      R&D         |    Tel: +49 7851 9196 40    ||
| Strassburger Str.6                   |    Fax: +49 7851 7357 6     ||
| D-77696                              |                             ||
| Kehl-Sundheim (Germany)              |    E-mail: sg@dalim.de      ||
|____________________________________________________________________|/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

lidstdc++ string problems

[Patrik Jonsson]

Hi everyone,

I wonder if there is a known problem with the c++ string class? (I just
upgraded to gcc 2.95.2, but it didn't help.) What happens is that I read
into a string from a char* using a strstream as " strstream >> string".
This works on other machines, but on linuxppc the resulting string
contains junk at the end that is in another string object defined earlier.
It's like it doesn't properly define what the length is. If I look at it
in gdb, the "dat" field contains the right char*, but when reading it more
stuff appears at the end. It's HIGHLY annoying, it's plain impossible to
make anything work! Is this known / is there a fix or something? It seems
bad if we can't trust the standard library... :(

Any hints would be much appreciated,

	/Patrik


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lidstdc++ string problems

[Franz Sirl]

At 11:10 03.02.00 , Patrik Jonsson wrote:

>Hi everyone,
>
>I wonder if there is a known problem with the c++ string class? (I just
>upgraded to gcc 2.95.2, but it didn't help.) What happens is that I read
>into a string from a char* using a strstream as " strstream >> string".
>This works on other machines, but on linuxppc the resulting string
>contains junk at the end that is in another string object defined earlier.
>It's like it doesn't properly define what the length is. If I look at it
>in gdb, the "dat" field contains the right char*, but when reading it more
>stuff appears at the end. It's HIGHLY annoying, it's plain impossible to
>make anything work! Is this known / is there a fix or something? It seems
>bad if we can't trust the standard library... :(

Can you send me a small testcase that abort()'s if the bug is hit and does
exit(0) otherwise? Which gcc-2.95.2 RPM did you use? 1g? Which compiler
options? Does -W -Wall warn about anything?

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Speed tests - G4-400 and PIII-600

[Timothy A. Seufert]

At 9:34 AM +0100 2/3/00, Stephane GEORGES wrote:
>I've made speed tests on programs running on my LinuxPPC on G4-400 Mhz AGP,
>and on Pentium III 600 Mhz.

>Bogomips:
>     - on Intel : ~ 600
>     - on PowerPC: ~ 800

BogoMIPS is meaningless.  It is not a benchmark.

>The test programs are dealing with run-length images processing.
>
>I was disapointed by the fact that the Intel machine ran 25% faster
>than the PowerPC machine.
>
>I thought that a G4-400 was worth a PIII-800 ...

That's just marketing hype.

>Maybe gcc including Alvitec patches will provide better performances ...

Perhaps.  But you'd have to recode your software to use AltiVec; you
can't just recompile and get a speed boost.  And you'd have to do the
same with the PIII SSE vector instructions to make a fair comparison.
AltiVec is better overall than SSE, but how much better depends a lot
on the application.

Actually, I'd say that the G4 put in a pretty good show, considering
that the PIII's clock rate is 50% faster.  Last time I looked, the G4
and PIII have about the same SPECint95 rating at the same clock
speed, though the G4 is considerably better at SPECfp95.

Motorola's inability to ramp up G4 clock speeds is a big problem.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Speed tests - G4-400 and PIII-600

[jlquinn]

Bogomips is a totally meaningless measure of performance.  It is a measure
of how many empty loops can run in a given time period.  This value is used
to calibrate short timing intervals in the kernel.  So it is only useful
for comparing how fast a machine can do absolutely nothing.  Check out the
BogoMips mini-HOWTO.

If you seriously want to benchmark the two machines, you first have to
decide what you are benchmarking - disk performance, processor speed,
memory bandwith, network performance, kernel performance, etc.  There are a
number of benchmark programs out there that attempt to generate reasonably
comparable numbers (I'm sure I will miss many favorites): lmbench,
bytemark, gcc benchmark suite (for testing performance regressions in gcc),
STREAM, HINT, to name a few.

Also, compiler versions significantly affect the performance as well.
egcs-1.1.2 is out of date.  gcc-2.95 includes a number of optimizations not
present.  The current mainline gcc contains even more optimization work.

FInally, unless you are just looking for bragging rights, the best
benchmark you can use is the applications you intend to run on these
machines.  Everything else is just an approximation.

Jerry Quinn
jlquinn@us.ibm.com



Stephane GEORGES <sg@dalim.de>@lists.linuxppc.org on 02/03/2000 03:34:07 AM

Sent by:  owner-linuxppc-dev@lists.linuxppc.org


To:
cc:   linuxppc-dev@lists.linuxppc.org
Subject:  Speed tests - G4-400 and PIII-600




I've made speed tests on programs running on my LinuxPPC on G4-400 Mhz AGP,
and on Pentium III 600 Mhz.

[snip]

Bogomips:
    - on Intel : ~ 600
    - on PowerPC: ~ 800

The test programs are dealing with run-length images processing.

I was disapointed by the fact that the Intel machine ran 25% faster
than the PowerPC machine.

I thought that a G4-400 was worth a PIII-800 ...
Maybe gcc including Alvitec patches will provide better performances ...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Speed tests - G4-400 and PIII-600

[jlquinn]

I realized after sending off my reply that I hadn't bothered to read your
email completely before responding.  For starters, you should try
rebuilding your test program with gcc-2.95.2 or perhaps with a recent
snapshot of the development branch of gcc.  This will at least get you the
latest compiler optimizations available.

How intensive is the computation on the image?  If you are running through
a large image with short computations at each pixel, you may be limited by
memory bandwidth.  Both of those machines have 100Mhz busses, right?  In
this case, you'd be roughly even at the start from a raw hardware viewpoint
and then the fact that x86 tends to receive more optimization work in the
compiler might push it into the lead.

Jerry Quinn
jlquinn@us.ibm.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Speed tests - G4-400 and PIII-600

[Benjamin Herrenschmidt]

On Thu, Feb 3, 2000,  <jlquinn@us.ibm.com> wrote:


>How intensive is the computation on the image?  If you are running through
>a large image with short computations at each pixel, you may be limited by
>memory bandwidth.  Both of those machines have 100Mhz busses, right?  In
>this case, you'd be roughly even at the start from a raw hardware viewpoint
>and then the fact that x86 tends to receive more optimization work in the
>compiler might push it into the lead.

Something else that can affect performances on PowerPC when doing large
quantities of data manipulations is the way datas are fetched/stored in
memory. I think Intel processors do a good job with byte and short
accesses while the PPC loves when everything is naturally aligned and all
accesses are done in 32 bits quantities. A bunch of pixel manipulation
code I've seen in the past few years tends to use byte access to the
pixel datas in memory. This can be very inefficient.

Unfortunately, most of the existing code is written by programmers that
either don't care or optimize for their x86 box...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/