Dag-Erling Smørgrav writes:
> Mike Haertel writes:
> > For example if your regex is /foo.*bar/, the initial Boyer-Moore search
> > is (probably) searching for foo.
> >
> > If the initial search succeeds, GNU grep isolates the containing line,
> > and then runs th
Dag-Erling Sm�rgrav writes:
> Mike Haertel writes:
> > GNU grep uses the well-known Boyer-Moore algorithm, which looks
> > first for the final letter of the target string, and uses a lookup
> > table to tell it how far ahead it can skip in the input whenever
> > it fin
Hi Gabor,
I am the original author of GNU grep. I am also a FreeBSD user,
although I live on -stable (and older) and rarely pay attention
to -current.
However, while searching the -current mailing list for an unrelated
reason, I stumbled across some flamage regarding BSD grep vs GNU grep
perform
>This is a fairly key statement in context, and an opinion here would
>count for a lot; are function calls likely to become more or less
>expensive in time?
Ambiguous question.
First answer: Assume we're hitting the cache, taking no branch
mispredicts, and everything is generally going at "the
>Second answer: in the real world, we're nearly always hitting the
>cache on stack operations associated with calls and argument passing,
>but not less often on operations in the procedure body. So, in
^^^ typo
Urk. I meant to say "less often", delete the "not".
To Unsubscribe: send mail
You might think that, due to MESI state bits in the cache and bus
coherency protocols, that locks are "free".
Unfortunately, the lock prefix has a measurable cost on a UP system,
at least on P6 and later processors. The reason is that the locked
memory operation is an "at-retirement" operation,
>On Sat, 10 Jul 1999, Matthew Dillon wrote:
>>
>> The supposedly atomic functions in i386/include/atomic.h are not
>> as atomic as was previously thought :-):
>>
>> #define atomic_add_short(P, V) (*(u_short*)(P) += (V))
>[...]
>
>Before I fixed this stuff for the alpha, the += e
