This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
So the additional overhead (at least 9 cycles with the NULL pointer check) does matter. In the new memcmp I can compare 8 bytes per cycle (8 x 9 == 72 bytes) so this overhead is significant.
You ignore completely real-world issues like loading the cache. Sure, in your synthesized test cases you might see effects for very short strings or memory blocks. But these are not that important. Once you work with bigger data sets they don't fit in the caches and then a single miss costs you so much more.
So, get this all set up as not only I proposed, then do some measurements. If it should turn out to be a real issue in real life, we can think about some way to fix it. That way in no case must involve writing to the vdso or exposing it directly to user code. prelink, for instance, would be at least hampered in its work. If no function in the vdso needs to reference any PC relative data and we can get by with a simple asm call, there are some quite dirty ways to avoid the extra indirection, but I'm not willing to discuss any of this until the simple solution is implemented, tested, and profiled first.
And anyway, if you think this work should really be your highest priority as PPC maintainer, you're wrong. There is a *MUCH* more important issue waiting to be fixed. If you don't know what I mean, contact me directly.
-- â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |