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/
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/
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/
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/