The future of i486 arch in Th

[Tomasz Pala]

OK, trochę więcej dot. tematu. Sprawdziłem sobie na takim xz i zysku nie
zaobserwowałem (jedyny przyrost wydajności daje -O3), ale wydaje mi się
to całkiem logiczne. Znacznie mniej logiczne, że -march=native daje mi
gorszy wynik, niż i686... Wyszukałem, że openssl ma detekcję runtime.
Jest libjpeg-turbo jako osobny pakiet. Nie mamy połatanego zliba:

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/zlib-compression-whitepaper-copy.pdf

co wiedziałem już dawno temu, natomiast nie wiedziałem, że OpenSuSE
sobie wciągnęło:

http://lists.opensuse.org/opensuse-factory/2011-03/msg00537.html

i to akurat warto byłoby mieć, chociażby na takiej samej zasadzie, jak libjpeg-turbo (odrębny pakiet):

https://www.snellman.net/blog/archive/2014-08-04-comparison-of-intel-and-cloudflare-zlib-patches.html

ALE...

https://software.intel.com/en-us/articles/memcpy-performance

i jak na życzenie, proszę:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8b4416d83c79ba77b0669203741c712880a09ae4

Pytanie zatem brzmi: czy glibc ma detekcję runtime? Sądząc po takich
commitach:

https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/x86/fpu/bits/mathinline.h;h=ee88b66050ab2c212bf61a42bbb7001b63328dd4;hp=9c32e9503b81bc409db40b2dcc1161f2f31c3284;hb=508ce3acd95e0782bc81e1f1eb84c43fa6978cfc;hpb=b4acef1ffe2e1ba6c608f31c1954a8100d3eabb0

to nie ma. Zresztą grep __SSE na źródłach to potwierdza (albo nie umiem
tego poprawnie odczytać).

$ ls **/*86/**/*sse2.* | wc -l
46

pokazuje skalę strat - to są funkcje używane przez wszystko w systemie.
Czyli -mfpmath=sse to przede wszystkim konkretne zmiany na poziomie glibca,
nie tyle wygenerowane przez gcc, jak pisałem poprzednio (co skuteczność ma
najwyraźniej taką sobie), ale ręcznie wyrzeźbione (sporo tego w changelogu).

Zatem jeżeli nie zapadnie decyzja o podniesieniu wymagań naszego i686,
to przynajmniej trzeba by zrobić zlib-sse oraz glibc-sse.

Tylko tak - samo -msse2 na IA-32 nie przełącza FPU na SSE, trzeba dodać
fpmath, zacząłem się więc zastanawiać dlaczego. Dwa potencjalne powody:
1. SSE bywa wolniejsze (ale już na AMD64 jest domyślnie używane, więc
   jeżeli, to na jakichś starych CPU),
2. ryzyko związane ze zmianą precyzji x87 - przy zmianie architektury na
   AMD64 można to było pominąć, aplikacje i tak wymagały testowania.

Podsumowując:
1. nie ryzykowałbym -mfpmath=sse dla całego systemu, gra nie warta
   chyba świeczki, za wyjątkiem dodatkowej wersji glibc-sse2 do wyboru,
2. włączyłbym -msse2 - jeżeli gcc nic samo nie wygeneruje, to paczka
   będzie kompatybilna wstecz, a jeżeli wygeneruje, znaczy że jest
   potencjalny zysk i użytkownik starego systemu ma pecha,
3. aplikacjom z kodem optymalizowanym pod SSE, ale bez detekcji runtime,
   pozwoliłbym na korzystanie z SSE2, bo w tych przypadkach zysk będzie
   znaczący (np. to co pisał Jeff).

Podobny temat w Ubuntu parę miesięcy temu:

https://lists.ubuntu.com/archives/ubuntu-devel/2014-March/038134.html

On Wed, Dec 31, 2014 at 20:21:55 +0100, Tomasz Pala wrote:

>> Np. benchmarki kilku
>> procesorożernych aplikacji, czy coś, pozwoliłyby świadomie podjąć
>> sensowną decyzję.

http://arctic.org/~dean/crypto/sha1.html

-- 
Tomasz Pala <gotar w pld-linux.org>