Subject:
RE: [st-pti] Architektura & Organizacja
From:
"Tomasz Klasa" ####@####.####
Date:
7 Dec 2017 19:39:34 +0000
Message-Id: <006a01d36f93$635d4950$2a17dbf0$@o2.pl>
Marcin, zakładając, że kompilator będzie miał informacje o sposobie działania algorytmów wypełniania cache (a nie tylko o jego rozmiarze) w różnych generacjach CPU, to pewnie, że zrobi. Tylko to oznacza, że po premierze każdej nowej generacji CPU w dzisiejszych czasach trzeba by zaktualizować kompilator, a najlepiej przekompilować programy. To nie ten kierunek.
Kompilator operuje na warstwie architektury i tylko do tego poziomu może robić optymalizację. Może użyć dodatkowych rejestrów czy rozkazów. Nie może robić optymalizacji pod cache procesora, skoro nie wie czy np. wyższy poziom zawiera to samo co niższy, czy nie. Podsystem cache został właśnie diametralnie zmieniony w Intel Coffe Lake. Był też (choć mniej) zmieniany przy przejściu np. z sandy Bridge na Ivy Bridge. Zobacz jakie zmiany w tym zakresie zrobiło AMD przechodząc z Excavatora na Zen.
Czym innym jest dobieranie kolejności rozkazów tak, żeby jak najlepiej wykorzystać dostępne rejestry (ograniczyć operacje WE/WY), a czym innym jest optymalizowanie pod kątem tego, co siedzi w cache w danej chwili. Przecież algorytm wymiany dla cache jest poza zasięgiem programu i może być (i jest) inny dla różnych procesorów w ramach architektury. Tak więc jeśli użyjesz takiej optymalizacji, to uruchamiając ten program na innym komputerze x86 dostajesz poważną deoptymalizację i spowolnienie kodu. A skoro instalator jest już skompilowany, to na 90% urządzeń program będzie działać w sposób daleki od zamierzonego.
Pozdrawiam,
Tomasz Klasa
-----Original Message-----
From: Marcin Paprzycki ####@####.####
Sent: Thursday, December 7, 2017 8:20 PM
To: ####@####.####
Subject: Re: [st-pti] Architektura & Organizacja
TOmku
co to znaczy nie zrobi?
od tego jest aby zrobil do tego na czym biega od tego mamy 40 lat badan / rozwoju kompilatorow aby robily i robia ;-)
nie zrobi dostosowania mnozenia macierzy zadkiej przez wektor dostosowanego do sposobu reprezentacji tekze ale to inna bajka -- nie ma tak duzo osob, ktore iteracyjnie mnoza macierze zadkie o rozmiarze milion na milion przez wektor...
pozdrowienia,
M
On 2017-12-07 19:33, Tomasz Klasa wrote:
> Kompilator może uwzględniać tyle, ile wynika z architektury (ew. z tego, co wie o procesorze, na którym jest prowadzona kompilacja). Kompilator nie zrobi optymalizacji pod cache innej generacji procesora x86, na którym potem program będzie uruchamiany. Ponadto, zarządzanie cache jest zupełnie poniżej warstwy OS i warstwy programu użytkownika - to jest poziom mikrokodu. O tym kompilator nie wie, więc nawet jeśli wie, że dostępne jest 512kB, to nie wie co w nich jest.
> Dla programisty to wręcz nie może mieć znaczenia. Pamięci cache programista nie widzi, sposobu implementacji potoku w procesorze też nie. Szerokość cache może być diametralnie różna w ramach architektury i nie może być brana pod uwagę podczas programowania. Biorąc "poprawkę" na to, jak Intel i5 (np. wspomniany wcześniej Sandy Bridge) przetworzy kod wysokiego poziomu na sekwencję rozkazów na poziomie mikrokodu dopasujemy się do tej generacji procesora, ale na następnej (np. z inaczej zorganizowanym cache) program może działać słabo. Oczywiście można zrobić równoległe warianty optymalizacji pod ileś tam generacji CPU, ale...
>
> Pozdrawiam,
> Tomasz Klasa
>
>
> -----Original Message-----
> From: Piotr Karocki ####@####.####
> Sent: Thursday, December 7, 2017 7:17 PM
> To: ST PTI
> Subject: RE: [st-pti] Architektura & Organizacja
>
>> Np. sposób realizacji architektury x86 w procesorze Intel Sandy
>> Bridge jest inny niż w Intel P4 i jeszcze inny niż w AMD Athlon.
>> Natomiast dla programisty to wszystko nie ma znaczenia, bo on (a
>> raczej kompilator) widzi tylko zestaw instrukcji i rejestrów
>> wynikający z x86.
> Dla kompilatora to ma znaczenie, bo kompilator robi optymalizacje
> kodu - a przy tym uwzglednia liczbę taktów zegara na instrukcje,
> szerokosc cache, i wiele, wiele innych rzeczy. Dla programisty to
> POWINNO mieć znaczenie, bo programista powinien ROZUMIEĆ "co się
> dzieje". Nawet jak pisze w jezyku wysokiego poziomu, bardzo wysokiego
> poziomu - jak np. .Net (srodowisko) to i tak dobrze by bylo gdyby
> wiedział ile jest generowanych przejść między ringami kodu i jak to co
> robi zostanie przełożone na język maszynowy (no dobrze, może niech
> będzie że na "asembler symboliczny"). Jeszcze fajniej by było gdyby
> wiedział jak to zostanie przetworzone do mikrokodu (te procesory które
> mają μop-fusion, albo te które w ogóle programuje sie bezposrednio mikrokodem).
>
> Ale to może zbyt daleko posunięty idealizm :)
>
>
> ---8<---
> Piotr Karocki
>
> Wszystko co jest poniżej jest samowolnym dopiskiem Google
>
> ---
> ST-PTI. Lista dyskusyjna Sekcji Terminologicznej PTI.
> Archiwum publiczne listy: http://lists.tldp.org/go.to?list=st-pti
> ---
>
>
>
> ---
> ST-PTI. Lista dyskusyjna Sekcji Terminologicznej PTI.
> Archiwum publiczne listy: http://lists.tldp.org/go.to?list=st-pti
> ---
>
>
>
--
Best International CS / IS Conference in Poland
Details: http://www.fedcsis.org
Facebook group: http://preview.tinyurl.com/yeazgvw
---
Ta wiadomość e-mail została sprawdzona pod kątem wirusów przez oprogramowanie AVG.
http://www.avg.com
---
ST-PTI. Lista dyskusyjna Sekcji Terminologicznej PTI.
Archiwum publiczne listy: http://lists.tldp.org/go.to?list=st-pti
---
