[If, after reading this mail, you continue to make the same invalid assertions and broken arguments, then you should not be surprised when people write you off as a troll]. On Mon, Nov 10, 2003 at 09:01:01AM +1100, Glenn McGrath wrote: > On Mon, 10 Nov 2003 01:32:44 +0800 > Cameron Patrick <cameron@patrick.wattle.id.au> wrote: > > > Well, Glenn didn't really put many words around his output from timing > > bzip2, so any claims about what he was trying to prove are > > speculative. > > The point i was trying to make is that architecture specific > optimisations do make programs run faster. You failed. Your experiment was flawed, as has been described in great detail in this thread. Also, your experiment couldn't have proven this even if it were correct. All it could have shown is that one particular set of optimisations worked better than another for one particular program. Now, if you were to assert that "architecture specific optimisations can make *some* program run faster", then I doubt you would have any trouble getting people to agree with you. However, this assertion does not lead to the conclusion "we should use these particular architecture specific optimisations for all programs" - instead, it leads to the question which is asked every time this comes up: "Does this particular set of architecture specific optimisations make this program run faster?" And which is almost invariably not answered. On the rare occasions when there is a valid answer, and it's "yes", then we find a way to make it happen (eg, libssl). > There is no point taking discussions any further if people refuse to > accept that very basic and simple principle on face value. We refuse to accept it blindly because it's wrong. There have been cases when architecture-specific optimisations have made programs run slower (recently the instruction ordering for that via i686 chip comes to mind); GCC gets it wrong from time to time, and there's no reason to think it's currently right (since everybody who asserts it is has failed to provide anything but circumstancial evidence, and we all know that software sucks). Sometimes it even causes programs to stop functioning entirely (athlon and p4, gcc 3.0.0 until sometime in 3.1.x). There are also an unknown number of cases where the optimum object code for i386 is the same as the optimum object code for i686 (it is trivial to empirically prove these exist [hello world]; it is very hard to know how many there are). There's certainly no evidence to support your assertion that it always makes programs run faster, and considerable *empirical proof* that it's wrong (disproving statements like "Y is true for all X" is easy; proving them is hard). So don't whine about people "refusing to accept" it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature