login
Search
From: Denis Cheng <crquan@gmail.com> the explicit memset call could be optimized out by data initialization, thus all the fill working can be done by the compiler implicitly. and C standard guaranteed all the unspecified data field initialized to zero. Signed-off-by: Denis Cheng <crquan@gmail.com> --- After comments in the former threads: http://lkml.org/lkml/2007/6/18/119 http://lkml.org/lkml/2007/6/18/48 I also think this style of zero initialization would be better. so the patch is little different: --- arch/x86_64/mm/init.c.orig 2007-06-07 10:08:04.000000000 +0800 +++ arch/x86_64/mm/init.c 2007-06-23 13:12:26.000000000 +0800 @@ -406,8 +406,8 @@ void __cpuinit zap_low_mappings(int cpu) #ifndef CONFIG_NUMA void __init paging_init(void) { - unsigned long max_zone_pfns[MAX_NR_ZONES]; - memset(max_zone_pfns, 0, sizeof(max_zone_pfns)); + unsigned long max_zone_pfns[MAX_NR_ZONES] = {}; + max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN; max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN; max_zone_pfns[ZONE_NORMAL] = end_pfn; -
* From: Denis Cheng
* Newsgroups: linux.kernel
Why not just show actual objdump output on code (maybe with different
oxygen atoms used in gcc), rather than *talking* about optimization and
standards, hm?
I bet, that will be a key for success. And if you are interested in such
optimizations, why not to grep whole source tree for this kind of
things? I'm not sure one function in arch/x86_64 is only such ``unoptimized''.
And after doing that maybe you will see, that "{}" initializer can be
applied not only to integer values (you did init with of *long int*,
with *int*, btw), but to structs and others.
Ahh, one more thing about _optimizing_ your time, i.e. not wasting one.
Add to CC list people, who already did reply on you patch. Otherwise
you are showing your disrespect for them and hiding from further
discussion.
I think you do not, but Linux development not have an automatic system
for patch tracking, so you are on your own with your text editor and
e-mail client on this. Please take care for your time.
--
frenzy
-o--=O`C
#oo'L O
<___=E M
-
Bullshit.
We expect a C compiler, and if a C compiler violates the C standard
that's a bug in the compiler that has to be fixed.
Open your eyes and you'll find thread overviews at the left side of
the URLs he gave...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
If you are serious, please consider last kernel headers vs ANSI C discussion, then GNU extensions of the GCC C compiler and relevant "if ICC doesn't support GCC extensions it's ICC's bug". That was about implementation. About standards you are not serious, aren't you? (Please don't see this as for this particular case, but as general Where's constructive context and support of yet another patch author, ____ -
If only Joerg would tell us where the problem exactly is...
There might be a bug in the kernel header, but this simply has to be
gcc is a C compiler and claims to follow the C standard.
The kernel does not claim to be compilable by a plain C compiler.
The comments are in the _threads_.
The patches are only the roots of the threads.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
> gcc is a C compiler and claims to follow the C standard. Not with the options the kernel build uses. But, close enough -- the differences are really minor stuff. Segher -
here is the objdump output of the two object files: As you could see, the older one used 0x38 bytes stack space while the new one used 0x28 bytes, and the object code is two bytes less, I think all these benefits are the gcc's __builtin_memset optimization than the explicit call to memset. $ objdump -d /tmp/init.orig.o|grep -A23 -nw '<paging_init>' 525:0000000000000395 <paging_init>: 526- 395: 48 83 ec 38 sub $0x38,%rsp 527- 399: 48 8d 54 24 10 lea 0x10(%rsp),%rdx 528- 39e: fc cld 529- 39f: 31 c0 xor %eax,%eax 530- 3a1: 48 89 d7 mov %rdx,%rdi 531- 3a4: ab stos %eax,%es:(%rdi) 532- 3a5: ab stos %eax,%es:(%rdi) 533- 3a6: ab stos %eax,%es:(%rdi) 534- 3a7: ab stos %eax,%es:(%rdi) 535- 3a8: ab stos %eax,%es:(%rdi) 536- 3a9: 48 89 7c 24 08 mov %rdi,0x8(%rsp) 537- 3ae: ab stos %eax,%es:(%rdi) 538- 3af: 48 c7 44 24 10 00 10 movq $0x1000,0x10(%rsp) 539- 3b6: 00 00 540- 3b8: 48 c7 44 24 18 00 00 movq $0x100000,0x18(%rsp) 541- 3bf: 10 00 542- 3c1: 48 8b 05 00 00 00 00 mov 0(%rip),%rax # 3c8 <paging_init+0x33> 543- 3c8: 48 89 44 24 20 mov %rax,0x20(%rsp) 544- 3cd: 48 89 d7 mov %rdx,%rdi 545- 3d0: e8 00 00 00 00 callq 3d5 <paging_init+0x40> 546- 3d5: 48 83 c4 38 add $0x38,%rsp 547- 3d9: c3 retq 548- $ objdump -d /tmp/init.new.o|grep -A23 -nw '<paging_init>' 525:0000000000000395 <paging_init>: 526- 395: 48 83 ec 28 sub $0x28,%rsp 527- 399: 48 89 e7 mov %rsp,%rdi 528- 39c: fc cld 529- 39d: 31 c0 xor %eax,%eax 530- 39f: ab ...
... or from complex memset() implementation (some chips even didn't do
`rep' fast enough somehow). Maybe code like below will be acceptable for
both optimizers and maintainers?
|-*-
unsigned long max_zone_pfns[MAX_NR_ZONES] = {
[ZONE_DMA] = MAX_DMA_PFN,
[ZONE_DMA32] = MAX_DMA32_PFN,
[ZONE_NORMAL] = end_pfn,
[ZONE_MOVABLE] = 0UL
};
Yes, comments and discussion is most important thing. But with such
That was a side note.
____
-
we should just alias our memset to the __builtin one, and then provide a generic one from lib/ for the cases gcc needs to do a fallback. -
In x86_64 there's infrastructure to check and select right memset(). Therefor it's need, i think. But if one will took a look at usage, zero memset() optimization becomes obvious, one argument off -- one reg is free from clobbering. |-*- flower-:22-rc4-mm2/arch/x86_64$ grep memset -R . | grep "[ 0,]0," | wc -l 42 flower-:22-rc4-mm2/arch/x86_64$ flower-:22-rc4-mm2/arch/x86_64$ cd .. flower-:22-rc4-mm2/arch$ grep memset -R . | grep "[ 0,]0," | wc -l 735 flower-:22-rc4-mm2/arch$ flower-:22-rc4-mm2$ grep memset -R . | grep "[ 0,]0," | wc -l 6679 flower-:22-rc4-mm2$ |-*- ____ -
The last time I checked, gcc generated horrible badly performing code for builtin memset/memcpy() when -Os is specified. -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: <zyntrop@kvack.org>. -
if you care about the last cycle, don't specify -Os but -O2. simple as that... you get what you tell the compiler you want. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
Certain distros are shipping kernels compiled with -Os. And it's more than just a couple of cycles. -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: <zyntrop@kvack.org>. -
so those distros pick space over some cycles. Who are you to then override that choice ? ;-) seriously, why are we even talking about overriding a choice the user (or distro vendor as user) made here? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
There is a real issue in the fact that compiling with -Os is available
through a kconfig option and AFAIR used by some distributions.
I doubt distros enable CONFIG_CC_OPTIMIZE_FOR_SIZE due to size
considerations, but due to speed considerations.
I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
CONFIG_EMBEDDED, but as long as it's available as a general purpose
option we have to consider it's performance.
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I think you are missing the point. You tell the kernel to OPTIMIZE_FOR_SIZE. *over performance*. Sure. Performance shouldn't be EXTREMELY pathetic, but it's not; and if it were, it's a problem with the gcc version you have (and if you are a distro, you can surely fix on a system level, size can help performance because you have more memory available for other things. It also reduces download size and gives you more space on the live CD.... if you want to make things bigger again, please do this OUTSIDE the "optimize for size" option. Because that TELLS you to go for size. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
then do we need a new option 'optimize for best overall performance' that goes for size (and the corresponding wins there) most of the time, but is ignored where it makes a huge difference? I started useing Os several years ago, even when it was hidden in the embedded menu becouse in many cases the smaller binary ended up being faster. in reality this was a flaw in gcc that on modern CPU's with the larger difference between CPU speed and memory speed it still preferred to unroll loops (eating more memory and blowing out the cpu cache) when it shouldn't have. if that has been fixed on later versions of gcc this would be a good thing. if it hasn't (possibly in part due to gcc optimizations being designed to be cross platform) then either the current 'go for size' or a hybrid 'performance' option is needed. David Lang -
that isn't so easy. Anything which doesn't have a performance tradeoff is in -O2 already. So every single thing in -Os costs you performance on a micro level. The translation to macro level depends greatly on how things are used (you even have to factor in download times etc)... so that is a fair question to leave up to the user... which is what there is today. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
this has not been true in the past (assuming that it's true today) ok, if you look at a micro-enough level this may be true, but completely ignoring things like download times, the optimizations almost always boil down to trying to avoid jumps, loops, and decision logic at the expense of space. however recent cpu's are significantly better as handling jumps and loops, and the cost of cache misses is significantly worse. is the list of what's included in -O2 vs -Os different for different CPU's? what about within a single family of processors? (even in the x86 family the costs of jumps, loops, and cache misses varies drasticly) ignore things like download time for the moment. it's not significant to most people as they don't download things that often, and when they do they are almost always downloading lots of stuff they don't need (drivers for example) users are trying to get better performance 90+% of the time when they select -Os. That's why it got moved out of CONFIG_EMBEDDED. David Lang -
At least not in the example Duron/Athlon case. Both -march=athlon{,-4) but
64K versus 256K L2 which I'd expect to be an important difference in the -Os
versus -O2 behaviour.
Rene.
-
In my experience, -Os produced faster code on gcc-2.95 than -O2 or -O3. It was not only because of cache considerations, but because gcc used different tricks to avoid poor optimizations, and at the end, the CPU ended executing the alternative code faster. With gcc-3.3, -Os show roughly the same performance as -O2 for me on various programs. However, with gcc-3.4, I noticed a slow down with -Os. And with gcc-4, using -Os optimizes only for size, even if the output code is slow as hell. I've had programs whose speed dropped by 70% using -Os on gcc-4. But their size was smaller than with older versions. But in some situtations, it's desirable to have the smallest possible kernel whatever its performance. This goes for installation CDs for instance. Willy -
> In my experience, -Os produced faster code on gcc-2.95 than -O2 or -O3. On what CPU? The effect of different optimisations varies -Os is "as fast as you can without bloating the code size", so that is the expected result for CPUs that don't need There are much better ways to achieve that. Segher -
this sounds like you are saying that people wanting performance should pick -Os. what should people pick who care more about code size then anything else? (examples being embedded development where you may be willing to sacrafice speed to avoid having to add additional chips to the design) David Lang -
That is true on most CPUs. Some CPUs really really need some of things that -Os disables (compared to -O2) for -Os and tune some options. There is extensive work being done over the last few years to make GCC more suitable for embedded targets btw. But the -O1/-O2/-O3/-Os gives you four choices only, it's really not so hard to understand I hope that for more specific goals you need to add more specific options? Segher -
No, -Os is for size only :
-Os Optimize for size. -Os enables all -O2 optimizations
that do not typically increase code size. It also
performs further optimizations designed to reduce code
size.
So it is expected that speed can be reduced using -Os. I won't report
Optimizing is not a matter of choosing *one* way, but cumulating
everything you have. For instance, on a smart boot loader, I have
a kernel which is about 300 kB, or 700 kB with the initramfs. Among
the tricks I used :
- -Os
- -march=i386
- align everything to 0
- replace gzip with p7zip
Even if each of them reduces overall size by 5%, the net result is
0.95^4 = 0.81 = 19% gain, for the same set of features. This is
something to consider.
Regards,
Willy
-
That's not a CPU, that's an architecture. I hope you understand there are very big differences between different members of the x86 family and you don't compare 2.95 on a Pentium class CPU to 3.x on an Opteron or 4.x on a Pentium4 That is not "for size only". Please read again. A 70% speed decrease is something that should be at least investigated, even if then perhaps it is decided GCC already A few percent points slower is expected, 20% would be explainable, but 70%? -O2 and -Os are supposed to differ in _minor_ ways. Such a huge performance drop is unexpected. If you file the PR, Yes of course. I'm just saying -Os is a pretty minor step in the overall making-things-smaller game. Leaving out XFS Sure. I don't think making -Os mean "as small as possible in all cases" (or, rather, introducing a new option for that) would help terribly much over the current -Os meaning -- a few percent at most. That's not to say that no such optimisations are added anymore, but mostly they turn out not to decrease speed at all and so are enabled at any -O level :-) Segher -
That's -Os mostly. Some awful CPUs really need higher loop/label/function alignment though to get any You told it to unroll loops, so it did. No flaw. If you feel the optimisations enabled by -O2 should depend on the CPU tuning selected, please file a PR. Also note that whether or not it is profitable to unroll a particular loop depends largely on how "hot" that loop is, and GCC doesn't know much about that if you don't feed it profiling information (it can guess a bit, sure, but it can guess wrong too). Segher -
actually, what you are saying is that the compiler can't know enough to figure out how to optimize for speed. it will just do what you tell it to, either unroll loops or not. this argues that both O2 and Os are incorrect for a project to use and instead the project needs to make it's own decisions on this. if this is the true feeling of the gcc team I'm very disappointed, it feels like a huge step backwards. David Lang -
It bases its optimisation decisions on the options you give it, the profile feedback information you either or not gave For optimal performance, you need to fine-tune options yes, I speak only for myself. However this is the only way it _can_ be, the compiler isn't clairvoyant. Some of the heuristics sure could use some tuning, but they stay heuristics. Segher -
My point is commit c45b4f1f1e149c023762ac4be166ead1818cefef
CC_OPTIMIZE_FOR_SIZE is currently known as an experimental feature to
For a given gcc version, there's a finite number of differences between
-Os and -O2.
The interesting question is for which differences with gcc 4.2 we want
the -Os version in the kernel for best performance. This should then be
That's a different point.
If you don't care about performance but care about size then -Os is
Agreed, but CONFIG_CC_OPTIMIZE_FOR_SIZE should again be under
CONFIG_EMBEDDED.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I would wager that the CPU type makes more of a difference than the compiler version. That is, I'd expect my Duron with it's "puny" 64K L1 to have a very different profile than it's Athlon brother with 256K L1. Not to mention CPUs with as little as 8K L1 (P1). I can't quote numbers -- it's a bit hard to test those things anyway as it's a system-global effect and not su much that's easily isolated in a dedicated benchmark. Rene. -
Sorry, that should've been L2. And "its" ... And while I'm at it, "and not so much one that's [ ...]". Rene. -
Smaller code can mean fewer page faults, fewer cache invalidations, etc. It's not just a matter of compiler code generation, gotta look at the whole picture. Jeff -
Sure, but my point is that if the kernel is considered special and the
best optimization for the kernel is therefore between -Os and -O2, we
should try to find this point of best optimization.
This should address Arjans point that -Os might not be best choice for
best performance (and it's actually our fault if gcc generates stupid
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
the picture gets even murkier when you consider that even if neither option overflows the cpu cache the one that takes more space in the cache leaves less space in the cache for the userspacde code that the system is what can be done to find the horribly bad but small code among the "it's smaller and would be less efficiant if you didn't consider the cache" majority? David Lang -
