CPUTYPE is not working in make.conf

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:

Code:
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?

Code:
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?
 
Don't set compiler flags at all in /etc/make.conf. You're asking for way too much trouble. Things will break.
 
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:

Code:
CPUTYPE?=       core2

So, my CFLAGS is:

Code:
[CMD]% make -C /usr/src/ -V CFLAGS[/CMD]
-O2 -pipe -march=core2
[CMD]% make -C /usr/ports/ -V CFLAGS[/CMD]
-O2 -pipe -march=core2
 
Last edited by a moderator:
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.
 
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!
 
Last edited by a moderator:
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.
 
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
Code:
NO_COPT_FLAGS=true
is exactly the same as
Code:
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.
 
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
 
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.
 
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 :P

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

LOL! Beautiful. Thanks! :)

--chris
 
Back
Top