On 2014-02-05 15:00:57 +0100, Christophe Gisquet wrote:
> Hi,
> 
> 2014-02-05 Martin Storsjö <mar...@martin.st>:
> > Based on a patch by Ronald S. Bultje.
> > ---
> > Updated as suggested by Janne, to not require pushing anything to
> > the stack.
> 
> That's not really an issue worthy of additional work, but with such
> patches, it may be interesting to know the impact of the fix
> speed-wise.

the penalty of the fix is not huge but it's meaningless. It doesn't make
sense to benchmark incorrect code. I can i"solve" every problem in a
small and constant amount of time incorrectly.

> For instance, this second patch looks like the right thing to do. But
> besides that, is there an actual/objective reason, e.g. number of
> cycles? (I guess they can vary significantly depending on
> architecture, cache/memory speed etc, but still...).

Number of cpu cycles/overall run time, and while those indeed vary for
different CPU the relative difference between two patches on the same
CPU differs not that much across systems.

Janne
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to