[XviD-devel] SAD cache

[skal]

	Radek,

On Tue, 2003-03-11 at 13:47, Radek Czyz wrote:
> Hi,
> 
> > If it's 10-20% of _all_ checks, that's okay, because we check up to 8
> > predictors or so, many of them will coincide. We could only call SAD-cache
> > for predictor check and don't use a hash during diamond phase.
> 
> I just checked it myself. My procedure remembers the pointer of
> reference picture which is being sad-ed, so it even intercepts a
> double-check made between two macroblocks. The cache is reset only at
> new picture.
> 
> It's not so bad after all.
> For advdiamond/diamond and no extsearch, where make_mask() prevents a
> double check even if a predictor is in range of initial diamond,
> there is little multiple checks - average 2.7% of all (with standard
> deviation +/-3.1 so it's not always so nice. There is 22% in one
> picture...)
> 
> For motion precision 6, with square and extsearch, it becomes a bit
> worse: (11.0 +/- 3.7)% .
> Not very bad still, especially when we remember that it's almost
> impossible to prevent them without extra cache.
> 
> Any comments?

	...then it might not be worth using the cache, except if these
	~11% (at worst) calls to sad16 (or hadamard()!) is far slower
	than the overall queries to the cache...

	bye,
		Skal