Co to za procesor PPlain? + Out of order execution

Odpowiedz Nowy wątek
2006-12-25 14:10
0

Witam,

Co to za procesor PPlain? Dość ciężko znaleźć o nim jakieś informacje (na polskim google tylko jedna strona!, na zagranicznym więcej, ale nie związanych).
Czytam kurs o programowaniu w asemblerze dotyczącego parowania instrukcji (wykonywania dwóch instrukcji naraz). W nagłówku kursu pisze, że powinno się tego używać dla PPlain and PMMX.

Mój procesor.

Intel Pentium M Processor 730
533 MHz FSB, Supports Enhanced Intel SpeedStep Technology
1.60 GHz
2 MB Cache
lub w skrócie Intel Centrino 1.6 Sonoma

Wie ktoś może ile maksymalnie instrukcji naraz może wykonać mój procesor (lub dowolny inny, byłbym wdzięczny za jakiś adres do zasobu internetowego)? W PPlain i PMMX są dostępne dwa "pipe" (nie znam polskiego tłumaczenia - kanał, rura?) : U i V - Czyli parowanie do dwóch instukcji. Jednak jak to jest we współczesnych procesorach?

Zdaje się, że technologia out-of-order execution sprzętowo nieco pomaga w parowaniu (automatycznie zmieniając kolejność wykonywania rozkazów). Na jakich procesorach jest ona dostępna?
Wydawało mi się, że na moim procesorze ta technologia powinna się znajdować. Tymczasem gdy zmieniam kolejność rozkazów w prostej pętli w asemblerze (wykonywanej kilka milionów razy) to czas wykonania się lekko zmienia (zmiana rzędu pół procenta, ale zawsze). Mimo iż zmiana kolejności nie wpływa na inne zależności między danymi.

Pozostało 580 znaków

2006-12-25 17:14
0

ten kurs: http://agner.org/optimize/ ?

pplain to w wolnym tłumaczeniu 'zwykły pentium'.

pipe to potok w tym przypadku :)

na prockach 586 (czyli pplain i pmmx) masz dwa potoki - u i v oraz brak out- of- order execution.

na prockach 686 wzwyż masz kilka portów, a każda instrukcja jest dekodowana do postaci mikrokodów (µopów, uopów, jak zwał tak zwał :) ). out- of- order execution już jest (choć sam nie wiem po co - ustalanie kolejności instrukcji powinno być robione przez programistę lub kompilator, a tak to tylko procki są większe, bardziej gorące i trudniej pod nie optymalizować przez te zbędne 'technologie').


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2006-12-25 20:26
0
donkey7 napisał(a)

ten kurs: http://agner.org/optimize/ ?

Zgadza się :) Kurs Agner Fog'a ale z innej strony - http://fatphil.org/x86/pentopt/
Dopisane: Całkiem ciekawa stronka i zdaje się cały czas uaktualniana. Dzięki za linka!

donkey7 napisał(a)

pplain to w wolnym tłumaczeniu 'zwykły pentium'.

Heh, przez pół dnia czytałem o parowaniu, które jak się okazuje było używane w bardzo starych procesorach :D

donkey7 napisał(a)

na prockach 686 wzwyż masz kilka portów, a każda instrukcja jest dekodowana do postaci mikrokodów (µopów, uopów, jak zwał tak zwał :) ). out- of- order execution już jest (choć sam nie wiem po co - ustalanie kolejności instrukcji powinno być robione przez programistę lub kompilator, a tak to tylko procki są większe, bardziej gorące i trudniej pod nie optymalizować przez te zbędne 'technologie').

Poczytałem już troszkę więcej o wykonywaniu instrukcji przez procesory potokowe (z kursu Agnera Fog'a). Analizowanie takiego kodu pod jest troszkę trudniejsze. Przy rozpatrywaniu pętli trzeba rozpatrzyć ilość cykli potrzebnych na wykonanie rozkazów, pobranie rozkazów, dekodowanie rozkazów, wykonanie rozkazów, zapisanie rozkazów + register read stalls. Sprawa się komplikuje gdy liczy się długość wszystkich rozkazów i próbuje tak je dopasować by były optymalnie zdekodowane przez dekodery + jeszcze jakieś kary związane z niewyrównanymi danymi...

Pozostało 580 znaków

2006-12-27 13:41
0

jeśli już jesteś taki zapalony do optymalizacji, to szczególną uwagę zwróć na optymalizację dostępu do pamięci (tzn. sposób w jaki działa schowek / cache procesora).

w dobie programowania obiekotwego nierzadko zdarza się, że procek 99 % czasu poświęca na oczekiwanie na transfer pamięci do schowka. (pamięci są kilka razy wolniejsze od procków i mają duże opóźnienia, np 5- 5- 5- 15, co w sumie daje średni czas oczekiwania na transfer jednej zmiennej dochodzący do 100 cykli).

swego czasu zrobiłem własny kompresor plików - tarsalzp ( http://www.cs.fit.edu/~mmahoney/compression/text.html#2953 ). zoptymalizowanie dostępu do pamięci dało kopa 10 - 20 %, a użycie mmx'a jezcze dodatkowe 10 - 20 %.

ważność poszczególnych elementów (w kolejności od najważniejszego) (wg mnie ;) ):

  1. optymalizacja dostępu do pamięci,
  2. użycie intrukcji strumieniowych (mmx, sse, 3dnow),
  3. optymalizacja kodu,

"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2006-12-27 13:48
0

hm czyzby ktos tu mial przedmiot na studiach - architektura systemow komputerowych - lub podobny czy mi sie wydaje? :) jak jestes bardzo poczatkujacy to polecam ksiazke Morrisa Mano, w tym momencie tytulu nie pamietam (chociaz przydaje sie dla kazdego).


play hard..go pro.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0