Re: RFC: Moving to -O3 for Fedora Linux
I found Os to offer the best all around gcc and with C files. I tested a large number of string type content files (not float or other numeric calculations) source fileswith gcc and with clang. gcc provides a smaller executable than does clang, and Os does much better than O3 I used CFLAGS := -Os -Wall -Wextra -Fpic -I./includes/ -march=x86-64 -Werror \ -std=gnu11 -fPIC #-Wpedantic #-c -E #--analyze Make veryclean all strip. veryclean: rm's all objs and excutables. all: recreates using $cc strip: removes unnecessary meta stuff around the executables. Savings using -Os are substantial, for my tests, about 400bytes per executable. Leslie Satenstein On Thursday, October 31, 2024 at 01:38:01 a.m. EDT, Carlos Rodriguez-Fernandez wrote: It would be great to see some empirical analysis about binary size increase, its impact on RAM consumption, and actual speed benefit, especially on Fedora. I'm having a hard time finding anything about it. Regards, Carlos R.F. On 10/30/24 7:46 PM, Neal Gompa wrote: > Hey folks, > > I know the idea of moving to -O3 has been briefly mentioned before in > other contexts when we've discussed uplifting the flags, but it looks > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > why we shouldn't consider doing the same for Fedora Linux 42? > > [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2024-October/043164.html > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
Neal Gompa wrote: > I know the idea of moving to -O3 has been briefly mentioned before in > other contexts when we've discussed uplifting the flags, but it looks > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > why we shouldn't consider doing the same for Fedora Linux 42? Yes, there is. The toolchain developers are against it. It bloats the programs, often leading to a performance decrease instead of the desired increase, and definitely leading to an increase in disk space and RAM use. Upstream GCC recommends using -O2 for a reason. See also Jakub Jelinek's reply. Can we please not copy every bad idea Ubuntu comes up with? It is bad enough that we are bloating and slowing down the entire distribution with frame pointers that are completely useless to the vast majority (I would estimate >99%) of our user base (because only developers can possibly make any use of the frame pointers, not end users, and even developers only need it if they use some specific profilers, whereas debuggers and even some profilers can work just fine with unwinding information) over the objections of the toolchain team. Now you want to ignore their recommendations yet again, leading to yet another global distro-wide size increase, with no evidence of any real-world speed increase. If we are going to consider switching away from -O2, then I would recommend -Os rather than -O3. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On 10/30/24 7:46 PM, Neal Gompa wrote: > Hey folks, > > I know the idea of moving to -O3 has been briefly mentioned before in > other contexts when we've discussed uplifting the flags, but it looks > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > why we shouldn't consider doing the same for Fedora Linux 42? > > [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2024-October/043164.html FWIW, Rust already uses the equivalent -Copt-level=3, both as the default cargo "release" profile and in Fedora's %build_rustflags. That's using LLVM though, so it's a separate risk analysis from GCC, and Rust also has a much smaller package footprint overall. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
If -O3 makes debugging harder, then I'm against its default use. If there are no public, documented measurements that -O3 is better for a specific package, then don't use -O3 for that package. I work with tool chains for software development, and with low-level libraries such as glibc, musl, uClibc, libbfd, etc. I encounter disagreements over the actual interface between components, and the applied meaning of specifications. This leads to debugging random apps and the packages that they depend on. For released Fedora packages, this involves debuginfod and debuginfo servers. While debugging, then a gdb message such as "value optimized out", or a misleading diagnosis of the correspondence between PC value and source location, becomes a significant stumbling block. Sometimes I can learn indirectly I want; other times a re-build using -O1 or -O0 is better, but takes more time. If default use of -O3 makes my debugging harder than the current default of -O2, then for me that's a step backwards. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
Am 31.10.24 um 19:18 schrieb Jakub Jelinek: On Thu, Oct 31, 2024 at 07:14:08PM +0100, Kilian Hanich via devel wrote: While we are at it, please don't mix -O2 and -O3 while compiling the same program. This can break things and is really not fun to debug (and that's also the reason why a lot of buildsystems don't support that). It works just fine, one can actually do it even in a single file, this function is -O3, this is -O2, etc. And effectively PGO is all about that, this function or basic block is hot, more optimization which could increase size and likely improve performance are done on it, this is cold, do other optimizations on it. Jakub Technically yes, but as somebody in this thread stated, -O3 sometimes manages to break programs which were relying on UB. Mixing -02 and -03 does this considerably more often. From my experience you also run surprisingly often into compiler bugs (likely because that's rarely done since, as I already stated, most build systems don't support mixing). One case where this happens is especially with templates in header files because this can create different instantiations of it even they should be the same. But PGO has these bugs less often as I noticed myself. I don't know why, but my guess would be because the compiler gets information about the whole program instead of just parts (the current C or C++ file). Either way it should be interesting to see how this will be with C++ modules because these really dislike changing compiler options even slightly (after all, the idea is that compilers can just mmap these without parsing; at least as far as I know). Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 07:14:08PM +0100, Kilian Hanich via devel wrote: > While we are at it, please don't mix -O2 and -O3 while compiling the > same program. > > This can break things and is really not fun to debug (and that's also > the reason why a lot of buildsystems don't support that). It works just fine, one can actually do it even in a single file, this function is -O3, this is -O2, etc. And effectively PGO is all about that, this function or basic block is hot, more optimization which could increase size and likely improve performance are done on it, this is cold, do other optimizations on it. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
Am 31.10.24 um 19:02 schrieb Jakub Jelinek: On Thu, Oct 31, 2024 at 07:47:22PM +0200, drago01 wrote: Isn't instruction cache footprint already part of "performance" i.e if performance is improved it shouldn't matter and vice versa, or what am I missing? That is not how compilers work, ... That's not what I meant sorry. I mean we shouldn't worry about size or cache footprint, in the end what matters is performance. If we compile with -O3 and binaries are faster it doesn't matter if the code size is larger. Likewise if they are just bigger and perform worse or similar to -O2 it's pointless. Or iow cache footprint and binary size are just factors that determine performance, but not goals on their own. Most of the code in the distro is cold, executed once or rarely, so making it unnecessarily larger will slow things down, e.g. by pushing the hot code out of the caches. As I said, -O3 (or even enabling some specific optimizations on top of that) is something that should be done selectively for code known to be hot/important for the performance, one runs a profiler, sees what code is performance critical, tries if -O3 helps that code, and if yes, uses it for that. Enabling it blindly is not what it is designed for, -O2 is the level meant to be used for most of the code. Jakub While we are at it, please don't mix -O2 and -O3 while compiling the same program. This can break things and is really not fun to debug (and that's also the reason why a lot of buildsystems don't support that). Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 07:47:22PM +0200, drago01 wrote: > > > Isn't instruction cache footprint already part of "performance" i.e if > > > performance is improved it shouldn't matter and vice versa, or what am I > > > missing? > > > > That is not how compilers work, ... > > > > That's not what I meant sorry. I mean we shouldn't worry about size or > cache footprint, in the end what matters is performance. If we compile with > -O3 and binaries are faster it doesn't matter if the code size is larger. > Likewise if they are just bigger and perform worse or similar to -O2 it's > pointless. Or iow cache footprint and binary size are just factors that > determine performance, but not goals on their own. Most of the code in the distro is cold, executed once or rarely, so making it unnecessarily larger will slow things down, e.g. by pushing the hot code out of the caches. As I said, -O3 (or even enabling some specific optimizations on top of that) is something that should be done selectively for code known to be hot/important for the performance, one runs a profiler, sees what code is performance critical, tries if -O3 helps that code, and if yes, uses it for that. Enabling it blindly is not what it is designed for, -O2 is the level meant to be used for most of the code. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thursday, October 31, 2024, Jakub Jelinek wrote: > On Thu, Oct 31, 2024 at 10:15:03AM +0200, drago01 wrote: > > On Thursday, October 31, 2024, Jakub Jelinek wrote: > > > > > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > > > I know the idea of moving to -O3 has been briefly mentioned before in > > > > other contexts when we've discussed uplifting the flags, but it looks > > > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > > > why we shouldn't consider doing the same for Fedora Linux 42? > > > > > > Yes, this is a very bad idea. > > > > > > -O3 significantly increases code size (and the speed up gains aren't > really > > > guaranteed), which is highly undesirable when the vast majority of > code in > > > the distro isn't performance critical, the I-cache footprint is then > more > > > important. > > > Isn't instruction cache footprint already part of "performance" i.e if > > performance is improved it shouldn't matter and vice versa, or what am I > > missing? > > That is not how compilers work, ... > That's not what I meant sorry. I mean we shouldn't worry about size or cache footprint, in the end what matters is performance. If we compile with -O3 and binaries are faster it doesn't matter if the code size is larger. Likewise if they are just bigger and perform worse or similar to -O2 it's pointless. Or iow cache footprint and binary size are just factors that determine performance, but not goals on their own. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, 31 Oct 2024 at 11:11, Jakub Jelinek wrote: > > On Thu, Oct 31, 2024 at 10:57:02AM +, Peter Robinson wrote: > > On Thu, 31 Oct 2024 at 07:32, Jakub Jelinek wrote: > > > > > > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > > > I know the idea of moving to -O3 has been briefly mentioned before in > > > > other contexts when we've discussed uplifting the flags, but it looks > > > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > > > why we shouldn't consider doing the same for Fedora Linux 42? > > > > > > Yes, this is a very bad idea. > > > > > > -O3 significantly increases code size (and the speed up gains aren't > > > really > > > guaranteed), which is highly undesirable when the vast majority of code in > > > the distro isn't performance critical, the I-cache footprint is then more > > > important. Especially when -O2 in GCC performs some vectorization already > > > for years and it is going to be used more at -O2 in GCC 15 (but the > > > heuristics for -O2 vectorization is avoid significant code increases). > > > > > > -O3 should be used just for performance critical code, which is found to > > > be > > > hot in profiling and proved to help performance of the code. > > > Better yet, performance criticial code should use PGO (profile guided > > > optimizations) so that only the hot parts of the code are automatically > > > optimized for speed and cold parts for size. With reasonable workload > > > used > > > during package build for the profile feedback generation. > > > > > > There are some packages in the distro which use PGO (e.g. gcc itself), but > > > I think e.g. SUSE packages use PGO far more often than in Fedora. > > > > How does SUSE choose to use PGO? Is that a manual process where the > > maintainer chooses to turn it on for a particular library or binary? > > I think so. > It needs some package specific know-how. > Basically, one needs to build the binaries and/or libraries with > -fprofile-generate flag in addition to normal compiler flags, then > run the binaries with the libraries on some typical workload and > finally rebuild again with -fprofile-use flag instead of -fprofile-generate. > It can be combined with LTO and generally LTO+PGO results in better speedups > over just one of those separately. > Testsuites often aren't very good workloads because they usually spend more > time on unlikely corner cases than on the common cases, but can be used when > there isn't anything better. > E.g. GCC when building itself has as the workload building itself, so is > trained mostly on C++ code and far less on C code, for shells I'd imagine one > should run a few configure scripts with the newly built shell, etc. > I guess one could look at SUSE debuginfo packages and see what packages have > been built with -fprofile-use and learn from their spec files (if the > corresponding packages in Fedora already don't use that). > Where PGO isn't ideal is multi-versioned code where the binaries/libraries > decide based on the build box hw capabilities on if one or another code > should be used; in that case depending on what the build box hw capabilities > were, some code can look unused even if it could be hot on other hw. I seem to remember firefox uses LTO+PGO for speed ups/ I wonder if we could provide some rpm macros and packaging guidelines to assist packagers in this process to make things more straight forward and less error prone? Is something like that a reasonable idea? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 12:36:28PM +0100, Jakub Jelinek wrote: > On Thu, Oct 31, 2024 at 11:26:23AM +, Peter Robinson wrote: > > I seem to remember firefox uses LTO+PGO for speed ups/ > > > > I wonder if we could provide some rpm macros and packaging guidelines > > to assist packagers in this process to make things more straight > > forward and less error prone? Is something like that a reasonable > > idea? > > Depends. Some packages like gcc, firefox and a few others already > have some configure or make (or whatever build system they use) options > to do the PGO build. Those should just use what the upstream provides and > don't need any new rpm macros. > Others perhaps could make use of them, but I think only conversion of a > dozens+ of packages for PGO would reveal how those macros should look like > and what would be helpful and what wouldn't. > The running of a -fprofile-generate instrumented program creates > something.c.gcda etc. files and those need to be then in the tree built > with -fprofile-use. Are the *.gcda files portable or must they be consumed by the exact same source / GCC combination? What I'm asking is, can those be created "offline" and included later in the RPM build, even if the code changes in between? Rich. > See > https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Instrumentation-Options.html#index-fprofile-generate > and > https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html#index-fprofile-use > for some details. > > Jakub > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 12:12:30PM +, Richard W.M. Jones wrote: > On Thu, Oct 31, 2024 at 12:36:28PM +0100, Jakub Jelinek wrote: > > On Thu, Oct 31, 2024 at 11:26:23AM +, Peter Robinson wrote: > > > I seem to remember firefox uses LTO+PGO for speed ups/ > > > > > > I wonder if we could provide some rpm macros and packaging guidelines > > > to assist packagers in this process to make things more straight > > > forward and less error prone? Is something like that a reasonable > > > idea? > > > > Depends. Some packages like gcc, firefox and a few others already > > have some configure or make (or whatever build system they use) options > > to do the PGO build. Those should just use what the upstream provides and > > don't need any new rpm macros. > > Others perhaps could make use of them, but I think only conversion of a > > dozens+ of packages for PGO would reveal how those macros should look like > > and what would be helpful and what wouldn't. > > The running of a -fprofile-generate instrumented program creates > > something.c.gcda etc. files and those need to be then in the tree built > > with -fprofile-use. > > Are the *.gcda files portable or must they be consumed by the exact > same source / GCC combination? What I'm asking is, can those be > created "offline" and included later in the RPM build, even if the > code changes in between? They are dependent on the exact source and compiler options used to compile them. Basically, they add tons of counters for various events, like passing through some control flow graph edge etc. And obviously the -fprofile-generate and -fprofile-use compilations need to agree what the counters are for, so the source needs to have the same control flow graph, same order of functions, ... So no, you don't want to ship -fprofile-generate instrumented binaries/libraries in binary rpms and somehow arrange for the *.gcda files to be fed back to next build. That is what AutoFDO intends to do (one profiles non-instrumented binaries, which are then profiled and fuzzy matched to the new compilation). AutoFDO is significantly less tested than normal PGO and I'd strongly advise we avoid that. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 07:28:35AM -0400, Neal Gompa wrote: > SUSE has the benefit of their build system taking care of automatic > rebuilds and simple build loops for them. This allows them to have a > much more hands-off approach than we do, and gives their packagers > significantly more breathing room to take advantage of things like > this. PGO is something that should be done within the build of a single package, so I don't see how that is related. There is also AutoFDO where one just builds programs/libraries, then runs them under profiler separately and can then just pass the profiler saved details to next build, which is something that in theory could be used across different rpm builds, but AutoFDO larger goes against package build reproducibility (normal PGO can be only problem for reproducibility in multi-threaded programs built with -fprofile-update=single or if threads aren't properly joined; one can build with explicit -fprofile-update=atomic or just compile/link with -pthread to get atomic (sure, more expensive) profile counter updates). Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 11:26:23AM +, Peter Robinson wrote: > I seem to remember firefox uses LTO+PGO for speed ups/ > > I wonder if we could provide some rpm macros and packaging guidelines > to assist packagers in this process to make things more straight > forward and less error prone? Is something like that a reasonable > idea? Depends. Some packages like gcc, firefox and a few others already have some configure or make (or whatever build system they use) options to do the PGO build. Those should just use what the upstream provides and don't need any new rpm macros. Others perhaps could make use of them, but I think only conversion of a dozens+ of packages for PGO would reveal how those macros should look like and what would be helpful and what wouldn't. The running of a -fprofile-generate instrumented program creates something.c.gcda etc. files and those need to be then in the tree built with -fprofile-use. See https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Instrumentation-Options.html#index-fprofile-generate and https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html#index-fprofile-use for some details. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 7:20 AM Jakub Jelinek wrote: > > On Thu, Oct 31, 2024 at 10:57:02AM +, Peter Robinson wrote: > > On Thu, 31 Oct 2024 at 07:32, Jakub Jelinek wrote: > > > > > > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > > > I know the idea of moving to -O3 has been briefly mentioned before in > > > > other contexts when we've discussed uplifting the flags, but it looks > > > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > > > why we shouldn't consider doing the same for Fedora Linux 42? > > > > > > Yes, this is a very bad idea. > > > > > > -O3 significantly increases code size (and the speed up gains aren't > > > really > > > guaranteed), which is highly undesirable when the vast majority of code in > > > the distro isn't performance critical, the I-cache footprint is then more > > > important. Especially when -O2 in GCC performs some vectorization already > > > for years and it is going to be used more at -O2 in GCC 15 (but the > > > heuristics for -O2 vectorization is avoid significant code increases). > > > > > > -O3 should be used just for performance critical code, which is found to > > > be > > > hot in profiling and proved to help performance of the code. > > > Better yet, performance criticial code should use PGO (profile guided > > > optimizations) so that only the hot parts of the code are automatically > > > optimized for speed and cold parts for size. With reasonable workload > > > used > > > during package build for the profile feedback generation. > > > > > > There are some packages in the distro which use PGO (e.g. gcc itself), but > > > I think e.g. SUSE packages use PGO far more often than in Fedora. > > > > How does SUSE choose to use PGO? Is that a manual process where the > > maintainer chooses to turn it on for a particular library or binary? > > I think so. > It needs some package specific know-how. > Basically, one needs to build the binaries and/or libraries with > -fprofile-generate flag in addition to normal compiler flags, then > run the binaries with the libraries on some typical workload and > finally rebuild again with -fprofile-use flag instead of -fprofile-generate. > It can be combined with LTO and generally LTO+PGO results in better speedups > over just one of those separately. > Testsuites often aren't very good workloads because they usually spend more > time on unlikely corner cases than on the common cases, but can be used when > there isn't anything better. > E.g. GCC when building itself has as the workload building itself, so is > trained mostly on C++ code and far less on C code, for shells I'd imagine one > should run a few configure scripts with the newly built shell, etc. > I guess one could look at SUSE debuginfo packages and see what packages have > been built with -fprofile-use and learn from their spec files (if the > corresponding packages in Fedora already don't use that). > Where PGO isn't ideal is multi-versioned code where the binaries/libraries > decide based on the build box hw capabilities on if one or another code > should be used; in that case depending on what the build box hw capabilities > were, some code can look unused even if it could be hot on other hw. > SUSE has the benefit of their build system taking care of automatic rebuilds and simple build loops for them. This allows them to have a much more hands-off approach than we do, and gives their packagers significantly more breathing room to take advantage of things like this. I don't think we can reasonably do so at scale as long as we don't have features like this. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 10:57:02AM +, Peter Robinson wrote: > On Thu, 31 Oct 2024 at 07:32, Jakub Jelinek wrote: > > > > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > > I know the idea of moving to -O3 has been briefly mentioned before in > > > other contexts when we've discussed uplifting the flags, but it looks > > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > > why we shouldn't consider doing the same for Fedora Linux 42? > > > > Yes, this is a very bad idea. > > > > -O3 significantly increases code size (and the speed up gains aren't really > > guaranteed), which is highly undesirable when the vast majority of code in > > the distro isn't performance critical, the I-cache footprint is then more > > important. Especially when -O2 in GCC performs some vectorization already > > for years and it is going to be used more at -O2 in GCC 15 (but the > > heuristics for -O2 vectorization is avoid significant code increases). > > > > -O3 should be used just for performance critical code, which is found to be > > hot in profiling and proved to help performance of the code. > > Better yet, performance criticial code should use PGO (profile guided > > optimizations) so that only the hot parts of the code are automatically > > optimized for speed and cold parts for size. With reasonable workload used > > during package build for the profile feedback generation. > > > > There are some packages in the distro which use PGO (e.g. gcc itself), but > > I think e.g. SUSE packages use PGO far more often than in Fedora. > > How does SUSE choose to use PGO? Is that a manual process where the > maintainer chooses to turn it on for a particular library or binary? I think so. It needs some package specific know-how. Basically, one needs to build the binaries and/or libraries with -fprofile-generate flag in addition to normal compiler flags, then run the binaries with the libraries on some typical workload and finally rebuild again with -fprofile-use flag instead of -fprofile-generate. It can be combined with LTO and generally LTO+PGO results in better speedups over just one of those separately. Testsuites often aren't very good workloads because they usually spend more time on unlikely corner cases than on the common cases, but can be used when there isn't anything better. E.g. GCC when building itself has as the workload building itself, so is trained mostly on C++ code and far less on C code, for shells I'd imagine one should run a few configure scripts with the newly built shell, etc. I guess one could look at SUSE debuginfo packages and see what packages have been built with -fprofile-use and learn from their spec files (if the corresponding packages in Fedora already don't use that). Where PGO isn't ideal is multi-versioned code where the binaries/libraries decide based on the build box hw capabilities on if one or another code should be used; in that case depending on what the build box hw capabilities were, some code can look unused even if it could be hot on other hw. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, 31 Oct 2024 at 07:32, Jakub Jelinek wrote: > > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > I know the idea of moving to -O3 has been briefly mentioned before in > > other contexts when we've discussed uplifting the flags, but it looks > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > why we shouldn't consider doing the same for Fedora Linux 42? > > Yes, this is a very bad idea. > > -O3 significantly increases code size (and the speed up gains aren't really > guaranteed), which is highly undesirable when the vast majority of code in > the distro isn't performance critical, the I-cache footprint is then more > important. Especially when -O2 in GCC performs some vectorization already > for years and it is going to be used more at -O2 in GCC 15 (but the > heuristics for -O2 vectorization is avoid significant code increases). > > -O3 should be used just for performance critical code, which is found to be > hot in profiling and proved to help performance of the code. > Better yet, performance criticial code should use PGO (profile guided > optimizations) so that only the hot parts of the code are automatically > optimized for speed and cold parts for size. With reasonable workload used > during package build for the profile feedback generation. > > There are some packages in the distro which use PGO (e.g. gcc itself), but > I think e.g. SUSE packages use PGO far more often than in Fedora. How does SUSE choose to use PGO? Is that a manual process where the maintainer chooses to turn it on for a particular library or binary? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, Oct 31, 2024 at 10:15:03AM +0200, drago01 wrote: > On Thursday, October 31, 2024, Jakub Jelinek wrote: > > > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > > I know the idea of moving to -O3 has been briefly mentioned before in > > > other contexts when we've discussed uplifting the flags, but it looks > > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > > why we shouldn't consider doing the same for Fedora Linux 42? > > > > Yes, this is a very bad idea. > > > > -O3 significantly increases code size (and the speed up gains aren't really > > guaranteed), which is highly undesirable when the vast majority of code in > > the distro isn't performance critical, the I-cache footprint is then more > > important. > Isn't instruction cache footprint already part of "performance" i.e if > performance is improved it shouldn't matter and vice versa, or what am I > missing? That is not how compilers work, no compiler except toys on trivial short examples try all the possible valid code generations and choose the optimal one (after all, without PGO the compiler doesn't even know what code is hot and what is cold, it can just use some heuristics). Compilers instead choose optimization passes based on the -O? options, where -O3 includes over -O2 possibly expensive optimization passes that aren't always guaranteed to improve performance and are often known to increase code size, changes inlining heuristics etc. Similarly -Os doesn't guarantee smallest possible code size, sometimes -Os code can be even bigger than -O2, though not on average, it simply choses optimizations which generally decrease code size or doesn't enable ones that often increase code size and on micro cost decisions can pick smaller code over larger one (or for -O2/-O3 rather estimated faster sequence over slower one). By using PGO, the compiler is told which parts of code are likely hot, which are likely cold, with what arguments some builtin functions are usually called etc., so the compiler can use better heuristics. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thursday, October 31, 2024, Jakub Jelinek wrote: > On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > > I know the idea of moving to -O3 has been briefly mentioned before in > > other contexts when we've discussed uplifting the flags, but it looks > > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > > why we shouldn't consider doing the same for Fedora Linux 42? > > Yes, this is a very bad idea. > > -O3 significantly increases code size (and the speed up gains aren't really > guaranteed), which is highly undesirable when the vast majority of code in > the distro isn't performance critical, the I-cache footprint is then more > important. > Isn't instruction cache footprint already part of "performance" i.e if performance is improved it shouldn't matter and vice versa, or what am I missing? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Wed, Oct 30, 2024 at 10:46:01PM -0400, Neal Gompa wrote: > I know the idea of moving to -O3 has been briefly mentioned before in > other contexts when we've discussed uplifting the flags, but it looks > like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason > why we shouldn't consider doing the same for Fedora Linux 42? Yes, this is a very bad idea. -O3 significantly increases code size (and the speed up gains aren't really guaranteed), which is highly undesirable when the vast majority of code in the distro isn't performance critical, the I-cache footprint is then more important. Especially when -O2 in GCC performs some vectorization already for years and it is going to be used more at -O2 in GCC 15 (but the heuristics for -O2 vectorization is avoid significant code increases). -O3 should be used just for performance critical code, which is found to be hot in profiling and proved to help performance of the code. Better yet, performance criticial code should use PGO (profile guided optimizations) so that only the hot parts of the code are automatically optimized for speed and cold parts for size. With reasonable workload used during package build for the profile feedback generation. There are some packages in the distro which use PGO (e.g. gcc itself), but I think e.g. SUSE packages use PGO far more often than in Fedora. Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
I found some interesting ones [1][2]. The common denominator is that between -O2 and -O3, the runtime improvement is increased a little bit overall but in some cases it can be significant, while the power consumption also increases. The memory access also tends to decrease. None of those study analyze much memory consumption from mapped files. Not sure if it is a big deal. Perhaps having a Fedora qcow2 image compiled with -O3 to compare would help to do some benchmarking and see. [1] https://academic.oup.com/comjnl/article-pdf/58/1/95/5071667/bxt129.pdf [2] https://ieeexplore.ieee.org/abstract/document/8109001 On 10/30/24 10:37 PM, Carlos Rodriguez-Fernandez wrote: It would be great to see some empirical analysis about binary size increase, its impact on RAM consumption, and actual speed benefit, especially on Fedora. I'm having a hard time finding anything about it. Regards, Carlos R.F. On 10/30/24 7:46 PM, Neal Gompa wrote: Hey folks, I know the idea of moving to -O3 has been briefly mentioned before in other contexts when we've discussed uplifting the flags, but it looks like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason why we shouldn't consider doing the same for Fedora Linux 42? [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2024- October/043164.html OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
It would be great to see some empirical analysis about binary size increase, its impact on RAM consumption, and actual speed benefit, especially on Fedora. I'm having a hard time finding anything about it. Regards, Carlos R.F. On 10/30/24 7:46 PM, Neal Gompa wrote: Hey folks, I know the idea of moving to -O3 has been briefly mentioned before in other contexts when we've discussed uplifting the flags, but it looks like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason why we shouldn't consider doing the same for Fedora Linux 42? [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2024-October/043164.html OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Moving to -O3 for Fedora Linux
On Thu, 31 Oct 2024 г. 05:46:01 GMT+3, Neal Gompa wrote: > Is there a reason why we shouldn't consider doing the same for Fedora Linux 42? -O3 is known to break code which rely on undefined behavior and have bigger binaries than -O2. Also -O3 not always improves performance. If -O3 will be default we need an easy way to switch back to -O2 per package. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
