Bug#657019: Please document why the package includes non-PIC code

[Reinhard Tartler]

On Di, Jan 24, 2012 at 16:09:01 (CET), Felipe Sateler wrote:

> On Tue, Jan 24, 2012 at 09:11, Reinhard Tartler <siretart at 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.

You're right. My point is that x264 upstream is very well at micro
optimizing the assembly and does a lot of both micro-benchmarks as well
as encoding benchmarks on a regular basis.

Please also note that just removing -fPIC from the makefiles will lead
to compilation failures on i386 because of register shortage. You would
then to additionally need to pass --disable-optimizations to the
configure script. And now things will become really dogslow.

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4