Learning about Control of Optimization -- for dummies please

[Johan Hendriks]

>>      On Wed, 5 Aug 2009 12:19:23 +0200 Roland Smith
<rsmith at xs4all.nl> 
wrote:
>> >On Wed, Aug 05, 2009 at 10:54:07AM +0100, David Southwell wrote:
>> >> I have found
>> >> http://docs.freebsd.org/info/gcc/gcc.info.Optimize_Options.html.
>> >>
>> >> I am about to build a new kernel am starting to dig a bit deeper
into
>> >> things I have, until now, taken for granted.
>> >>
>> >> The above link is very informative in technical terms about how to
>> >> control optimization but I find it difficult to interpret the info
in a
>> >> way that tells me what might work best on my own system (Intel
quad
>> >> Core) with 8G of ram.
>> >
>> >The build system takes care of that, once you have set the correct
>> >CPUTYPE in /etc/make.conf. For a quad-core, set CPUTYPE=nocona. See
>> >make.conf(5), /usr/src/share/mk/bsd.cpu.mk and
>> >/usr/src/sys/conf/kern.pre.mk.
>>
>>      As I read the man page for [g]cc, though, setting -march=nocona
(which
>> is where the CPUTYPE information ends up in the cc commands) tells
the
>> compiler which base instruction set to use and which model of
instruction
>> scheduling to use, but to get the rest of the model-dependent
features
>> used, he would still need to add "-mmmx -msse -msse2 -msse3" at a
minimum
>> for most other compilations, though these would not be advisable for
kernel
>> compilations.  I don't recall whether SSE4 instructions are in the
Nocona/
>> Merom/Kentfield chips or first appear in the Core i7 series.  I don't
think
>> the compiler versions available under FreeBSD support the SSE4
>> instructions, though, so SSE4 doesn't matter anyway.
>>
>> >Additionally, compiler settings for building the kernel can be set
with
>> >COPTFLAGS in /etc/make.conf. Using anything other than -O or -O2 is
>> >not guaranteed to work. If you don't know what you are doing, do not
use
>> >COPTFLAGS and stick with the defaults that the build system
generates.
>>
>>      Right.  -O3 might royally screw a kernel in particular. :-)
>>
>>
>>                                   Scott Bennett, Comm. ASMELG, CFIAG
>Thanks for add more useful info however would you mind elaborating a
little 
>more because I do not understand the implications.

>should I have:
>CPUTYPE=nocona 
>in make.conf?
>Do I need anything else in make.conf?

>So far my draft make.conf has these entries:

>CPUTYPE=nocona

>CFLAGS= -O2 -fno-strict-aliasing -pipe

>FORCE_MAKE_JOBS=        true

>Incidentally I am also puzzled because it appears necessary to use
amd64 
>GENERIC as my starting point when the cpu is actually Intel Quad Core!!


>I presume this means that in drafting a kernconf I need to refer to;

>dns1# pwd
>/usr/src/sys/amd64/conf
>dns1# ls -l
>total 44
>-rw-r--r--  1 root  wheel     13 Jun 20  2005 .cvsignore
>-rw-r--r--  1 root  wheel    482 Apr 15 04:14 DEFAULTS
>-rw-r--r--  1 root  wheel  11968 Apr 15 04:14 GENERIC
>-rw-r--r--  1 root  wheel    818 Apr 15 04:14 GENERIC.hints
>-rw-r--r--  1 root  wheel   1036 Apr 15 04:14 MAC
>-rw-r--r--  1 root  wheel    132 Apr 15 04:14 Makefile
>-rw-r--r--  1 root  wheel  20721 Apr 15 04:14 NOTES


>It would be great if some logical consistency could be introduced into
naming 
>conventions!!! It would really help those of us who know little and
make it a 
>trifle easier to climb the greasy pole of knowledge <chuckles>

It is logical.
You use i386 on old amd processors also.
The naming amd64 comes from the fact that AMD did come first with the 64
bit processor.
If Intel was the first it proberly would have a name like i386_64 or
something like that.

Nothing to worry about.
If your Intel proccessor has 64 bit support use the AMD64 version

It is just a name.

About the make.conf the use of nocona is ok but put a ? mark ofter
CPUTYPE
Do not ask me why, people told me it is better, if i understand
correctly It has someting to do about the choice the compiler has while
building, it could override the nocona setting if it is needed.
If i recall correct!!!!

CPUTYPE?=nocona

I would ditch the CFLAGS, the normal setings ar the same as that line 

FORCE_MAKE_JOBS=        true

FORCE_MAKE_JOBS is also ok



 

 



No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.44/2282 - Release Date:
08/04/09 18:01:00