5.x, 6.x and CPUTYPE

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

5.x, 6.x and CPUTYPE

Joel Hatton-2
Hi,

I've noticed that some CPU definitions have changed in /etc/make.conf
between 5 and 6. For good or for bad, I have up until now been building
5.x for both p3 and p4 architectures with 'i686' but this particular
definition's removal from 6.x has given me cause to rethink my strategy.
I'd like to know:

Should I use 'i386' and build once for all, or use p3/p4 defs and build
once for each? And if the latter, why? (does this give any worthwhile
performance increase?)

If I don't specify a CPUTYPE at all, will this be auto-detected in some
way (which would probably not suit me) or will it fall back to i386?

Is this a consistent requirement for world/kernel/ports?

Finally, when building on a single host, but where multiple requirements
are being met, is it possible to define different make.conf files for make
or is it easier to just edit this file before each build?

thanks,
joel

-- Joel Hatton --
Security Analyst                    | Hotline: +61 7 3365 4417
AusCERT - Australia's national CERT | Fax:     +61 7 3365 7031
The University of Queensland        | WWW:     www.auscert.org.au
Qld 4072 Australia                  | Email:   [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Craig Boston-4
On Mon, Nov 07, 2005 at 04:21:56PM +1000, Joel Hatton wrote:
> I've noticed that some CPU definitions have changed in /etc/make.conf
> between 5 and 6. For good or for bad, I have up until now been building
> 5.x for both p3 and p4 architectures with 'i686' but this particular
> definition's removal from 6.x has given me cause to rethink my strategy.
> I'd like to know:

Joel, thanks for pointing this out, I hadn't noticed this until I saw
your message.

I always build my production servers with CPUTYPE=i686 so they can be
transplanted to any machine with a PPro or better processor (or even
qemu if necessary).

Looking at bsd.cpu.mk, it appears that i686 *IS* still accepted (for 5.x
compat?) and is just aliased to CPUTYPE=pentiumpro.

Craig
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Derek Kulinski-2
In reply to this post by Joel Hatton-2
Hello Joel,

Sunday, November 6, 2005, 10:21:56 PM, you wrote:

> Hi,

> I've noticed that some CPU definitions have changed in /etc/make.conf
> between 5 and 6. For good or for bad, I have up until now been building
> 5.x for both p3 and p4 architectures with 'i686' but this particular
> definition's removal from 6.x has given me cause to rethink my strategy.
> I'd like to know:

> Should I use 'i386' and build once for all, or use p3/p4 defs and build
> once for each? And if the latter, why? (does this give any worthwhile
> performance increase?)

i386 will guarantee you that it should work on any PC, while p3/p4
will tell compiler to try using instructions available in pentium 3 or
pentium 4.
I don't have any performance stats to prove that, but in theory the
code should be faster when you use p3 or p4 instead of i386.

> If I don't specify a CPUTYPE at all, will this be auto-detected in some
> way (which would probably not suit me) or will it fall back to i386?

I'm afraid it will fall back to value that will produce code that can
run on any PC (which is i386). Actually it won't provide any flag to
gcc, but gcc will assume i386.

> Is this a consistent requirement for world/kernel/ports?

> Finally, when building on a single host, but where multiple requirements
> are being met, is it possible to define different make.conf files for make
> or is it easier to just edit this file before each build?

As long as you defined the variable in this way e.g.:
CPUTYPE?=i686
(the question mark is not a typo)

This is actually recommended way to assign values like this one.

You can pass this argument in make command e.g.
make buildworld CPUTYPE=i686
make buildworld CPUTYPE=p4
etc.

If you don't give argument, then whatever you have in /etc/make.conf
will be assumed as a default value.

--
Best regards,
 Derek                            mailto:[hidden email]
CCNA, SCSA, SCNA, LPIC, MCP certified
http://www.takeda.tk

Profanity is the language all programmers know best.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Scot Hetzel
In reply to this post by Joel Hatton-2
On 11/7/05, Joel Hatton <[hidden email]> wrote:
> Finally, when building on a single host, but where multiple requirements
> are being met, is it possible to define different make.conf files for make
> or is it easier to just edit this file before each build?
>
That is what I do when I build 5.x, 6.x, and 7-CURRENT on the same
server by creating multiple make.conf files.

You just need to define the _MAKE_CONF variable for the appropriate OS
that you are building:

make _MAKE_CONF=/etc/make.conf.6x [build|install]world

make _MAKE_CONF=/etc/make.conf.6x [build|install]kernel

If your installing the build on another host, you just have to make
sure that the /etc/make.conf.* on the build server matches the
/etc/make.conf on the target system.

Scot
--
DISCLAIMER:
No electrons were mamed while sending this message. Only slightly bruised.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Joel Hatton-2
In reply to this post by Craig Boston-4

>
> I always build my production servers with CPUTYPE=i686 so they can be
> transplanted to any machine with a PPro or better processor (or even
> qemu if necessary).

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?

cheers,
joel

-- Joel Hatton --
Security Analyst                    | Hotline: +61 7 3365 4417
AusCERT - Australia's national CERT | Fax:     +61 7 3365 7031
The University of Queensland        | WWW:     www.auscert.org.au
Qld 4072 Australia                  | Email:   [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Stephen Hurd
>
>>
>> I always build my production servers with CPUTYPE=i686 so they can be
>> transplanted to any machine with a PPro or better processor (or even
>> qemu if necessary).
>
> 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?

For packages, it's a good idea to make a build jail... in case of static
linking goodness.
I had packages bite me when I was building them all on a system with a
CPUTYPE=p3 world.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Craig Boston-4
In reply to this post by Joel Hatton-2
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.

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.

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.

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.

Craig
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Chuck Swiger-2
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".

--
-Chuck

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Andrew Pantyukhin-2
On 11/8/05, Chuck Swiger <[hidden email]> wrote:

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

Remeber that MacOSX/i386 requires the latest SSE feature
set? Well, some day, although in a much more justified way,
that might happen to FreeBSD. I don't think it'll happen earlier
than 5-10 years from now, but it will. It doesn't mean you'll
have to put something in your configs - just that the default
target will include optimizations for some instructions.

I still don't understand many of this gcc scheduling stuff, but
-mfpmath=sse should give a noticable boost to all code,
not matter when it was written. Also, things like OpenSSH
and mplayer were manually optimized to benefit from MMX,
MMX2, 3DNow, 3DNowEx, SSE, SSE2... (that's what
mplayer says about my athlon64 cpu, it was compiled
without runtime cpu detection).

So that's a matter of taste. It's not in vain to have a dozen
scheduling configurations for a medium site, but it could
live without that. Personally, I think, if there's a way to
automate everything nicely, then one should do it. Package
building is another issue, but I think FreeBSD will gain a
good world-wide distributed compilation network, where
you can get a binary with some specific options and
optimizations, - in the months to come. Let's hope for that.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 5.x, 6.x and CPUTYPE

Brandon Fosdick
In reply to this post by Scot Hetzel
Scot Hetzel wrote:
> You just need to define the _MAKE_CONF variable for the appropriate OS
> that you are building:
>
> make _MAKE_CONF=/etc/make.conf.6x [build|install]world
>
> make _MAKE_CONF=/etc/make.conf.6x [build|install]kernel

I spent a bit of time today trying to figure out why the above doesn't work. Eventually it occured to me to grep /usr/src to see if the variable even existed. It turns out it doesn't, however __MAKE_CONF does exist (that's with *two* leading underscores). Hopefully this will clear things up a bit in case anyone else is trying it.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"