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 :)
> [snip]
> > 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.
> [snip]
> > 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
gcc
people worked closely with Intel.
__
exa
Reply to: