[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why you are wrong [Was: On linux kernel packaging issue]

On Mon, 2003-11-10 at 15:46, Glenn McGrath wrote:
> A program that is CPU bound will benefit from compiler optimisations.

A program that is CPU-bound *and* can be encoded more efficiently will
benefit from compiler optimizations. Some CPU bound things just aren't
going to be helped much by vectorization, instruction reordering, etc. I
mean, integer multiply is integer multiply.

> I am not going to individually check every debian package just to give
> you "evidence" and some sort of blanket statment covering all released
> packages at a particualr instant in time.

You don't need to check every Debian package; like you said yourself,
nothing that isn't CPU-bound is going to get helped at all. That cuts
out a whole lot of programs. Especially since this discussion involves
the Linux kernel, you only need to make your point for one program --
the Linux kernel.

> You comments on compiler bugs are irrelevent, it is not debians role to
> try and predict future compiler bugs, just to work around previous ones.

This sounds like the talk of someone who never got bit by a compiler
bug... I had a hell of a time when a number of Gentoo users compiled
broken glibc at one point (some combination of -O3 and i686); the only
thing that consistently failed on their systems was a piece of software
I wrote (and the minimal test cases I put together after being
completely confused for a few weeks).

Debugging compiler problems is *not fun*. They are incredibly difficult
to trace (pydance crashed generating arrow events, due to problems with
Python's floating point processing, due to problems with glibc that only
occurred on a handful of systems -- how quickly could you have figured
that out?) from the perspective of an application developer. They can be
incredibly difficult to fix from the perspective of a compiler

As for trying to predict future bugs, Debian does this all the time.
That's why we have things like the testing distribution. We know that
essentially all software has mistakes; we should try and mitigate the
damage from those mistakes as much as possible.

> Other than exposing bugs (which is a good thing) compiler optimisations
> do no harm.

Unless it rearranges the instructions so that they run slower through
common pipelines, e.g. optimizing for i586 seems to do this on Athlons
and P4s. Optimizations happen in both new instructions *and* new
instruction ordering; the former is usually upwards-compatible, but the
latter is not.
Joe Wreschnig <piman@debian.org>

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: