Position Independent Code

[Ranguvar]

I've noticed that a lot of Linux distros are using --enable-pic in their configuration of x264. Is this necessary for dynamic libraries? I saw the comment in the x264 changelog that it was necessary for those under Mac OS X Intel, but what about x86* Linux? And if it is necessary, would compiling the executable and the libraries separate, the former without PIC, provide any remotely noticeable speed gain?

Thanks.

[cacepi]

I've noticed that a lot of Linux distros are using --enable-pic in their configuration of x264. Is this necessary for dynamic libraries?
I'm not a Linux expert, but the reason you're seeing --enable-pic used is not so much for dynamic libraries, but more due to secure Linux features like PaX and Exec Shield, which use position independent executables. You'd probably see _some_ difference in encode speed, but how much I really can't say.

[Dark Shikari]

I'm not a Linux expert, but the reason you're seeing --enable-pic used is not so much for dynamic libraries, but more due to secure Linux features like PaX and Exec Shield, which use position independent executables. You'd probably see _some_ difference in encode speed, but how much I really can't say.Back when x264 supported PIC32, the speed loss was ~4%. The speed loss with PIC64 is ~1%.

[akupenguin]

x264 still supports --enable-pic on x86_32, it just doesn't produce pic asm. This of course makes the option useless.
In a test from a year ago, I found: pic32 cost 3%, pic64 cost 1%.
A similar test now found: pic32 cost 5%, pic64 cost 0.5%.
Dunno if the difference is due to changes in x264, or different settings, or different cpu, or what.

[Dark Shikari]

x264 still supports --enable-pic on x86_32, it just doesn't produce pic asm. This of course makes the option useless.
In a test from a year ago, I found: pic32 cost 3%, pic64 cost 1%.
A similar test now found: pic32 cost 5%, pic64 cost 0.5%.
Dunno if the difference is due to changes in x264, or different settings, or different cpu, or what.How did you measure PIC32 when x264 doesn't actually support it in asm? Or did you just use the last version that did?

[akupenguin]

Just configure --enable-pic, which generates pic c and nonpic asm. The real speed cost should then be >5%.

[Dark Shikari]

Just configure --enable-pic, which generates pic c and nonpic asm. The real speed cost should then be >5%.Well isn't that really not an accurate test, as PIC probably has a different effect on the C code than asm code?

[akupenguin]

Well, if you're interested in the effects on x264's speed, then measuring x264 is the most accurate test, even if it doesn't tell you how much pic sucks in other apps...