arch - centrino?[OT - narzekania]

[Artur Flinta]

W liście z pią, 18-06-2004, godz. 23:06 +0200, Cezary Krzyżanowski
napisał(a):
> Muszę przyznać, że burzysz tutaj mój starannie wypieszczony światopogląd 
> :D No jeżeli wszystko dobrze rozumiem, to po to się podaje 
> kompilatorowi, na jaką architekturę ma optymalizować, żeby wiedział, co 
> to Centrino, nie ? No po etapie analizy składniowej jak działa generacja 
> kodu tymczasowego i potem jego optymalizacja, to chyba właśnie wtedy 
> jest brane pod uwagę, co to za architektura, w czym jest "dobra", a w 
> czym nie, ile ma keszu itd....No nigdy nie rozbierałem kompilatora aż 

Najpierw kompilator musi umieć te procki wszystkie rozróżnić i mieć do
nich zaimplementowaną optymalizację. Optymalizacja kompilatora niewiele
da, jeżeli napiszesz program do liczenia macierzy tak, że za każdą
kolejno liczoną pętlą będzie się musiał do pamięci RAM odwoływać, bo
akurat sposób ułożenia danych jest taki a nie inny (czasem pomaga,
odwrócenie pętli by dane zamiast z RAM w większości szły z cache).
Oczywiście jest to bardzo specyficzny przypadek, dla macierzy które się
nie mieszczą w pamięci podręcznej procka, ale warto na takie bardziej
złożone obliczeniowo problemy zwracać uwagę. Tutaj kompilator nie
pomoże. Kolejna różnica to wszelakie SSE, MMX itp. Jeżeli aplikacja z
tego jakoś bezpośrednio nie korzysta, to kompilator też wiele tutaj nie
wniesie. Owszem, zapewne jakiś kod pod te jednostki generuje, ale na
100% nie da to takiego efektu jak przemyślane i świadome użycie tych
rozszerzeń przez programistę, który też odpowiednio dobierze wielkość i
rodzaj struktur danych, by lepiej były przez te dodatkowe instrukcje
przetwarzane. 

> tak bardzo, żeby się o tym przekonać....Z drugiej strony nasuwasz mi 
> myśli, że optymalizacja kodu przy kompilacji nadaje się tylko do lipnie 
> napisanych programów :D 

Nie, staram się Ci uświadomić, że największy zysk jest w optymalizacji
algorytmów, to co kompilator dopasowuje do konkretnego procesora jest
już tylko takim lepszym ułożeniem instrukcji, by lepiej wpasowywały się
w potoki procka. Ale jak już dwa listy temu pisałem, zaawansowane
jednostki predykcji w rdzeniach procesorów, też same sobie potrafią
podobną niby "optymalizację" zrobić dla kodu.

> Bo jak ktoś dobrze pisze, to w zasadzie mało już 
> zostaje do optymalizacji, to fakt, ale kolejne generacje procków no 
> muszę się różnić do cholery czymś więcej, niż tylko taktowaniem i 
> ilością pamięci podręcznej, na pewno są na każdej architekturze jakieś 

Owszem, zmienia się liczba potoków, obsługa pamięci, algorytm predykcji,
dochodzą nowe instrukcje które za jednym zamachem potrafią zrobić w tym
samym czasie to co poprzedni procek musiał mielić kilkoma instrukcjami.

> kruczki, które można wykorzystać przy optymalizacji kodu wyjściowego, o 
> którch programista nie koniecznie musi wiedzieć (nie wiem, w stylu że 

Jeżeli ma już zoptymalizowany algorytm, to niestety trzeba znać te
kruczki procka na jakiego dokładnie się pisze program. W sumie to
jeszcze lepiej będzie, jak kluczowe elementy zostaną zapisane w
assemblerze, by nie dać kompilatorowi możliwości skopania kodu
wynikowego.

Pozdrawiam

	Artur
-- 
Zawsze kiedy jest problem, jest jakieś rozwiązanie;
 zatem jeśli nie ma rozwiązania, nie ma problemu.