Daniel Berlin wrote:
>>> 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. :)
Yep, but in general its a good idea to stay away from prefetches because
they are very small improvements next to algorithmic changes. In this
case, supporting non-txdelta transfers over LAN or local connections
would make a far bigger difference than trying to improve vdelta's
performance. Improving vdelta would still be useful for other cases,
but I'm not sure that vdelta is even the limiting factor in those cases.
Inaccurate realtime - http://subversion.kicks-ass.org/issue1429/vdelta.txt
Accurate theorhetical -
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Aug 19 09:01:54 2003