st-pti: Re: Architektura & Organizacja


Previous by date: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Grzegorz Plucinski
Next by date: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Piotr Karocki
Previous in thread: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Grzegorz Plucinski
Next in thread: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Piotr Karocki

Subject: RE: [st-pti] Architektura & Organizacja
From: "Tomasz Klasa" ####@####.####
Date: 7 Dec 2017 18:32:00 +0000
Message-Id: <005c01d36f89$f267d4d0$d7377e70$@o2.pl>

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
---



Previous by date: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Grzegorz Plucinski
Next by date: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Piotr Karocki
Previous in thread: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Grzegorz Plucinski
Next in thread: 7 Dec 2017 18:32:00 +0000 Re: Architektura & Organizacja, Piotr Karocki


  ©The Linux Documentation Project, 2014. Listserver maintained by dr Serge Victor on ibiblio.org servers. See current spam statz.