- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
CFLAGS and CXXFLAGS
The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although we define those generally here, you will only have maximum performance if you optimize these flags for each program separately. The reason for this is because every program is different.
In make.conf you should define the optimization flags you think will make your system the most responsive generally. Don't place experimental settings in this variable; too much optimization can make programs behave bad (crash, or even worse, malfunction).
We will not explain all possible optimization options. If you want to know them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.
A first setting is the -march= or -mtune= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments).
A second one is the -O flag (that is a capital O, not a zero), which specifies the gcc optimization class flag. Possible classes are s (for size-optimized), 0 (zero - for no optimizations), 1, 2 or even 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). -O2 is the recommended default. -O3 is known to cause problems when used system-wide, so we recommend that you stick to -O2.
Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation). It has no impact on the generated code, but uses more memory. On systems with low memory, gcc might get killed. In that case, do not use this flag.
Using -fomit-frame-pointer (which doesn't keep the frame pointer in a register for functions that don't need one) might have serious repercussions on the debugging of applications.
When you define the CFLAGS and CXXFLAGS, you should combine several optimization flags. The default values contained in the stage3 archive you unpacked should be good enough. The following example is just an example:
Code Listing 4.2: Defining the CFLAGS and CXXFLAGS variableCFLAGS="-march=k8 -O2 -pipe" # Intel EM64T users should use -march=core2# Use the same settings for both variablesCXXFLAGS="${CFLAGS}" ""
I am looking to fine tune a Gentoo Linux distribution and one of the installation procedures requires definining env. variable flags for GCC (C and C++) compiling of my kernel. I really want to optimize my i5 processor with this but can anyone perhaps suggests and specifics that may help me along the way. All I need are just some flags. As for my processor type exactly, it is:
Intel Core i5-2450M @ 2.50GHz
Below is text from the Gentoo handbook explaining exactly what I am looking for and what I need. The problem really is I do not know much about programming so I cannot seem to find the Intel pages or URL that I need but I know it exist. Thanks!
""As you probably noticed, themake.conf.examplefile is structured in a generic way: commented lines start with "#", other lines define variables using theVARIABLE="content"syntax. Themake.conffile uses the same syntax. Several of those variables are discussed next.
As you probably noticed, the make.conf.example file is structured in a generic way: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. The make.conf file uses the same syntax. Several of those variables are discussed next.
CFLAGS and CXXFLAGS
The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although we define those generally here, you will only have maximum performance if you optimize these flags for each program separately. The reason for this is because every program is different.
In make.conf you should define the optimization flags you think will make your system the most responsive generally. Don't place experimental settings in this variable; too much optimization can make programs behave bad (crash, or even worse, malfunction).
We will not explain all possible optimization options. If you want to know them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.
A first setting is the -march= or -mtune= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments).
A second one is the -O flag (that is a capital O, not a zero), which specifies the gcc optimization class flag. Possible classes are s (for size-optimized), 0 (zero - for no optimizations), 1, 2 or even 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). -O2 is the recommended default. -O3 is known to cause problems when used system-wide, so we recommend that you stick to -O2.
Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation). It has no impact on the generated code, but uses more memory. On systems with low memory, gcc might get killed. In that case, do not use this flag.
Using -fomit-frame-pointer (which doesn't keep the frame pointer in a register for functions that don't need one) might have serious repercussions on the debugging of applications.
When you define the CFLAGS and CXXFLAGS, you should combine several optimization flags. The default values contained in the stage3 archive you unpacked should be good enough. The following example is just an example:
Code Listing 4.2: Defining the CFLAGS and CXXFLAGS variable
CFLAGS="-march=k8 -O2 -pipe" # Intel EM64T users should use -march=core2
# Use the same settings for both variables
CXXFLAGS="${CFLAGS}"
As you probably noticed, the make.conf.example file is structured in a generic way: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. The make.conf file uses the same syntax. Several of those variables are discussed next.CFLAGS and CXXFLAGS
The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although we define those generally here, you will only have maximum performance if you optimize these flags for each program separately. The reason for this is because every program is different.
In make.conf you should define the optimization flags you think will make your system the most responsive generally. Don't place experimental settings in this variable; too much optimization can make programs behave bad (crash, or even worse, malfunction).
We will not explain all possible optimization options. If you want to know them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.
A first setting is the -march= or -mtune= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments).
A second one is the -O flag (that is a capital O, not a zero), which specifies the gcc optimization class flag. Possible classes are s (for size-optimized), 0 (zero - for no optimizations), 1, 2 or even 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). -O2 is the recommended default. -O3 is known to cause problems when used system-wide, so we recommend that you stick to -O2.
Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation). It has no impact on the generated code, but uses more memory. On systems with low memory, gcc might get killed. In that case, do not use this flag.
Using -fomit-frame-pointer (which doesn't keep the frame pointer in a register for functions that don't need one) might have serious repercussions on the debugging of applications.
When you define the CFLAGS and CXXFLAGS, you should combine several optimization flags. The default values contained in the stage3 archive you unpacked should be good enough. The following example is just an example:
Code Listing 4.2: Defining the CFLAGS and CXXFLAGS variableCFLAGS="-march=k8 -O2 -pipe" # Intel EM64T users should use -march=core2# Use the same settings for both variablesCXXFLAGS="${CFLAGS}" ""
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello barnac1e,
This topic isoutside my expertise.
A quick google search suggests using '-march=native'.
Personally, I prefer to just take whatever options the kernel folks supply.
I'm more worried aabout correctness than performance when it comes to the kernel.
Then, after you've built the kernel and have it working with your application, if you find that there is some kernel function which is actually taking longer than you think it should, you can try optimizing that function and see if it makes a difference.
Or, you can ask the kernel folks in charge of that particular section of code.
And then there is the idea of getting security patches and needing a new kernel.
I guess you can tell I'm not a fan of trying stuff like this... I have too much work to do already.
Good luck.
Pat
This topic isoutside my expertise.
A quick google search suggests using '-march=native'.
Personally, I prefer to just take whatever options the kernel folks supply.
I'm more worried aabout correctness than performance when it comes to the kernel.
Then, after you've built the kernel and have it working with your application, if you find that there is some kernel function which is actually taking longer than you think it should, you can try optimizing that function and see if it makes a difference.
Or, you can ask the kernel folks in charge of that particular section of code.
And then there is the idea of getting security patches and needing a new kernel.
I guess you can tell I'm not a fan of trying stuff like this... I have too much work to do already.
Good luck.
Pat
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page