[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FORTIFY_SOURCE for the kernel



Josh Boyer wrote:

If it results in some form of improvement in performance, I'm all for it. I don't think we don't want a degredation in performance just to gain some
size benefits.  Though from past experience, it results in both size _and_
performance improvements for most code.

I'm of the opinion that we should definitely try it.

Too bad the "Summer of Code" thing is over.  This would have made a great
project for some eager coder to play with.

josh



AFAIK, FC has long compiled kernel, firefox and thunderbird with -Os instead of -O2. I personally did some benchmarking of firefox and thunderbird during FC1 in fedora.us. The performance benefit then was small but real, so I added this to the %build sections.

export RPM_OPT_FLAGS=$(echo $RPM_OPT_FLAGS | sed 's/-O2/-Os/')

Recently I was helping my friend debug his genetic mutation simulation code. He was building it with -O3 and was surprised gdb was failing. I told him to try it at -O0 or -O1. Not only was gdb able to debug it at the lower levels, his performance intensive code actually went much faster (maybe 40%) than -O3. In the case of his code, it was both performance and very memory intensive (using 1-3GB of RAM).

Moral of a story like this is that there is no silver bullet of compiler optimization. If you really want to tune for performance, you have to do benchmarking that simulates something like real-world usage. Maybe even different parts of a larger application can be compiled with different flags based upon fine-grained profiling analysis.

The trouble however with this kind of analysis and fine-tuning with our distro is that things continue to change too fast. We don't have all the features that we need, and everything is a moving target. Also in most cases you can get greater long term efficiency and performance gains through profiling for the purpose of fixing/replacing algorithms. Evolution IMAP for example is unusably bad and requires this kind of analysis and rewrite. Compiler flags alone cannot fix bad design.

Warren Togami
wtogami redhat com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]