This is the mail archive of the libc-alpha@sourceware.org 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]

Re: [PATCH] Faster strlen


> > I have doubts that table lookups are a good idea if it blows away
> > the working set in L1 for the application.
> It does not have this problem. It does lookup only for powers of 2 which 
> fits 11 cache lines.

11 cache lines is a lot of L1 cache.

It also depends on the layout, often L1s have a low associativity,
so you're more likely to throw out valuable application data

> 
> However it has problem that atom L2 cache has slow latency. When I
> add access 8 random reads between calls then performance becomes
> same as pminub. 

But pminub has the advantage that it doesn't force out the cache lines
of the application. It may well win in the real world.

Testing icache (running some large dummy code in the tester) would be
also good.

-Andi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]