Re: i586 debian port?
These numbers arn't worth much unless you also rebuilt libc6 to be pentium
optimized. There was a long thread on this this summer. I actually built all
of the base system and a few other programs pentium optimized and saw a
speeedup of at least 5% (20% is claimed).
Drake Diedrich wrote:
> On Sat, Jan 09, 1999 at 02:09:30PM +0000, Russell Coker wrote:
> >
> > There's probably not much need for a Pentium optimised version of "cp" or any
> > other similar programs which spend most of their time waiting for IO and aren't
> > run that much. For a Pentium optimised system you would only need different
> > versions of programs that matter, libc6, gzip, bzip2, povray (which are all
> > reasonably small), and maybe X servers (a significant amount of data).
> > Someone with a good knowledge of pgcc could probably produce a Pentium
> > optimised version of all these packages in an afternoon.
> >
>
> I did some tests recently comparing pgcc with egcc for some floating
> point intensive code (simple 100x100 matrix multiplies). On Pentium,
> Pentium II, and Pentium Pro egcc code was between 3% faster and 1% slower-
> within the typical deviation between runs. Sometimes gcc (2.7.2) was up
> there as well, though it was typically about 10% slower. Curiously, Pentium
> MMX did perform ~10% better under pgcc as compared to egcc, but only on the
> static matrix code. The dynamicly allocated matrix code was no faster.
> An AMD K6-2/300 performed comparably to the pentium 166 MMX (both SDRAM).
> Cyrix was not tested this time, but on previous tests it was comparable to a
> pentium at about half the clock rate. For floating point performance stick
> to Intel architectures, especially pII and PPro. pgcc with k6 flags did not
> perform as well as *any* of the other compilers (pgcc mppro, -mpentium,
> egcc, or gcc) on the AMD. The latest egcc with -O6 has the pgcc code
> scheduler built in. Architecture specific scheduling and op codes did not
> improve run times significantly on any architecture aside from the Pentium
> MMX.
> The example programs and libraries listed above are actually
> predominantly integer codes (even povray- it spends a lot of time wandering
> around linked lists compared to floating point ops). It's unlikely they'd
> improve even as much as the floating point code under a pgcc compile- though
> this should be tested. I think I did benchmark gzip once, but have
> misplaced the results. IIRC gzip was insensitive to the compiler and
> optimization flags- the C code has already been hand tuned.
> Strangely, the best time was on a Pentium II with pgcc -mk6
> optimizations. It was 1% better than egcc. Debian's BLAS routines are half
> as fast as naively coded matrix multiplies (I wanted to test the compilers,
> not the CPUs). ASCI-Red's hand-coded assembly BLAS is almost twice as fast
> as the code produced by our compilers, and 4 times as fast as our BLAS
> library. A slightly less naive matrix multiply (hand unrolling to improve
> cache hits) improved run times 25% on Intel. On an SGI this less naive code
> was several times faster than the naive code (RISC - lots of registers).
> The non-Intel architectures might show similar speedups.
>
> --
> Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302
> John Curtin School of Medical Research, Australian National University 0200
> Replies to other than Drake.Diedrich@anu.edu.au will be routed off-planet
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
see shy jo
Reply to: