5.x, 6.x and CPUTYPE
cswiger at mac.com
Mon Nov 7 19:58:24 PST 2005
Craig Boston wrote:
> On Tue, Nov 08, 2005 at 12:05:13PM +1000, Joel Hatton wrote:
>> Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method.
>> Do you know of any particular disadvantages of continuing with this
>> less-than-optimised model - I guess I mean, is this something that is
>> likely to break or become uneconomical at some point?
> It won't break; after all the release binaries are targeted for 386 (or
> maybe 486 now) in order to be able to run on anything. You might need
> to update make.conf with the "pentiumpro" name just in case they ever
> drop the i686 alias, but that's about it.
Yes. Note that you should choose the lowest common denominator for the
hardware you possibly might want to run the binaries on. "pentium" or
"pentiumpro" are also good candidates in that they are well-tested targets
compared with the p4 or Althon targets.
> You might not get quite as good performance as if you compiled for
> exactly your CPU (keep in mind we're probably talking about 1-2% at most
> unless you have a VERY specific workload that SSE could benefit), but
> IMO it's more than worth it to be able to plug the hard drives into a
> similar machine and have things Just Work.
Agreed, although the performance difference depends a lot on the tasks being
done. Disabling the "cpu I386_CPU" statement in the kernel conf seems to be
more important than the difference between specifying a compiler architecture
or leaving it to the default.
> Personally, I pick i686 (pentiumpro) as a good middle ground. The
> features optimized for by that are present in every modern
> x86-architecture CPU: P2, P3, P4, Athlon, etc. So it's unlikely you'll
> run into something older than that. Also, the ppro has most of the
> features that really affect performance -- i.e. the gap between 386/486
> and 686 is a lot bigger than the gap between 686 and P3/P4.
Agreed. The gap in performance is 386/486 >> 486/586 > later models.
> P3s/P-M and Athlons especially are fairly smart and will optimize a lot
> of things at runtime. P4s are probably where you'll see the biggest
> performance hit -- that's where Intel tried to push a lot off it off on
> the compiler.
The P4 can benefit significantly sometimes from a compiler that knows how to
schedule for it and the underlying microcode which actually implements the x86
instructions, rather than just for a generic pentium, but most of the time
there isn't much difference between using "pentium" and "pentium4".
More information about the freebsd-stable