[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: required memchr behavior

From: Eric Blake
Subject: Re: required memchr behavior
Date: Fri, 29 May 2009 17:45:33 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090302 Thunderbird/ Mnenhy/

Hash: SHA1

According to Matthew Woehlke on 5/29/2009 4:59 PM:
>>> Implementations shall behave as if they read the memory byte by byte
>>> from the beginning of the bytes pointed to by s and stop at the first
>>> occurrence of c.
> Doesn't that preclude *any* sort of optimization? Or is it always safe
> to read up to the end of a word boundary?

The as-if rule is very powerful.  For example, this wording explicitly
permits the x86_64 implementation that Ulrich checked into glibc on May 21
(commit fa64b7f), where the assembly code uses speculative preloads of
cache lines at a time, reading many bytes in advance of the memory
actually belonging to the pointer, since a failed speculative load across
a page boundary is still safe if a match is later found up front.

And if others agree with me that we need to provide a gnulib memchr
replacement for installations that are using a glibc version that predates
last week (and thus causes problems with higher level algorithms such as
strstr), the replacement will be C code that scans an aligned word at a
time, similar to how it is already done in memchr2.c.  Not quite as
efficient as hand-tuned assembly, but hands down faster than a byte at a time.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]