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 <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
