The future of i486 arch in Th

[Tomasz Pala]

On Wed, Dec 31, 2014 at 12:52:56 +0100, Jacek Konieczny wrote:

> Historia komputeryzacji i stan obecny opisałeś ładnie, a jesteś w stanie
> rzucić konkretami? Co na włączeniu SSE zyskamy?

Teoretycznie: dodatkowe rejestry XMM (żałosnej liczby rejestrów IA-32
nie trzeba chyba wyjaśniać).
Ufając np. Intelowi:
https://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints

It uses SSE floating point model by default. In other cases you should
specify "-mfpmath=sse" to improve floating pont performance.

<strong>Adding "-mfpmath=sse" is important in 32 bits mode!</strong>

- 4-5% wydajności dzięki SSE (nie SSE2).

SSE wykorzystuje x264:
https://mailman.videolan.org/pipermail/x264-devel/2009-August/006224.html

czytam komentarze typu (pod koniec):
https://www.google-melange.com/gsoc/project/details/google/gsoc2011/mpopoloski/5668600916475904

No i wreszcie ta stała 80-bitowa precyzja x87.

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

Nic pod ręką nie mam, nie dziś;)

> IMHO nie ma sensu porzucać kompatybilności nawet z antykami, jeżeli
> dzięki temu zyskamy 1% wydajności w 5% zastosowań. To byłoby wypięcie
> się na niektórych (owszem, pojedynczych) użytkowników w pogoni za
> numerkami.

Pentium Pro? Nie wierzę, że ktoś takich maszyn używa _aktualizując_
oprogramowanie. Sam kiedyś żałowałem porzucenia i586 i athlon, ale od tamtego
czasu nawet raz nie uruchomiłem komputerów używających tego. Przypomnę:
SSE ma już 15 lat, na tak starych maszynach nie sądzę, by dało się
korzystać ze współczesnego firefoxa.

A podążając za taką argumentacją - dlaczego w takim razie i686 a nie
i586 czy wręcz jeszcze niższe? Było coś rewolucyjnego, co znacząco
podniosło wydajność i686 względem i586? Jak dobrze pamiętam tamte czasy,
to rewolucją był MMX i 3D Now! - z przeznaczeniem pod multimedia. Zatem
bez SIMD jesteśmy w epoce premultimedialnej.

> I czy nie jest tak, że w zastosowaniach, w których ma to największe
> znaczenie, detekcja i wykorzystanie specjalnych funkcji procesorów jest
> załatwiane ???on runtime???? Przynajmniej kiedyś tak ze wszelkimi codekami
> było.

Tak miał mplayer, jest to w różnych cruncherach, jest libjpeg-turbo, ale
poza tym - szczerze wątpię, pisanie wstawek w asemblerze to ciężki
kawałek chleba, żaden libpng czy zlib strzelam, że tego nie ma. Istotne
jest, że umie te instrukcje wygenerować gcc, bez SIMD nie ma ani tych
rejestrów, ani _żadnych_ instrukcji wektorowych, więc wyłączamy sporo
potencjalnych optymalizacji - konkrety mam tylko dla -ftree-vectorize:

http://www.haifa.il.ibm.com/Workshops/compiler2004/papers/autovectorizationGCC.pdf

Pixel Blending Application
   - small dataset: 16x improvement
   - tiled large dataset: 7x improvement
   - large dataset with display: 3x improvement

SPEC gzip ­ 9% improvement

To są potencjalne zyski, które wyrzucamy. Może i da to realnie 1%, ale
wierzę, że wypniemy się w ten sposób na =0% użytkowników.

Do przemyślenia na 2015:)

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