>>>
>> I'm not exactly sure what you are trying to say here. But I believe
>> if we want vdelta to become a very fast operation that it needs to try
>> and fit its hash table and buffers into the L1 cache. On current
>> CPU's, we can probably expect that cache size to be 128KB, but if we
>> want to support older CPU's in the 500MHZ-2000MHZ, we probably need to
>> be able to fit all of that into 64KB of memory.
>
> Hm, I don't know where I got the megabyte sizes ... but you're right.
> However, this would mean drastically reducing the vdelta window size,
> which would really hurt both network performance and repository size.
> Unfortunately, the algorithm itself is such that locality of data
> references can't be improved.
True, but that's not the only way to avoid the cache misses.
You could also prefetch the data.
There are several obvious prefetch points you could use in the
algorithm (for instance, prefetch the data the next slot in the bucket
will attempt to match against).
gcc 3.1+ has a builtin_prefetch you can use (it is a NOP on targets not
supporting prefetch), and we already configure detect GCC, right?.
Do we have an annotated listing of what lines in vdelta are reponsible
for the misses somewhere?
Since i am spending my non-lawschool time right now writing high level
loop optimizations for gcc for IBM, i theoretically should be able to
improve the code to run faster. :)
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 22 05:55:09 2003