Subject:
RE: [st-pti] Architektura & Organizacja
From:
Piotr Karocki ####@####.####
Date:
7 Dec 2017 19:49:41 +0000
Message-Id: <ba7cfb62da8e4d4a780ac8391af9500e@mail.gmail.com>
Chodzi o to, żeby cache mógł być wykorzystany - czyli żeby (na przyklad)
skakanie po sparse table nie powodowało uniewazniania calego cache. Co
zresztą i tak dotyczy tylko tego, gdzie cache istnieje, gdzie jest
hierarchia pamięci... Bo przeciez kto powiedzial ze tak musi byc? RAM
przestanie być bandą kondensatorów, zacznie być bandą memrystorów - samo to,
że przechowuje dane pomiędzy uruchomieniami zmienia parametry naszej zabawy.
Ot, dostęp do kluczy prywatnych zatrzymanych w pamięci po restarcie.
(tak, wiem, przy zwyklych tranzystorowych kosciach to tez jest mozliwe;
korzystając z odpowiednich narzedzi nawet po dwu tygodniach; przy
memrystorkach zaś - dostepne jest dla zwyklego software).
-----Original Message-----
From: Tomasz Klasa ####@####.####
Sent: Thursday, 07 December 2017 20:42
To: 'ST PTI'
Subject: RE: [st-pti] Architektura & Organizacja
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
---
---
ST-PTI. Lista dyskusyjna Sekcji Terminologicznej PTI.
Archiwum publiczne listy: http://lists.tldp.org/go.to?list=st-pti
---
