Re: Pgcc in Deb
> You've missed the point, which is this: my machine very seldom maxes out
> its cpu. Most of the time that I spend waiting for something to happen
> is due to the time required to read something from memory or disk. The
> fact that there are other processes sitting idle *is not relevant*--I'm
> only waiting for one process (say it's X or the cp command) and that
> process is only waiting on one thing. If the majority of my applications
> spend (imaginary numbers) 5% of their time processing, 30% of their time
> waiting on io, and 65% of their time waiting on me, then making the apps
> cut their cpu time by 3% (to 4.9% of total run time) isn't significant.
I don't think it's that hard to max out your CPU. The thing is you'll
notice the difference only when your CPU is maxed out. That's when I
think [Is this thing compiled with all optimization flags on?]
> Certain cpu-bound workloads would benefit from optimizations; a
> highly-tuned BLAS library, for example, is tremendously useful for
> scientific applications. But this caveat does *not* apply to the vast
> majority of debian packages. The and implications of "an optimized set
> of computational libraries for debian" are different from those of "a
> debian distribution compiled with processor-specific optimizations."
Well, then there's an alternative task that could be done: Making sure
that all computationally intensive apps compiled with -mcpu=686, since
anyone using those things will have an 686!!
> Finally, the idea that supporting a half-dozen differently-optimized
> versions of every package will result in *more* stability is highly
> suspect IMO.
I was trying to stir up some irony in that :)
> > If I do benchmarks, would this be revisited?
> If you have benchmarks that show significant performance improvements on
> a typical workload using architecture-specific optimizations, I'm sure
> they'll be looked at.
Okay, so I'll take my chance in that.
> > Are you sure about the PentiumIII? I would think that it's backwards
> > compatible with PentiumII, and implementing the same optimization paths.
> The *instructions* are backward-compatible, AFAIK, but the optimal
> instruction ordering is not. (And ordering for maximum pipelining, more
> efficient cache usage, optimum memory access, etc., is the major factor
> in this sort of optimization, not the use of special instructions.)
So the compilers that tuned for 686 won't work as good on PIII, right?
That means the gcc isn't up to date in that, but I always thought the
people worked closely with Intel.