On Sun, Jun 24, 2007 at 08:58:10PM +0800, rae l wrote: > On 6/23/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > >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? > 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,
Actually more: $((0x3d9 - 0x3ce)) > I think all these benefits are the gcc's __builtin_memset optimization > than the explicit call to memset. ... 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 }; |-*- > $ objdump -d /tmp/init.orig.o|grep -A23 -nw '<paging_init>' [] > 547- 3d9: c3 retq [] > 545- 3ce: c3 retq [] > > > >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. > with '{}' initializer, gcc will fill its memory with zeros. > > to other potential points to be optimized, I only see this trivial as > the first point, I wonder how people gives comments on this; and if > this optimization can be tested correctly, this can be done as an > optimization example and I'll try others. Yes, comments and discussion is most important thing. But with such propositions you will be better in the kernel-janitors list. > > > >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. > Thank you, I know it and I've already subscribed the linux kernel > mailing list(linux-kernel@vger.kernel.org) so that I won't miss any > further discussion about it. OK, but news<=>e-mail service, like Gmane is much nicer. > > > >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. > What about that? > Do you mean something such as git by "an automatic system"? That was a side note. ____ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/