|
FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
How to optimize FreeBSD 7.0 ?
Hi,
While i was googling, i found this page. The optimizations described are said 'applyable' to FreeBSD 4 and 5. Can they be applied to a FreeBSD 7.0 ? I am interesting in optimizing the software compilation process. Where can i find an up to date guide to achieve this? How, once it is done, recompile all the already installed ports? Thanks |
|
|||
I suggest that you leave your CFLAGS alone. You just break things if you play with them. Default CFLAGS are quaranteed to work.
|
|
|||
Quote:
That's why I am asking. I guess that if these flags are there and modifiable it must be because they can be used and I'd like to know how. If somebody can help me.... |
|
|||
But that flags may interact very badly with some ports, so use them on your own risk.
|
|
|||
Quote:
Of course I have a sandbox to play with them. I would just like to have a more detailed guide than the make.conf itself. |
|
|||
Thanks, it seems that only setting the cpu is useful.
But how can I recompile all the already installed ports to take this change in account? |
|
||||
The performance gain will be marginal but looking after the problem if some port fails to compile will drives you crazy. Furthermore posting a PR with such 'optimizations' will not get you any response. This is in my opinion 'Gentooish behaviour'.
>But how can I recompile all the already installed ports to take this change in account? As you can see, there are more important thing to learn instead of tinkering with the stability and reliability of the system http://www.gsp.com/cgi-bin/man.cgi?s...ic=portupgrade
__________________
use UNIX or die :-) |
|
||||
The posts generally applicable.
My advice: Set CPUTYPE as harisman suggested, it makes sense to do so (for example I havn't used any thing but i685 and em64t chips in a long time, never seen an Intel 80386 either) Using SCHED_ULE might be worth while as Oliver_H posted. I've personally never had a problem with any of the schedulers I've built kernels off, but I don't run high load servers ! Do not mess with CFLAGS or CXXFLAGS unless you know what you are doing. Do not mess with CFLAGS unless you know what you are doing and are a C Programmer familiar with the available options to gcc. Do not not mess with CXXFLAGS unless you know what you are doing and are a C++ Programmer familiar with the available options to g++. Do not touch CFLAGS or CXXFLAGS for building world or kernel unless you are a FreeBSD hacker and know what you are doing. Always read the compiler documentation before setting CFLAGS/CXXFLAGS outside your own programs, and even then read it if you don't know what is happening. (Might seem rude but the above comments might make life easier in the long run.) The cross reference to optimizing kernel builds should be taken with a grain of salt as far as some parts go. Same for the kernel related options imho -> make sure of things before screwing around with non-important stuff, less headaches then hunt & pecking options. Locate bottlenecks before trying to optimize them. Quote:
Unless you hit a spot that can benefit from optimization, you probably shouldn't change things from defaults unless you know what your changing or are willing to play with it until you either break it, fix it, or perfect it. PS: I generally build my own programs with CFLAGS set to one of these values in my makefiles: Code:
# normal build CFLAGS= -Wall -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion \ -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes \ -Wmissing-declarations -Wredundant-decls -Winline -Wnested-externs\ -std=c99 -march=i686 # for debugging builds append to CFLAGS -ggdb # or -g3 # optimized builds with options added after clfags, used for testing for problems that may occur in the code when optimized OFLAGS= -fforce-mem -fforce-addr -finline-functions -fstrength-reduce \ -floop-optimize -O3
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
Quote:
Code:
CFLAGS=-O2 -pipe |
|
||||
here you have an example /etc/make.conf from one of my boxes:
http://toya.net.pl/~vermaden/text/make.conf you should also tweak /etc/src.conf for base system components tweaking: src.conf(5)
__________________
religions, worst damnation of mankind "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”. vermaden's: links resources deviantart spreadbsd |
|
|||
After messing with my CFLAGS on a test system, I am inclined to agree that leaving them alone is for the best. I used O3 optimizations and noticed the stability of the system fell as a consequence.
Also, messing with the CFLAGS often prevents a successful buildworld. The only optimizations I now do, is to set the CPUTYPE. I remove unnecessary modules from the kernel, and use the ULE scheduler. |
|
|||
None of you should be messing with the CFLAGS, unless you have the slightest idea what the options do, leave them alone.. you're more likely to break something then improve performance any.
|
|
||||
vermaden is a smart ex-Gentoo user who's settled on a great operating system in its place. I'm sure he knows this too. I ditched Gentoo for Debian. I was running FreeBSD, which I like even more, but no official support from ATi and no KDE 4, I think I'll wait to migrate.
|
|
|