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. |