[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion performance (issue #1429 et al)

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2003-08-20 07:35:55 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.