On Tue, 2002-10-15 at 02:42, Florin Andrei wrote: > On Mon, 2002-10-14 at 15:08, Jean Francois Martinez wrote: > > > > Also since not all back ends are of equal quality at times "optimizing" > > for the processor brings a slowdown: the K6 will run faster on code who > > is compiled with -mcpu=i686 than with -march=k6 and that is valid both > > for gcc 2.96 and 3.2. > > > > Benchmark first and draw conclusions later: for instance you could > > assume that code optimized for Pentium will run faster than code for > > 386 when CPU is a 686. Wrong. > > In a nutshell, you're saying that gcc sucks. > Don't get me wrong, i don't say you're not right. But one would expect a > compiler to do "the right thing". Seems like gcc doesn't. > Oh no. I am telling that the backend for K6 sucks. Since the K6 was never very popular there was never much interest in making a good code generator for it. I don't think this applies to the Athlon (who is far more popular than the K6 was) but there is still a non-zero probability that the code generator for PIII has had so much more work on it than the one for K7 that its code could run faster on the K7 despite not targetting it specifically. I am telling that a newer processor will not necessarily run faster on code optimized for a slightly older processor (eg Athlon versus PIII, PIII versus Pentium) than on code optimized for 386. The crucial factor is not the new instructions but timetables and pipelining. That is why Pentium code is so slow on the PII/PIII family: the ideal mix of simple and complex instructions who will make the Pentium happy is guaranteed to keep one of the three decoding units of the PII/PIII starved most of the time because that unit can only decode simple instructions and the next one is a complex one. And if you think about it the more ideal is the mix for the Pentium, the worse it will be for processors whose ideal mix is different. For the same reason you should not believe without checking that what is good for PIII is good for the Athlon. JFM _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
