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