st-pti: Re: Architektura & Organizacja
Subject:
Re: [st-pti] Architektura & Organizacja
From:
Marcin Paprzycki ####@####.####
Date:
7 Dec 2017 19:18:22 +0000
Message-Id: <e4f903d7-6ba0-bae3-53fe-e8e9f436d77a@ibspan.waw.pl>
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
