Compilation optimization settings for Atom N270 and general advice?

A

Agent_K64

Hello! I'm new to FreeBSD; I've decided to install it on my netbook to try it out. I've done a bit of reading about how one can compile software from ports, specifically for their system's architecture, for better performance. I figured it would be interesting to do for a relatively underpowered machine like an Atom N270 powered netbook. But I've also read about how compiler optimizations can break software, so I'm a bit scared of introducing a whole new layer of complexity--bugs--to deal with as I learn a new OS, making things a lot more difficult. :(

So, I'd like to hear some opinions on what reasonably safe optimization settings are. I have edited my /etc/make.conf to:

Code: 
.if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc46)
CC=gcc46
CXX=g++46
CPP=cpp46
CPUTYPE?=atom
CFLAGS= -march=atom -O2 -fno-strict-aliasing -pipe
.endif

I did install gcc46 from the port, as it supports the Atom CPU optimizations, while FreeBSD's default gcc version does not. I also followed Configuring ports for custom version of GCC

Is that reasonable? Should I stick with "-O", instead? Is "-fno-strict-aliasing" recommended? Which flags does "CPUTYPE?=atom" and "-march=atom" trigger, anyway? Do they automatically enable SSSE3, since the Atom supports it?

Also, is there a way to confirm that the software I compile is in fact using Atom optimizations (to check that I enabled it properly in the settings)?
 
Touching CFLAGS is never recommended. As for -march=<cpu-type>, using CPUTYPE?=native is enough. It adds -march=native to CFLAGS which makes GCC select the best architecture option for the host processor. You can query GCC what -march=native implies
$ gcc46 -Q --help=target -march=native
$ gcc46 -E -dM -</dev/null -march=native
$ gcc46 -v -E -dM -</dev/null 2>&1 -march=native | fgrep cc1
FYI, -march=native is a superset of -march=<cpu-type> when you're compiling on same machine you're going to run binaries.
 
Not sticking to the base system compilers when using the ports system will involve serious hurt. Loads of ports won't compile, or will fail in unexpected ways if they compile at all. Moreover, you will not receive any support here unless you rebuild those ports with the base system compilers first. And, as suggested in many a topic filled with frustrated hobbyists here: leave CFLAGS alone.
 
dandelion: Thanks! Those commands are pretty cool. The main difference that I notice is the lack of SSSE3 in FreeBSD's gcc, and it recognizes the architecture as 'nocona'. gcc46 actually recognizes the CPU as an Atom, and enables SSSE3.

DutchDaemon: Yeah, I saw that thread and it is exactly the type of thing I was worried about. However, I may be wrong, but I'm getting the impression that it's not gcc45 itself that's to blame for the failures listed there, but the new -flto optimization option which it supports. I assume it's not enabled by default in gcc46? If so, then it should not prove much to be an issue?
 
You need to think about where using better-optimized compilation (in this case -msse3 & friends) is actually going to help: devel/gettext, probably not. multimedia/mplayer, probably lots. The odd breakage of mplayer would be a minor hassle (comment out some lines in /etc/make.conf & recompile), gettext breaking in some subtle way could b0rk dozens of things.

I don't have a good answer, but I'd say the shotgun approach is probably not the best way here.
 
Thanks for the replies. I guess I'll refrain from using gcc46 for some things, by commenting it out in the make.conf file. Would I also need to rename /etc/libmap.conf to prevent FreeBSD's gcc from using the mappings in it, which were intended for gcc46?

Speaking of libmap.conf...
&quot said:
libgcc_s.so.1 gcc44/libgcc_s.so.1
libgomp.so.1 gcc44/libgomp.so.1
libobjc.so.3 gcc44/libobjc.so.2
libssp.so.0 gcc44/libssp.so.0
libstdc++.so.6 gcc44/libstdc++.so.6
Click to expand...
What does the .so.number mean? Why does libobjc have different numbers, while the other libraries do not?
 
Ironically, I'm getting an error when trying to compile libgpg-error-1.10. :( I've commented out gcc64 from the make.conf, and renamed libmap.conf, but make still tries to use gcc46 to build libpgp-error anyway.. and failing. I've tried removing gcc46, but now it just complains about gcc46 missing. :( Could anyone tell me how to fix this?

PS. Sorry for the double post. It seems I'm now allowed to edit my posts. :x
 
As DutchDaemon said, NEVER play with compilers. It was my first problem when I started FreeBSD and I had everywhere compile errors! DucthDaemon remember :D
Use only system's default compiler. If you want to compile a source (example a program you wrote in C) with an other compiler different from the default you can do it with CC=gcc46 for example. But everything that exist on ports is better to be compiled with the default compiler to avoid serious problems!
 
sk8harddiefast said:
As DutchDaemon said, NEVER play with compilers.
Click to expand...

Well, that's probably putting it too strongly. I'd add a trailing clause, "unless you really know what you are doing and agree not to blame anyone else for any messes you make."

Then, because some people don't really know what they think they know, I'd follow up with a stern, moralizing lecture about the virtue of humility and the need for an accurate perception of our personal capabilities and limitations.

But maybe you and DutchDaemon are right. It's easier to just say NEVER.

;)
 
Well. I agree with you, but at least me, I said NEVER just because I believe that to play with compiler is very very big mistake! Is not just a port and play with a flag. If you make experiments with compiler and compiler stop work right, then you have serious problem. NEVER is just to give the exact danger that could cause this. I am not an expert on FreeBSD but I made this mistake and I show a "system mess". So If I could say my opinion, this would be NEVER play with compiler and not "unless you really know what you are doing". I believe is safer :D
 
Looks like libgpg-error doesn't like gcc46, even though I've set no flags other than the CPUTYPE. I was hoping that just using a newer compiler version would mean it's better and less buggy.. and more importantly, it would support my CPU. But I guess not! :( I'm also guessing that attempting to compile the rest of Xorg with gcc46 isn't a very wise idea. :S It successfully compiled on FreeBSD's gcc after I ran # make clean, as suggested. Hooray!

That makes me wonder if leaving CPUTYPE?=native is a good idea? It selects the nocona architecture, but I've got a different chip. It would be a shame if things broke or got un-optimized as a result of this. Does anyone know anything about this?

Thanks for all the input.
 
You must log in or register to reply here.
Back
Top