This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: i386 inline-asm string functions - some questions
On Mon, Dec 29, 2003 at 11:09:14AM -0800, Zack Weinberg wrote:
> Denis Zaitsev <zzz@anda.ru> writes:
>
> > On Mon, Dec 29, 2003 at 12:31:52AM -0500, Daniel Jacobowitz wrote:
> >> Funny, I conducted this experiment last week and found quite the
> >> opposite. Compiling the demangler and a smallish yacc parser
> >> with -D__NO_STRING_INLINES cost about 20% in runtime.
> >
> > -D__NO_STRING_INLINES just puts the inlining off. But nobody here
> > tells about the inline/noinline comparing. Of course, inlining is
> > better at speed. The comparison is doing between some versions of the
> > inlining.
>
> No. There is no "of course" here.
Strictly speaking, you are right. But in general, in the real life in
average etc., when strings are too short the effects you are
describing below to appear etc. etc., my "of course" is near enough to
the truth.
> If your inlined functions blow out the instruction cache, it may
> wind up being a net lose.
Definitely. This is why I don't like when the inline functions are
growing, putting the effects of "m" down...
> Same if the out-of-line memcpy takes several more instructions to
> set up but makes damn sure to do aligned memory accesses
> (full-bus-width loads, nontemporal store, prefetches, etc etc etc),
> whereas the inline one doesn't.
First, they are trying to do so here and there (but ok, not fine).
Second, I have experimented with this nonaligned access some time
ago. I don't remember exactly, but it seems that the modern x86
processors do the job as fine as when the memory access is aligned.
But as it was too far ago, I can't recollect the details and so I
won't insist. Better I will repeat the measurements...