add a config option for -Os compilation
Quoted 1 line · Martin J. Bligh
If you have a puny 128K L2 cache, it might help,
[ I accept this as a flame-bait. ]
Can you be little bit less ignorant? Eh?
Please. I beg you.
Linux is used not only by you, and not only on huge NUMA boxes with
huge caches <flame-bait>to hide stupid design flaws</flame-bait>. (can't wait when clusters of hand-helds connected over bluetooth will wipe out mainframe market :)))
My system has 16K L1 cache. Only L1. And what should I do?
I was benchmarking 2.4.1[68] some time ago and -Os helps gcc to
produce faster code (both gcc 2.95.3 and 3.2.3). (It was Geode. But e.g. Motorolla's PowerQuicc has 16K L1 too - but I'm not sure does -Os help on ppc)
On my test difference was around 5-7%. Task was very IO intensive
with few of computational branches. Size of .text ~ 800K, .bss ~ 400K.
Quoted 3 lines
Please don't - I benchmarked it a while ago, and it's definitely slower. If you have a puny 128K L2 cache, it might help, but it definitely needs to be optional.
Optional - would be Okay.
P.S. That's dependency on GCC what should be optional. Let's not forget the source of the problem.
Signature · 5 lines
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
--
"... and for $64000 question, could you get yourself vaguely
familiar with the notion of on-topic posting?"
-- Al Viro @ LKMLQuoted 8 lines · Adrian Bunk
Quoted 2 lines · Ihar 'Philips' Filipau
Quoted 1 line · Martin J. Bligh
If you have a puny 128K L2 cache, it might help,
Martin was ironically talking about people who are ignorant of machines with _huge_ caches.
Oh. Sorry. Probably I need to work on my English bit more.
Quoted 1 line
I the context of this thread he wanted to vote for making -Os conditionally and not unconditionally enabled by telling that he knows of situations where -O2 produces faster code.
Absolutely.
High-end toys, after all, optimized to handle this.
IMHO this should be settled on per-target basis: embedded system -
-Os; servers - -O2; desktops - -O3 ;) So instead of CONFIG_EMBEDDED better to have CONFIG_TARGET=[desktop|server|embedded].
Inroducing one more variable into builds - is really painful. I was
hit by gcc miscompiles and internal errors not once (especially with -O[23]). Tracking down this kind of issues would be made more problematic.
P.S. I'm really sorry for my rude response.
Signature · 5 lines
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
--
"... and for $64000 question, could you get yourself vaguely
familiar with the notion of on-topic posting?"
-- Al Viro @ LKMLQuoted 10 lines
Quoted 3 lines
Martin was ironically talking about people who are ignorant of machines with _huge_ caches.
Oh. Sorry. Probably I need to work on my English bit more.
Quoted 3 lines
I the context of this thread he wanted to vote for making -Os conditionally and not unconditionally enabled by telling that he knows of situations where -O2 produces faster code.
Quoted 8 lines
Absolutely.
High-end toys, after all, optimized to handle this.IMHO this should be settled on per-target basis: embedded system - -Os; servers - -O2; desktops - -O3 ;) So instead of
CONFIG_EMBEDDEDbetter to haveCONFIG_TARGET=[desktop|server|embedded].Inroducing one more variable into builds - is really painful. I was hit by gcc miscompiles and internal errors not once (especially with -O[23]). Tracking down this kind of issues would be made more problematic.
P.S. I'm really sorry for my rude response.
;-) No problem.
But if someone with a small cache would actually *measure* the damned thing, I'd be more impressed ... I've never seen that, but perhaps I just missed it.
Point is the same either way though ... we shouldn't unconditionally optimise for *anyone's* system. If it's faster on all systems that anyone can be bothered to measure, great. If it's faster on some, and slower on others, a config option seems more appropriate, defaulting to the majority of users.
M.