Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
TwojePC.pl © 2001 - 2024
RECENZJE | Technika. Droga ku wydajności
    

 

Technika. Droga ku wydajności


 Autor: Zbyszek | Data: 23/04/07

Przetwarzanie potokowe i x86 - mieszanka wybuchowa

Wykorzystanie dwóch równoległych potoków wykonawczych do pracy nad specyficznym kodem x86, potwierdziło, że szeregowy ciąg instrukcji powiązanych między sobą wzajemnymi relacjami, jest niesłychanie trudny do równoległego wykonywania.

Aby narobić sporego zamieszania w potokach wykonawczych procesora, wystarczyły dwie typowe instrukcje x86 połączone ze sobą prostą zależnością - do wykonania jednej z nich potrzebny jest wyniki innej instrukcji. Co wtedy, gdy obie te instrukcje nastąpią jedna po drugiej i równocześnie znajdą się w dwóch równoległych potokach?
Wystąpienie takiej sytuacji powodowało konieczność zatrzymania pracy potoku wykonawczego, z instrukcją oczekującą na wynik wykonania drugiej instrukcji znajdującej się w drugim potoku. Wstrzymanie pracy potoku musiało trwać do czasu całkowitego wykonania i wczytania wyniku drugiej instrukcji, wykonywanej w sąsiednim potoku.

Łatwo się domyślić, że zaistnienie takiej sytuacji owocowało spadkiem szybkości wykonywania instrukcji. A co w wypadku, gdy jednocześnie w potokach procesora znalazło się więcej takich rozkazów? Powstał w nich po prostu duży korek, zwalniający pracę potoków wykonawczych, i w końcowym efekcie powodujący wyraźny spadek wydajności całego CPU.

Ale to nie koniec niespodzianek. Jeszcze większe kłopoty powodowały instrukcje kodu x86 bezpośrednio odwołujące się do pamięci operacyjnej. Wykonanie takiej instrukcji w potoku wykonawczym, powodowało konieczność zatrzymania pracy tego potoku na dość długi okres czasu, potrzebny do wykonania komunikacji z pamięcią operacyjną, czyli przeciętnie aż kilkaset cykli zegara! Dramat.

Jednak nie była to jeszcze sytuacja najgorsza z możliwych. W potokach układu oba typy instrukcji mogły przecież znaleźć się jednocześnie, a dodatkowo jeszcze we wzmożonych ilościach. I co wtedy? Rozwiązanie takiej plątaniny trwałoby ogrom czasu, a wydajność spadła niemalże do zera. Koszmar!

Oczywiście tak ekstremalnie niekorzystna sytuacja występowała bardzo rzadko, bo w kodzie x86 instrukcje te nie stanowiły większości. Jednak o zatrzymanie pracy całego CPU na kilkaset cykli zegara nie było trudno.
Wystarczyło wystąpienie dwóch odpowiednio ułożonych instrukcji: w pierwszym potoku instrukcja odwołująca się do pamięci RAM, w drugim instrukcja oczekująca na wynik innej instrukcji z pierwszego potoku - wstrzymanym na kilkaset cykli zegara ze względu na odwołanie do pamięci operacyjnej. Wówczas drugi potok, tak jak i pierwszy wstrzymywany był na kilkaset taktów zegara, aż do czasu wykonania instrukcji stojącej obecnie w zatrzymanym pierwszym potoku.

Specyfika kodu x86 okazała się więc dla architektury potokowej dużym problemem, skutecznie ograniczającym jej ogromne możliwości. Nie ulegało wątpliwości, że należało w jakiś sposób wesprzeć ją w wykonywaniu nieprzyjaznych dla niej instrukcji kodu x86.







Polub TwojePC.pl na Facebooku

Rozdziały: Technika. Droga ku wydajności
 
 » CISC i RISC
 » Architektura potokowa
 » Wydajny RISC
 » Ogromne możliwości
 » Kod x86 niewygody dla architektury RISC
 » Pierwsze kroki x86 w stronę RISCa
 » Przetwarzanie potokowe i x86 - mieszanka wybuchowa
 » Kłopotliwe przeskoki
 » 1995 - rok procesorowych rewolucji
 » Bez kuli u nogi
 » Poza kolejnością
 » Więcej mocy
 » Jedna instrukcja, wiele danych
 » Wciąż słabe zmienne przecinki
 » SSE - druga generacja SIMD w układach x86
 » 128 bitowe zmiennoprzecinkowe FPU - coraz bliżej RISCa
 » x86-64 - więcej rejestrów
 » Zjedzona od środka
 » Zakończenie oraz Słowo od Autora
 » Kliknij, aby zobaczyć cały artykuł na jednej stronie
Wyświetl komentarze do artykułu »