On Tue, 19 Aug 2003, Brandon Ehle wrote:
> 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.
Yeah, but you aren't going to really improve the algorithm here.
:)
So you either not use it, or speed up what you've got.
> 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.
IE not use it :)
Improving vdelta would still be useful for other cases,
> but I'm not sure that vdelta is even the limiting factor in those cases.
>
IE speed up what you got (if it's really the slow point).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 20 07:37:13 2003