On Tue, Jan 24, 2012 at 09:11, Reinhard Tartler <siret...@tauware.de> wrote: > On Di, Jan 24, 2012 at 11:04:00 (CET), Fabian Greffrath wrote: > >> Am 23.01.2012 14:53, schrieb Reinhard Tartler: >>> The reason is that x264 uses a lot of hand written assembler, and >>> upstream takes care to use non-pic code only on architectures that >>> support this. >>> >>> Btw, the same applies to the libav* packages. >> >> Is there any benchmark available (for either package) that compares the >> performance of the library using the hand written assambler code with >> one using generic code? > > Have a look at upstream commit logs. Many commit messages count cpu > cycles as performance speedup. > > http://git.videolan.org/?p=x264.git;a=commitdiff;h=748fe16c1303b89d2a1d0378addd83fb4198f51a > http://git.videolan.org/?p=x264.git;a=commitdiff;h=6b06f6d3f7f800dca1a4ea154f54427d5b3cea2b > > no name only some very recent ones.
Not that I'm an expert on this subject (and I haven't looked at the code), but it is my understanding that cpu cycles is not the only relevant measure of speed. Branching and the guessing the cpu does to follow branches can be very relevant too. Code compactness is also important due to cache hits/misses. So I think the only way to tell if an optimization really is beneficial is via benchmarking. -- Saludos, Felipe Sateler _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
