I've read a few things about this option while compiling, but does this have a real difference for building PAC ?
I mean, will there there be any noticeable difference ?
I mean, will there there be any noticeable difference ?
Building with -o3
- Thread starter bud77
- Start date
I'm a long-time Gentoo Linux user (over 10 years as my primary OS) where every application is compiled from the sources. In the Gentoo installation guide, and on their Wiki the recommended -O optimization is -O2. From the guide located here https://wiki.gentoo.org/wiki/GCC_optimization
"There are seven -O settings: -O0, -O1, -O2, -O3, -Os, -Og, and -Ofast..... With the exception of -O0, the -O settings each activate several additional flags, so be sure to read the GCC manual's chapter on optimization options to learn which flags are activated at each -O level, as well as some explanations as to what they do.
Let's examine each optimization level:
-O0: This level (that's the letter "O" followed by a zero) turns off optimization entirely and is the default if no -O level is specified in CFLAGS or CXXFLAGS. This reduces compilation time and can improve debugging info, but some applications will not work properly without optimization enabled. This option is not recommended except for debugging purposes.
-O1: This is the most basic optimization level. The compiler will try to produce faster, smaller code without taking much compilation time. It's pretty basic, but it should get the job done all the time.
-O2: A step up from -O1. This is the recommended level of optimization unless you have special needs. -O2 will activate a few more flags in addition to the ones activated by -O1. With -O2, the compiler will attempt to increase code performance without compromising on size, and without taking too much compilation time.
-O3: This is the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with -O3 is not a guaranteed way to improve performance, and in fact in many cases can slow down a system due to larger binaries and increased memory usage. -O3 is also known to break several packages. Therefore, using -O3 is not recommended.
-Os: This option will optimize your code for size. It activates all -O2 options that don't increase the size of the generated code. It can be useful for machines that have extremely limited disk storage space and/or have CPUs with small cache sizes.
-Og: In GCC 4.8, a new general optimization level, -Og, has been introduced. It addresses the need for fast compilation and a superior debugging experience while providing a reasonable level of runtime performance. Overall experience for development should be better than the default optimization level -O0. Note that -Og does not imply -g, it simply disables optimizations that may interfere with debugging.
-Ofast: New in GCC 4.7, consists of -O3 plus -ffast-math, -fno-protect-parens, and -fstack-arrays. This option breaks strict standards compliance, and is not recommended for use.
As previously mentioned, -O2 is the recommended optimization level. If package compilation fails and you aren't using -O2, try rebuilding with that option. As a fallback option, try setting your CFLAGS and CXXFLAGS to a lower optimization level, such as -O1 or even -O0 -g2 -ggdb (for error reporting and checking for possible problems)."
As you can see -O2 is the recommended optimization level and is what I use in my systems. In fact, if you compile with -O3 and have an issue Gentoo won't accept your bug report until you've gone back and recompiled with -O2 or lower optimization first. Compiling with -O3 has long been known to be problematic. The resulting binaries tend to be considerably larger (not desirable on memory limited devices like phones) and often behave in unexpected ways.
Google is your friend, there is much info regarding this on the net. The more you look at it the more you'll find that the consensus is that the best combination of binary speed, size and stability is usually achieved with -O2 or -Os optimization.
Last edited:
Thanks, but I alread read such things
My question was wether there was a real gain rom in building with o3
Anyway, I tried and installed it, and it's running fine for the past 2 days now
But no noticeable difference
My question was wether there was a real gain rom in building with o3
Anyway, I tried and installed it, and it's running fine for the past 2 days now
But no noticeable difference
I understood what your question was, and believed I gave a thorough answer. In most mobile devices which are generally RAM starved, have small caches and lack storage capacity, whatever little bit you might gain in speed via -O3 optimization is lost because the binaries are considerably larger. The unwanted cache thrashing alone probably counters whatever performance gain is made in optimization. And because these binaries sometimes exhibit unexpected behavior, there's a possibility of introducing unwanted instability. These affects are well known and why I chose to compile my ROM(s) with -Os or -O2.
Last edited:
Top Liked Posts
-
There are no posts matching your filters.
-
3
I'm a long-time Gentoo Linux user (over 10 years as my primary OS) where every application is compiled from the sources. In the Gentoo installation guide, and on their Wiki the recommended -O optimization is -O2. From the guide located here https://wiki.gentoo.org/wiki/GCC_optimization
"There are seven -O settings: -O0, -O1, -O2, -O3, -Os, -Og, and -Ofast..... With the exception of -O0, the -O settings each activate several additional flags, so be sure to read the GCC manual's chapter on optimization options to learn which flags are activated at each -O level, as well as some explanations as to what they do.
Let's examine each optimization level:
-O0: This level (that's the letter "O" followed by a zero) turns off optimization entirely and is the default if no -O level is specified in CFLAGS or CXXFLAGS. This reduces compilation time and can improve debugging info, but some applications will not work properly without optimization enabled. This option is not recommended except for debugging purposes.
-O1: This is the most basic optimization level. The compiler will try to produce faster, smaller code without taking much compilation time. It's pretty basic, but it should get the job done all the time.
-O2: A step up from -O1. This is the recommended level of optimization unless you have special needs. -O2 will activate a few more flags in addition to the ones activated by -O1. With -O2, the compiler will attempt to increase code performance without compromising on size, and without taking too much compilation time.
-O3: This is the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with -O3 is not a guaranteed way to improve performance, and in fact in many cases can slow down a system due to larger binaries and increased memory usage. -O3 is also known to break several packages. Therefore, using -O3 is not recommended.
-Os: This option will optimize your code for size. It activates all -O2 options that don't increase the size of the generated code. It can be useful for machines that have extremely limited disk storage space and/or have CPUs with small cache sizes.
-Og: In GCC 4.8, a new general optimization level, -Og, has been introduced. It addresses the need for fast compilation and a superior debugging experience while providing a reasonable level of runtime performance. Overall experience for development should be better than the default optimization level -O0. Note that -Og does not imply -g, it simply disables optimizations that may interfere with debugging.
-Ofast: New in GCC 4.7, consists of -O3 plus -ffast-math, -fno-protect-parens, and -fstack-arrays. This option breaks strict standards compliance, and is not recommended for use.
As previously mentioned, -O2 is the recommended optimization level. If package compilation fails and you aren't using -O2, try rebuilding with that option. As a fallback option, try setting your CFLAGS and CXXFLAGS to a lower optimization level, such as -O1 or even -O0 -g2 -ggdb (for error reporting and checking for possible problems)."
As you can see -O2 is the recommended optimization level and is what I use in my systems. In fact, if you compile with -O3 and have an issue Gentoo won't accept your bug report until you've gone back and recompiled with -O2 or lower optimization first. Compiling with -O3 has long been known to be problematic. The resulting binaries tend to be considerably larger (not desirable on memory limited devices like phones) and often behave in unexpected ways.
Google is your friend, there is much info regarding this on the net. The more you look at it the more you'll find that the consensus is that the best combination of binary speed, size and stability is usually achieved with -O2 or -Os optimization.1
I understood what your question was, and believed I gave a thorough answer. In most mobile devices which are generally RAM starved, have small caches and lack storage capacity, whatever little bit you might gain in speed via -O3 optimization is lost because the binaries are considerably larger. The unwanted cache thrashing alone probably counters whatever performance gain is made in optimization. And because these binaries sometimes exhibit unexpected behavior, there's a possibility of introducing unwanted instability. These affects are well known and why I chose to compile my ROM(s) with -Os or -O2.
