On Tue, 2020-05-26 at 14:14 -0400, Mike Gilbert wrote: [...] > > > > > Assuming that the pic performance penalty is really only relevant > > on > > legacy arches (like x86), here are a couple of options: > > > > 1. Disable pic on arches where tie performance penalty is small. > > 2. Force pic everywhere, performance be damned. > > Option 1 should say "Disable pic on arches where the performance > penalty is large."
Performance penalty is not really a matter of arch. Of course -fPIC from C/C++ code has a small performance impact on x86 (bigger than on amd64), but the gain is worth it. Here it is a matter of hand written assembly that is not relocatable. The performance impact thus depends on the gain of said assembly, which in the case of multimedia apps/libs is huge because that's usually about vectorizing inner loops bodys (somewhere between x4 or x8 speedups is not unusual for the part in question). That's why the policy has always been to have PIC everywhere with exceptions/workarounds tied to the pic useflag, giving users and profiles the choice. Again, the real fix is to rewrite the assembly in a PIC way, or at least have ifdefs to allow it, but that is hard. Packages that have the option to have PIC or slightly faster non-PIC assembly do/should not have a pic useflag and always use the PIC variant.
