[parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[Markus Grabert]

Jurriaan Kalkman wrote:


>>Are you aware of any other gcc/binutils bugs or should
>>gcc/binutils NOW create proper executables for pa2.0 and
>>pa1.1 (including the old CPUs like 730's PCX-S CPU) ?
>>
> 
> There are still bugs.


But Grand Grundler wrote:

| Yes - should work fine. Note one can build 32-bit PA2.0 binaries.
| The scheduling and insns are optimized for PA2.0 CPU but will
| run in "narrow" mode.

Mhh who's right ? I tend to believe Grand.

Of course there are bugs in binutils/gcc. But are there KNOW bugs/issues
a software developer (not a kernel freak) has to be aware of ?
What about glibc ?
Are threads fully supported ? Are gcc's ObjC, Java and C++ compilers
also working ?


>>I can imagine that the Linux/HPPA kernel is not very optimized yet
>>(can't compare the speed on my 730 with HP/UX since I don't
>>have the OS software anymore ...). Is the speed difference just a
>>few percent or can you 'feel' it (mhh, fuzzy question) ?
>>
>>
> I can only say that compiling a kernel on my C200 takes about 2 times
> as long as on my alpha (21164, 500 Mhz, 2 Mb cache). I feel it should
> be faster.


That's odd.
A 21164/500MHz (not 21164A or 21164PC) is slower according to
Spec_INT95, Spec_FP95 and the Spec_base(INT|FP)95 variants.

Indeed the benchmarks say that the Alpha is about 50% slower for FP stuff

and just a little bit slower for INT stuff (compared to a C240 HP/UX).

Moreover, according to SPEC:
If you compare it to a Intel CPU, the PA8200/236Mhz seem to be as fast as
a Pentium II 400-450 for integer operations and as fast as a
Pentium III 750-800 for floating point operations.

Well, lies, bigger lies/statistics and benchmarks.
Don't trust them.
Nevertheless a factor of 2 shouldn't occur. It's a too big number.
Is it just for compiling the kernel or for every application ?

greetings Max


> Good luck,
> Jurriaan

Re: [parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[John David Anglin]

> Of course there are bugs in binutils/gcc. But are there KNOW bugs/issues
> a software developer (not a kernel freak) has to be aware of ?

These are the main gcc issues that I am aware of:

1) 32-bit ABI -- 5-7 byte structures are not passed correctly per ABI.
2) I would say avoid "-O3" on mainline at the moment.  3.0.2 is better.
   The cause of the bug is unknown.

> What about glibc ?
> Are threads fully supported ? Are gcc's ObjC, Java and C++ compilers
> also working ?

ObjC builds and testsuite results are similar to i386.  Is anybody
actually using it?  I believe that the library is installed in the
wrong location.  There may still be issues with the testsuite using
the installed library rather than the build library.

Java: the library doesn't build.  Needs porting for both parisc-linux
and hpux, I believe.

C++: lack of weak symbol support causes some problems with template
instantiation under hpux.  Not sure how this is working under parisc-linux
but weak support should help.

Fortran: there are some bugs that need work on main.  Stick with 3.0.x
for now.

At least based on the testsuite results, C++ STL threads work under hpux.
Don't know of any issues under linux.  The primary problem is locking.

It would be useful if the gcc testsuite were run on various parisc-linux
linux configurations: 1.X and 2.0 processors, 32 and 64 bit, gcc mainline
and 3.0.2.  Then, post the results using the contrib/test-summary script to
gcc-testresults@gcc.gnu.org.  This would help a lot to determine the status
of things for gcc under parisc-linux.  Volunteer(s)?

I am planning to set up a 64-bit test system in the near future.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[Randolph Chung]

> It would be useful if the gcc testsuite were run on various parisc-linux
> linux configurations: 1.X and 2.0 processors, 32 and 64 bit, gcc mainline
> and 3.0.2.  Then, post the results using the contrib/test-summary script to
> gcc-testresults@gcc.gnu.org.  This would help a lot to determine the status
> of things for gcc under parisc-linux.  Volunteer(s)?

As part of building the Debian gcc packages the testsuite is run.
Currently there are about 290-odd failures (across gcc/g++/libstdc++). I
will look into posting the results.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[Grant Grundler]

Markus Grabert wrote:
> Jurriaan Kalkman wrote:
> > There are still bugs.
> 
> But Grand Grundler wrote:
> | Yes - should work fine. Note one can build 32-bit PA2.0 binaries.
> | The scheduling and insns are optimized for PA2.0 CPU but will
> | run in "narrow" mode.
> 
> Mhh who's right ? I tend to believe Grand.

I believe I was talking in general and without regard to the
issues we've recently had (and are *almost* fully resolved).
For the past week or two the apt-get'able toolchain has been
foobar.

> Of course there are bugs in binutils/gcc. But are there KNOW bugs/issues
> a software developer (not a kernel freak) has to be aware of ?
> What about glibc ?
> Are threads fully supported ? Are gcc's ObjC, Java and C++ compilers
> also working ?

Recently, bugs have been fixed in dynamic linking and C++ toolchain.
Just waiting for the fixes to propogate into the debian pkg pool
so we can all apt-get them.


> > I can only say that compiling a kernel on my C200 takes about 2 times
> > as long as on my alpha (21164, 500 Mhz, 2 Mb cache). I feel it should
> > be faster.
> 
> 
> That's odd.
> A 21164/500MHz (not 21164A or 21164PC) is slower according to
> Spec_INT95, Spec_FP95 and the Spec_base(INT|FP)95 variants.
> 
> Indeed the benchmarks say that the Alpha is about 50% slower for FP stuff
> and just a little bit slower for INT stuff (compared to a C240 HP/UX).

Those benchmarks are most likely based on hpux and hpux toolchain.

gcc is not as good at pipelining and other parisc specific
micro optimizations. C240 is PA8200 (iirc) and can execute
2 to 4 insn per cycle under optimal conditions.

grant

Re: [parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[Jurriaan on Alpha]

On Thu, Nov 15, 2001 at 02:08:46PM +0000, Markus Grabert wrote:
> Jurriaan Kalkman wrote:
> 
>> I can only say that compiling a kernel on my C200 takes about 2 times
>> as long as on my alpha (21164, 500 Mhz, 2 Mb cache). I feel it should
>> be faster.
> 
> That's odd.
> A 21164/500MHz (not 21164A or 21164PC) is slower according to
> Spec_INT95, Spec_FP95 and the Spec_base(INT|FP)95 variants.

Well, it actually is a 21164A I guess:

cpu model		: EV56
cpu variation		: 7
cpu revision		: 0
system type		: Miata
cycle frequency [Hz]	: 499784372 est.
timer frequency [Hz]	: 1024.00
page size [bytes]	: 8192
phys. address bits	: 40
max. addr. space #	: 127
BogoMIPS		: 988.76
kernel unaligned acc	: 1 (pc=fffffffc0040f064,va=fffffc8900008027)
user unaligned acc	: 0 (pc=0,va=0)
platform string		: Digital Personal WorkStation 500au
cpus detected		: 1

> 
> Indeed the benchmarks say that the Alpha is about 50% slower for FP stuff
> 
> and just a little bit slower for INT stuff (compared to a C240 HP/UX).
> 
> Moreover, according to SPEC:
> If you compare it to a Intel CPU, the PA8200/236Mhz seem to be as fast as
> a Pentium II 400-450 for integer operations and as fast as a
> Pentium III 750-800 for floating point operations.
> 
> Well, lies, bigger lies/statistics and benchmarks.
> Don't trust them.
> Nevertheless a factor of 2 shouldn't occur. It's a too big number.
> Is it just for compiling the kernel or for every application ?
> 
I'm most interested in the speed of compiling, since that what I do most :-)
Having just downloaded the angband-2.9.4-alpha.tar.gz file, I ran this
test in a fresh angband-2.9.4-alpha directory:

#!/bin/sh
# prep the cache
find . -type f -exec cat {} > /dev/null ';'
./configure > /dev/null
time sh -c "make > /dev/null"
make distclean > /dev/null

Both tests were run on systems with 512 Mb memory, the C200+ has a
Quantum UW-SCSI harddisk, the Alpha an IBM UW-SCSI harddisk, but Bonnie
shows them to be almost the same speed. I especially compiled and installed
gcc-3.0.2 20010924 on the Alpha to get as close as possible in compiler
versions, but the Alpha got even faster...

Alpha (gcc-2.95.4)        : real 5m45 user 5m13 system  9s
Alpha (gcc-3.0.2 20010924): real 4m36 user 4m12 system 10s
C200+ (gcc-3.0.2 20010922): real 8m23 user 7m48 system 33s
dual P3/700 (gcc-2.95.4)  : real 1m20 user 1m17 system  3s

and I'd like to note that I was reading mail, news and ssh'ing to the
C200+ from the alpha at the same time, the C200+ wasn't doing anything
else. Angband-2.9.4 is a set of c-sources of some 175000 lines.

The results are shocking; the C200+ is twice as slow, and uses 3 times as
much system time. The angband-2.9.4-alpha sources live at
ftp://clockwork.dementia.org/angband/Source/angband-2.9.4-alpha.tar.gz
if anyone feels like repeating this experiment.

Good luck,
Jurriaan
-- 
I expect Woman will be the last thing civilized by Man.
        George Meredith
GNU/Linux 2.4.15-pre4 on Debian/Alpha 64-bits 988 bogomips load:1.05 1.01 0.77

Re: [parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[Grant Grundler]

Jurriaan on Alpha wrote:
> The results are shocking; the C200+ is twice as slow, and uses 3 times as
> much system time.

I'm not surprised by the result.
1) We've done nearly zero tuning kernel.  Alpha port is much more mature.
2) gcc is poorly tuned for hppa as well.
   ie compare perf of gcc vs acc on HPUX. Up to 2x difference in some cases.
3) gcc is int intensive. Ie clock speed matters more and the alpha
   has 2.5x advantage here.

grant

Re: [parisc-linux] Linux/PA-RISC speed (was Re: C240 Graphics, 64bit kernel and more)

[Alan Cox]

> Alpha (gcc-2.95.4)        : real 5m45 user 5m13 system  9s
> Alpha (gcc-3.0.2 20010924): real 4m36 user 4m12 system 10s
> C200+ (gcc-3.0.2 20010922): real 8m23 user 7m48 system 33s
> dual P3/700 (gcc-2.95.4)  : real 1m20 user 1m17 system  3s

Be cautious. Unless you built cross compilers and each is building for
the same target you are doing different amounts of work for each target
CPU

Looking at the high system time I guess there is work to do on the hppa,
but it doesn't suprise me. It takes a lot of time to tune a port after it
actually works reliably