debian faster than gentoo

[ozonator]

ozonator: On a side note I have read that you make Propolice ineffective when enabling -O3

Hadn't heard that before, but you're right. Here's what the propolice docs say: "When you specify the option -O3, the protection instruments may be eliminated by the optimizer." So, it doesn't necessarily make propolice ineffective, but depending on the code, some optimizations might make stack protection impossible. Based on the difference between -O3 and -O2, this implies that there's something about -finline-functions and/or -frename-registers that's the source of the potential ineffectiveness. Whatever the details, no matter -- I'd rather take the chance with -fstack-protector that it can make a difference, even if only in some circumstances. Besides, now that I'll be using -Os, I can add improved propolice functionality to the list of benefits.

As for there being a performance hit with propolice, the propolice docs indicate that there can a performance hit of up to 8%, but in practice it should be much less than that (4% is the maximum hit they report with a 'real world' program); depending on the program, it might be nil. I didn't check for a performance hit myself, since I'd rather increase my chances of having secure code by using it. The only thing I can offer is that I also use OpenBSD, which implemented propolice system-wide a little over a year ago; I don't recall noticing any difference in speed when moving to the newly-compiled version.

[siti]

Some tests:
http://www.trl.ibm.com/projects/securit ... 0000000000
These tests show around 8% but these tests was done quite a while ago so it might be less than that.

[ozonator]

An addendum to my initial post in this thread, reporting my experience switching to -O2/-Os from -O3.

1. Just noticed this in the ebuild for glibc-2.3.2-r1:

Code: Select all

# Lock glibc at -O2 -- linuxthreads needs it and we want to be conservative here
export CFLAGS="${CFLAGS//-O?} -O2"
export CXXFLAGS="${CFLAGS}"

If that's so, then why might re-emerging glibc with -O2 or -Os in $CFLAGS result in different performance from -O3? I thought it seemed faster when I re-emerged, but if it was compiled with -O2 in each case, the difference may have been made by the other changes to $CFLAGS I made when moving to -O2/-Os: dropping -funroll-loops and adding -s. Does that make sense?

2. In most cases, I'm finding that -Os binaries are indeed smaller than those built with -O2. While there are a few exceptions that are about the same size or a few bytes larger, there's one that seems to be much bigger with -Os: abiword -- the Abiword-2.0 binary is 4440128 bytes with -Os, 4106464 with -O2. Strange; I'll try re-emerging to make sure this isn't an anomaly. I know that -Os isn't a guarantee that the binary will be smaller, and I'm not surprised to see things coming out at approximately the same size, but I still wonder why this might be.

[Joe]

Another point for per-package-USE-Flags...

Obviosly there isnt one compiler setting matching perfectly to all of your packages, as there isnt the one and only USE-Flags-Setting.


Regards,

Joe

[regeya]

I don't know that '-Os' is 'hot' per se, but those of us with very little on-proc cache might give it a try. I've noticed a bit of a noticible difference(!)

My guess is that because the proc is doing fewer fetches from system RAM, that's giving me a bit of a boost. Again, just my guess.

[zhenlin]

yes.. people like me

And me...

No such luck for me - I had to file several -Os related bugs.

Back to -O2 for me.

[Zeitgeist]

I've found -O2 to be faster than -O3. I see lots of people throwing out tons of cflags they don't even know what they do.

Running lots of benchmakrs and i've found -march=pentium4 -O2 -fomit-frame-pointer to be the best for m.e

[30726]

I've found -O2 to be faster than -O3. I see lots of people throwing out tons of cflags they don't even know what they do.

Running lots of benchmakrs and i've found -march=pentium4 -O2 -fomit-frame-pointer to be the best for m.e

Same here. I've had problems with both -O3 and -Os, so I'm sticking with -O2 for now on. Must be pretty stable to use since almost the entire Slackware distribution is compiled with -O2 (http://www.osnews.com/story.php?news_id=3166&page=2).

[Zeitgeist]

Same here. I've had problems with both -O3 and -Os, so I'm sticking with -O2 for now on. Must be pretty stable to use since almost the entire Slackware distribution is compiled with -O2 (http://www.osnews.com/story.php?news_id=3166&page=2).

Most distributions compile with something like -O2 mpcu=i686 or something conservative. Debian only uses -O2 I believe.

[jcmorris]

Well guys, here is my theory. If you notice, the more flags you have, the larger the binary. However, if the optimizations produced code too large, that would increase load times, and since it just bigger code, wouldn't that translate into requiring more memory accesses to retrieve all the extra instructions and data? And, since it takes several CPU cycles per memory access, wouldn't that translate into slower overall speed an less responsiveness? Well guys, I'm in the process of installing an LFS (Linux From Scratch) system, and I'm going to use -march=athlon-xp -O2 -mfpmath=sse -fomit-frame-pointer -malign-double -ffast-math -fforce-addr -mno-push-args

My current Gentoo setup uses
-march=athlon-xp -O2 -fomit-frame-pointer -pipe -fforce-addr -maccumulate-outgoing-args -funroll-loops -mno-push-args

I think I'll compare them side-by-side. I'll let you know how it goes.

Now, the reasons why I'm going to try these particular CFLAGS:
1) I think -O2 will produce binaries that load quicker than O3. I won't use -Os because it doesn't align functions, loops, and jumps, which I can see as improving performance greatly.
2) -malign-double seems to align doubles in a more favorable fashion, and possibly make retrieving them faster
3) -ffast-math I can't see it increasing size, just speed, so I'll try it
4) -fforce-addr and -fforce-mem seem so intuitive to me. Since register-to-register operations are always faster than memory-to-memory, it makes sense to copy operands into registers, do the work, and then put the result back in RAM.
5) -fomit-frame-pointer, some packages don't like it, but most do. This will really help free up an extra register
6) -mnopush-args, I think the code increase is pretty much not considerable, and may be faster in rare cases
7) I'm dropping -maccumulate-outgoing-args, because while fast, it gives a large increase in code size, so I think this may cause more harm than good.

In general, I believe that these test flags will be a good balance between speed/size.

I think though, that we are going to see that there is no good set of optimizations. I think it varies greatly for each program. I think that in the long run we'll find it best to use the "least common denominator" for overall best average speed. I think the best thing is to change CFLAGS for each individual package, but this would take forever!

jcm