X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs- Message-ID: <19980623021139.A4049@math.fu-berlin.de> Date: Tue, 23 Jun 1998 02:11:39 +0200 From: Felix von Leitner To: beastium-list AT Desk DOT nl Subject: Re: Pgcc and K6 Mail-Followup-To: beastium-list AT Desk DOT nl References: <35839518 DOT 3E8627C AT wxs DOT nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.8i In-Reply-To: ; from Linux mailing list user on Fri, Jun 19, 1998 at 12:49:36PM +0200 Sender: Marc Lehmann Status: RO X-Status: A Content-Length: 3151 Lines: 69 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