|
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.
|
|
|
|
 |
 |
 |
|
|
|
poprzednia strona (Pierwsze kroki x86 w stronę RISCa) 
