Re: Pgcc in Deb
On Mon, Apr 03, 2000 at 10:01:45PM +0300, you wrote:
> Michael Stone wrote:
> > No, the problem is that your pentium optimizations haven't been shown to
> > have a noticable impact in anything but fringe cases for people using
> > debian. (I.e., disk or network waits are so much larger than cpu waits
> > that optimizing cpu doesn't make a significant difference.) If you do
> > benchmarks that disprove this, it might be revisted. (But be aware that
> > many people have already tried this and were not impressed with the
> > results.)
>
> When I took an OS course, we were asked to write a round-robin scheduler that
> simulates processes with I/O blocking. It wasn't fun, but what I remember
> from that experience is that it will make a difference when you are running
> a lot of processes. That's the whole point of a good scheduling algorithm
> right? Keeping the CPU loaded, fairness, etc. Normally, your CPU shouldn't
> be doing any idle loops except in the case of badly written programs, and
> doing spin-locks for multi-threading. In that case, if I were to think that
> my computer is waiting for I/O all the time, I could also fancy turning down
> all the optimizations would be a good idea to introduce more stability in
> my system. That is, it seems to me too conservative to favor an argument
> that talks about I/O waits when there are so many apps running on a typical
> desktop.
>
> orion:gcc-2.95.2$ ps aux | wc -l
> 91
>
> Do you see my point?
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.
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."
Finally, the idea that supporting a half-dozen differently-optimized
versions of every package will result in *more* stability is highly
suspect IMO.
[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.
> I'm eager to burn my cluster for a pentium-pro optimized Debian. I
> used to optimize every single piece of code when I wrote assembly, and
> I feel irritated when I think of the possible optimizations on my
> system.
Is this about real, significant performance issues, or is this about
scratching a "possible optimizations" itch?
[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.)
--
Mike Stone
Reply to: