Mail Archives: pgcc/1998/06/23/00:12:00
Thus spake Linux mailing list user (linux AT windows95 DOT sucks DOT eu DOT org):
> > I am not a subscriber to the mailing list but I used pgcc on my P75
> > with great satisfaction. Now I have a K6 233: does pgcc have switches
> > for this cpu? should I use pgcc or rather gcc instead?
> Yes to both.
> Use -mamdk6 -march=amdk6 for optimal performance, -mamdk6 without
> -march=amdk6 if you need to run the stuff on other systems, as well.
I'm not impressed.
$ pgcc -v
gcc version pgcc-2.91.42 19980621 (gcc2 ss-980502 experimental)
$ pgcc -mamdk6 -march=amdk6 -O6 -funroll-loops -fomit-frame-pointer -pipe -o bzip2-k6 bzip2.c
$ time ./bzip2-k6 -9 < bzip2.c > /dev/null
bzip2-k6: Caught a SIGSEGV or SIGBUS whilst compressing,
which probably indicates a bug in bzip2. Please
report it to me at: jseward AT acm DOT org
Input file = (stdin), output file = (stdout)
$ pgcc -mamdk6 -march=amdk6 -O6 -pipe -o bzip2-k6 bzip2.c
bzip2-k6: Caught a SIGSEGV or SIGBUS whilst compressing, [...]
$ pgcc -mamdk6 -march=amdk6 -O4 -pipe -o bzip2-k6 bzip2.c
$ time ./bzip2-k6 -9 < bzip2.c > /dev/null
0.50s user 0.03s system 50% cpu 1.050 total
$ time ./bzip2-k6 -9 < bzip2.c > /dev/null
0.51s user 0.01s system 71% cpu 0.731 total
$ time bzip2 -9 < bzip2.c > /dev/null
0.48s user 0.02s system 70% cpu 0.713 total
$ time bzip2 -9 < bzip2.c > /dev/null
0.48s user 0.02s system 63% cpu 0.792 total
$ pgcc -O4 -funroll-loops -fomit-frame-pointer -pipe -o bzip2-k6 bzip2.c
$ time bzip2 -9 < bzip2.c > /dev/null
bzip2-k6: Caught a SIGSEGV or SIGBUS whilst compressing, [...]
$
To summarize: only a scaled down version of the optimizations worked,
and those were slower than the original bzip2 compiled with vanilla
gcc-2.8.1 -funroll-loops -fomit-frame-pointer -O3.
I even tried pgcc with the same options I used for gcc-2.8.1. They
produce a core dump, too. It looks to me like the omit-frame-pointer is
at fault. When I remove it, I get a version that is slightly faster
than the 2.8.1 gcc, but not much.
0.46s user 0.03s system 173% cpu 0.282 total
0.45s user 0.03s system 104% cpu 0.459 total
[I always wonder what those >100% CPU numbers mean, but the user time is
usually right. I'm using uniprocessor Linux-2.1.106 on my K6-166 with
K6 bug]
That same version is slightly slower again when testing bz2 files.
This is against the Linux libc 5.4.44 source tree:
bzip2: 17.50s user 0.09s system 100% cpu 17.550 total
bzip2-k6: 18.92s user 0.11s system 100% cpu 18.993 total
I don't want to talk down on your work, but why should I care about pgcc
when the savings are dubious at best and the core dump probability is
increased? This reminds me of Linux/Alpha, where X will only work when
compiled with gcc-2.7.2.3 and the kernel will only work when compiled
with egcs, and gnu libc will not compile at all no matter which compiler
you use and when you finally beat it into submission it will produce
core dumps in the startup code when linked against, before even touching
main().
By the way: my impression is that egcs generally generates slower code
than older gccs on x86. Did anyone else get that impression, too?
Felix
- Raw text -