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 developer. 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