At Tue, 24 Jun 2003 11:32:17 -0400,
Matt Zimmerman wrote:
>
> On Tue, Jun 24, 2003 at 01:47:55PM +0900, GOTO Masanori wrote:
>
> > At 21 Jun 2003 00:27:18 +0200,
> > Mathieu Roy wrote:
> > > RedHat provide glibc for i386, i586 and i686. Why doesn't Debian
> > > provide several packages for i*86 when the package can be optimized a
> > > lot depending on the CPU type?
> >
> > We're planning. i686 optimized binary does not work on my machine, so
> > it's currently dropped. We need to check whether it's ok to upgrade
> > smoothly or not.
>
> There used to be libc6-686 and so on, but they caused a lot of problems with
> upgrades. Then they were re-enabled, then disabled again in the same
> release.
Yup. I investigate a good way to support them.
> I wasn't able to measure a significant performance increase with
> the optimized library anyway, so I haven't missed it.
Good point. I agree with your thought. Performance improvement is
_not_ my primary intention. At least it needs to support libc6-686:
- LinuxThreads floating stack support. It's ready for i686 and later.
- NPTL/TLS support. NPTL currently supports i486 and later because
pthread_spin_trylock uses cmpxchgl instruction (well, it's not
difficult to support i386, but imagine pthread on i386 with the
max clock (I recall it was 20MHz?) speed and memory...)
and so on.
BTW, I also think that 5% performance improvement with optimization is
valuable. It's not easy to accelerate 5% performance without any
source code modification and hardware improvement. In addition, it
reduces the user responce time, I think it's more important than
increasing throughput (= computational speed).
IMHO, the problem is the lack of real data which compares non-
optimized vs optimized binary performance on the actual environment.
I often heard the perfomance improvement issue using gcc optimization
like Gentoo, but I merely saw the real perfomance comparison graph.
So, supporting optimized library is not primary issue for at least
libc.
Regards,
-- gotom
