Re: Pgcc in Deb

["Christopher W. Curtis" <ccurtis@aet-usa.com>]

Eray Ozkural wrote:
> 
> Josip Rodin wrote:
> > No arch/cpu-related optimizations are being set by default in most of the
> > packages. Perhaps there are a few exceptions, where the upstream settings
> > use optimization, or where the Debian maintainer has changed it, I don't
> > know.
> 
> I see. I'd like to stress that my original claim about 50% is perfectly
> valid, and I think that's sufficiently large to demand some action.
> It by no means implies that people with true i386's won't be able to
> run Debian, it just gives a turbo option to people with pentiums.

I don't think that is true (anymore?)  Some compilation options can
(should) take advantage of features (instructions) that the newer CPUs
support that the older ones don't.  NT, for instance, will not run on a
386 chip.  Not [simply] because it's far too slow, but because it uses
the XCHG (I think) instruction, which the 386 does not have.  There are
distinct benefits to compiling for a newer chip than a base-model.  I
personally would like to have a dist specific to my Athlon if there are
GCC optimizations for its pipeline and cache.

Now, the biggest complaint is obviously resource constraints.  Maybe
it's just not practical for every package to be compiled for a 386 and
for an Intel Pentium and an AMD Athlon and an Intel Pentium-III, etc.  I
wonder if package pools (are these being adopted for sure?) would help. 
>From my understanding, there will be many versions of packages saved,
not just stable and latest, and Packages.gz is updated to reflect links
to working versions.  If so, could this be further amended to include
optimizations?

Ie:

i386/Packages.gz -> i386/i386/Packages.gz
i386/i386/Packages.gz <- lowest common denominator
i386/i486/Packages.gz <- i486 optimized packages, with i386 packages
                         substituted for packages without i486 opts
i386/k6/Packages.gz   <- same as i486, for AMD K6[-[2|3]] chips
...etc.

?

This would be nice if possible (I assume that there is some sort of
automatic generation of Packages.gz with a package pool implementation)
assuming that the condition where 'xyz-1.1 exists in i486 and xyz-1.1.1
exists in i386 but not i486' can be resolved.

I'm not a developer and am not familiar with the process; if packages
are automatically compiled from source on each architecture after being
submitted to incoming then this isn't really an issue, but seeing that
the alpha often lags behind i386 in package versions it doesn't seem
that this happens.  But in light of this, I'll just read what others say
- I just would like to add that I think it's good to optimize for later
chips if possible ...

regards,
Christopher