# CPUTYPE is not working in make.conf



## mobilitysd (Jul 26, 2013)

Hello everybody!

I have a question about variable CPUTYPE in make.conf. I want to build kernel, world and all software with the following settings:


```
CPUTYPE?=core2

NO_CPU_CFLAGS=false
NO_CPU_COPTFLAGS=false

CFLAGS+= -msse3
CXXFLAGS+= -msse3

NO_PROFILE=true
```

I know that GCC which is used in FreeBSD is 4.2.1 and this is a very old version which doesn't support -mssse3, -msse4.2. But, I have noticed something that all software including kernel and world don't use -march=core2 only -msse3. What is the  problem? Should I use it to get the desired result?


```
CPUTYPE?=core2

NO_CPU_CFLAGS=true
NO_CPU_COPTFLAGS=true

CFLAGS+= -march=core2 -msse3
CXXFLAGS+= -march=core2 -msse3

NO_PROFILE=true
```

Then why we need to set CPUTYPE if it's useless?


----------



## DutchDaemon (Jul 26, 2013)

Don't set compiler flags at all in /etc/make.conf. You're asking for way too much trouble. Things will break.


----------



## mobilitysd (Jul 26, 2013)

But, how about optimization? How can I optimize my system for CPU? Which settings are the safest for it?


----------



## bkouhi (Jul 26, 2013)

It is not useless. Remove those CFLAGS as @DutchDaemon mentioned. The default value of CFLAGS is: -O2 -pipe. I have this line in my /etc/make.conf:


```
CPUTYPE?=       core2
```

So, my  CFLAGS is:


```
[CMD]% make -C /usr/src/ -V CFLAGS[/CMD]
-O2 -pipe -march=core2
[CMD]% make -C /usr/ports/ -V CFLAGS[/CMD]
-O2 -pipe -march=core2
```


----------



## DutchDaemon (Jul 26, 2013)

And that's all you'll ever need. Optimization is overrated. It breaks more than it can ever speed up. Why is why, if someone comes here with weird and inexplicable errors, the first question is: what have you added to /etc/make.conf? And usually, that is the only question that needs answering.


----------



## mobilitysd (Jul 26, 2013)

You are my hero - @bkouhi! Now, I know how to find out which options will be used. Now I can change them and see what I get eventually. Thanks a lot!


----------



## wblock@ (Jul 26, 2013)

Do not set the value of CFLAGS.  Some individual ports use faster values, but if the setting is overridden, can't do that.  Setting CPUTYPE is generally safe.


----------



## phoenix (Jul 27, 2013)

Setting a make variable to "false" is exactly the same add seeing it to "true". Most variables are not checked for their contents only checked that they exist/are set to something.

This 
	
	



```
NO_COPT_FLAGS=true
```
 is exactly the same as 
	
	



```
NO_COPT_FLAGS=false
```

If you don't want it set, then don't set it to anything.

IOW, set CPUTYPE and delete everything else.


----------



## Chris_H (Aug 1, 2013)

I had a l-o-o-n-g discussion on the stable list, a few years back. I _insisted_ on CPU profiling, because I was _sure_ it would make _all_ the difference. In the end, the _only_ things that could possibly benefit from it, were mostly third party applications -- OpenSSL, and crypto-based stuff. So in the end, you will likely defeat your intended goal. Because so much of src, and ports, have already made the proper adjustments for you, you ultimately end up undoing all/most of it.

Best wishes.

--chris


----------



## xibo (Aug 1, 2013)

If you're going to play with CPUTYPE, CFLAGS or LDFLAGS, be prepared to have a lot of work. It *is* possible, however it isn't easy - that's why you're being told not to do it.

With CPUTYPE set clang can generate like 5-10% faster code on the average, with some multimedia apps gaining considerably more while some other packages will end up becoming slower. IMO that is not worth it, since you'll likely be taking a lot of time setting things up - running test cases against _every_ C/C++ port, comparing timings with "unoptimized" versions, ...
... and redo it at every update. Sometimes ports strip CFLAGS or ignore CPUTYPE - you want to modify them not to? Even more work if you do so.

Notice that OpenSSL uses hand written (perl script generated in fact) assembly optimizations to use AVX - that's how they were able to support it long before compilers could reliably generate code to use it properly. Therefore it doesn't matter whether or not you build it for your system, since it will detect your CPU features and use them anyways.


----------



## kpa (Aug 1, 2013)

Let's put that 5-10% gains into perspective. Under typical usage of a desktop computer the CPU is idling most of the time because the applications are waiting for user input. So with that much improvement your computer is idling 5-10% more efficiently 

You won't see any difference in performance unless the application is doing constant work keeping the CPU busy for extended periods of time, let's say 15 seconds.


----------



## Chris_H (Aug 1, 2013)

kpa said:
			
		

> Let's put that 5-10% gains into perspective. Under typical usage of a desktop computer the CPU is idling most of the time because the applications are waiting for user input. So with that much improvement your computer is idling 5-10% more efficiently



LOL! Beautiful. Thanks! 

--chris


----------

