Procesory są projektowane tak, aby wykonywać miliardy operacji w ciągu sekundy. Pewien badacz sprzętu postanowił jednak sprawdzić, jak bardzo można odwrócić tę zasadę.
Zamiast szukać najszybszych instrukcji x86, zaczął polować na te najwolniejsze. W jego eksperymencie pojedyncza instrukcja potrzebowała aż 198 miliardów cykli zegara, a jej wykonanie trwało około 62 sekund. Tak powstał nietypowy ranking deoptymalizacji procesora, który pokazuje, jak absurdalnie wolna może stać się pojedyncza operacja, jeśli odpowiednio przygotuje się środowisko jej wykonania.
Za projektem stoi badacz sprzętu Christopher Domas, znany w środowisku niskopoziomowego programowania jako @xoreaxeaxeax. Jego pomysł jest przewrotny. Zamiast analizować opóźnienia instrukcji po to, aby znaleźć sposoby na przyspieszenie kodu, Domas próbuje znaleźć kombinacje prowadzące do maksymalnego spowolnienia.
Efektem jest CPU Deoptimization Leaderboard, czyli swoista „izba hańby” dla instrukcji procesorów.
Nie chodzi o najwolniejszy procesor
Na pierwszy rzut oka wynik może wydawać się niewiarygodny. Współczesne procesory potrafią wykonywać ogromną liczbę operacji w bardzo krótkim czasie. Tymczasem zwycięska konfiguracja eksperymentu doprowadziła do sytuacji, w której wykonanie jednej instrukcji trwało około 62 sekund.
Nie oznacza to jednak, że procesor przez cały ten czas był zajęty wykonywaniem typowej operacji arytmetycznej.
Sekret tkwi w środowisku, w którym instrukcja została wykonana.
Domas bada bowiem nie tylko sam rozkaz procesora, lecz także sposób, w jaki można zmusić sprzęt do oczekiwania na bardzo wolne operacje wejścia i wyjścia. W tym przypadku wykorzystano między innymi komunikację z urządzeniami za pośrednictwem PCI Express oraz pamięć MMIO. To właśnie dlatego ranking jest bardziej eksperymentem z granicami architektury procesora niż prostą tabelą „najwolniejszych instrukcji”.
Zwycięzca potrzebował 198 miliardów cykli
Najwolniejszą konfiguracją okazała się instrukcja fxrstor64. Jej zadaniem jest odtworzenie stanu rejestrów wykorzystywanych przez procesor podczas obliczeń SIMD. Instrukcja może operować na dużym bloku danych przechowywanym w pamięci. Domas znalazł sposób na wykorzystanie tego mechanizmu w połączeniu z bardzo wolnym obszarem MMIO.
Najpierw jego narzędzie mmiotic pomogło zidentyfikować obszar infrastruktury PCIe charakteryzujący się wyjątkowo wysokim opóźnieniem. Następnie badacz zmusił procesor do pobrania 512 bajtów stanu właśnie z tego miejsca. W efekcie pojedyncza instrukcja została zmuszona do oczekiwania na dane pochodzące z niezwykle wolnego źródła.
Pierwsza wersja eksperymentu zajęła około 74 miliardów cykli, czyli ponad 23 sekundy. Na tym Domas jednak nie poprzestał.
Badacz celowo zagłodził procesor
Kolejny etap eksperymentu był jeszcze bardziej pomysłowy. Domas zaczął wykonywać serię małych, czterobajtowych odczytów z innego obszaru MMIO o wysokim opóźnieniu. Chodziło o przeciążenie infrastruktury odpowiedzialnej za komunikację PCIe. W ten sposób procesor musiał kolejkować operację odtworzenia stanu za innymi, bardzo wolnymi odczytami.
Można to porównać do ustawienia jednej wyjątkowo wolnej operacji w kolejce, a następnie celowego zablokowania wszystkich dróg prowadzących do jej wykonania. Eksperyment doprowadził do wyniku wynoszącego około 198 miliardów cykli. Przy testowanej częstotliwości przekładało się to na około 62 sekundy.
Jedna instrukcja procesora potrzebowała więc czasu porównywalnego z długością krótkiego filmu.
Jeszcze większy koszmar był możliwy
Domas wskazuje, że można było pójść jeszcze dalej. W eksperymencie wykorzystano również instrukcje AMX dostępne między innymi w procesorach Intel Sapphire Rapids. Mechanizm ten pozwolił zwiększyć obszar przechowywanego stanu z 512 bajtów aż do 8 KB. Przy odpowiedniej konfiguracji mogłoby to doprowadzić do opóźnienia przekraczającego bilion cykli.
To pokazuje, jak bardzo wynik zależy od warunków, w których wykonywana jest instrukcja.
Nie jest to więc sytuacja, w której producent procesora umieścił w układzie pojedynczy rozkaz, który z natury potrzebuje kilkudziesięciu sekund na wykonanie. Badacz stworzył wyjątkowo niekorzystne środowisko i wykorzystał je do wyciągnięcia opóźnienia do ekstremalnego poziomu.
„Najwolniejsza instrukcja” to trochę pułapka
W tym eksperymencie kryje się ważny szczegół. Ranking nie pokazuje po prostu listy instrukcji x86 uporządkowanych od najszybszej do najwolniejszej. Wynik zależy w dużej mierze od tego, co badacz zrobi z konkretnym poleceniem. Ta sama instrukcja może w normalnym programie wykonać się bardzo szybko. Jeżeli jednak procesor zostanie zmuszony do oczekiwania na dane z wyjątkowo wolnego źródła, sytuacja może wyglądać zupełnie inaczej.
Dlatego projekt Domasa jest bardziej badaniem możliwości deoptymalizacji niż klasycznym benchmarkiem procesorów. Jego celem nie jest pokazanie, który CPU jest najlepszy do gier czy pracy. Chodzi o znalezienie granic, do których można doprowadzić wykonanie pojedynczej instrukcji.
Stare procesory też mają swoje miejsce w rankingu
Do eksperymentów Domas wykorzystywał między innymi procesory Intel Core i7-8559U oraz AMD Ryzen 7 5800H. W jednym z testów sięgnął jednak po znacznie starszą konstrukcję.
Procesor VIA Eden, pochodzący z początku XXI wieku, posłużył do sprawdzenia instrukcji rdmsr. Ten rozkaz pozwala odczytywać rejestry MSR, czyli rejestry specyficzne dla danego modelu procesora.
Domas odkrył w układzie VIA nieudokumentowany rejestr znajdujący się pod adresem 0x133. Według jego obserwacji odczyt tego rejestru zapewniał wyjątkowo długi czas reakcji.
Wynik wyniósł około 202 mikrosekund, czyli 161 602 cykle zegara. Na tle 198 miliardów cykli może wyglądać skromnie, ale w świecie pojedynczych instrukcji taki rezultat również jest bardzo nietypowy.
Powstaje nietypowa mapa słabych punktów x86
Projekt jest dostępny publicznie na GitHubie i nie ogranicza się do jednego procesora. Domas ustalił również zasady, które mają umożliwić porównywanie wyników z różnych platform. Do rankingu można zgłaszać dowolne konfiguracje, o ile punktowane jest wykonanie pojedynczej instrukcji.
Nie można natomiast wykorzystywać instrukcji, które mogą zostać przerwane, ani przypadków, w których badana operacja jest emulowana przez moduł obsługi. Czasy są normalizowane względem bazowej częstotliwości procesora. Testy wykonywane są także bez fizycznych modyfikacji sprzętu.
Dzięki temu ranking ma pokazywać możliwości istniejących układów, a nie wynik eksperymentu wymagającego specjalnie przerobionego komputera.
Po x86 mogą przyjść ARM i RISC-V
Najciekawsze może być jednak to, że projekt nie musi zakończyć się na architekturze x86. Domas zapowiada możliwość stworzenia podobnych rankingów dla ARM oraz RISC-V. To otworzyłoby drogę do porównania zupełnie różnych filozofii projektowania procesorów.
Takie zestawienie nie odpowiadałoby oczywiście na pytanie, która architektura jest najlepsza. Pokazywałoby raczej, jak różne mechanizmy procesorów reagują na ekstremalne warunki wykonania instrukcji. Dla osób zajmujących się projektowaniem CPU, systemami operacyjnymi, kompilatorami czy bezpieczeństwem niskopoziomowym może to być wyjątkowo interesujący materiał badawczy.
Ten badacz już wcześniej robił rzeczy, których nie powinien robić normalny kompilator
Procesory są projektowane tak, aby wykonywać miliardy operacji w ciągu sekundy. Pewien badacz sprzętu postanowił jednak sprawdzić, jak bardzo można odwrócić tę zasadę.
Zamiast szukać najszybszych instrukcji x86, zaczął polować na te najwolniejsze. W jego eksperymencie pojedyncza instrukcja potrzebowała aż 198 miliardów cykli zegara, a jej wykonanie trwało około 62 sekund. Tak powstał nietypowy ranking deoptymalizacji procesora, który pokazuje, jak absurdalnie wolna może stać się pojedyncza operacja, jeśli odpowiednio przygotuje się środowisko jej wykonania.
Za projektem stoi badacz sprzętu Christopher Domas, znany w środowisku niskopoziomowego programowania jako @xoreaxeaxeax. Jego pomysł jest przewrotny. Zamiast analizować opóźnienia instrukcji po to, aby znaleźć sposoby na przyspieszenie kodu, Domas próbuje znaleźć kombinacje prowadzące do maksymalnego spowolnienia.
Efektem jest CPU Deoptimization Leaderboard, czyli swoista „izba hańby” dla instrukcji procesorów.
Nie chodzi o najwolniejszy procesor
Na pierwszy rzut oka wynik może wydawać się niewiarygodny. Współczesne procesory potrafią wykonywać ogromną liczbę operacji w bardzo krótkim czasie. Tymczasem zwycięska konfiguracja eksperymentu doprowadziła do sytuacji, w której wykonanie jednej instrukcji trwało około 62 sekund.
Nie oznacza to jednak, że procesor przez cały ten czas był zajęty wykonywaniem typowej operacji arytmetycznej.
Sekret tkwi w środowisku, w którym instrukcja została wykonana.
Domas bada bowiem nie tylko sam rozkaz procesora, lecz także sposób, w jaki można zmusić sprzęt do oczekiwania na bardzo wolne operacje wejścia i wyjścia. W tym przypadku wykorzystano między innymi komunikację z urządzeniami za pośrednictwem PCI Express oraz pamięć MMIO. To właśnie dlatego ranking jest bardziej eksperymentem z granicami architektury procesora niż prostą tabelą „najwolniejszych instrukcji”.
Zwycięzca potrzebował 198 miliardów cykli
Najwolniejszą konfiguracją okazała się instrukcja fxrstor64. Jej zadaniem jest odtworzenie stanu rejestrów wykorzystywanych przez procesor podczas obliczeń SIMD. Instrukcja może operować na dużym bloku danych przechowywanym w pamięci. Domas znalazł sposób na wykorzystanie tego mechanizmu w połączeniu z bardzo wolnym obszarem MMIO.
Najpierw jego narzędzie mmiotic pomogło zidentyfikować obszar infrastruktury PCIe charakteryzujący się wyjątkowo wysokim opóźnieniem. Następnie badacz zmusił procesor do pobrania 512 bajtów stanu właśnie z tego miejsca. W efekcie pojedyncza instrukcja została zmuszona do oczekiwania na dane pochodzące z niezwykle wolnego źródła.
Pierwsza wersja eksperymentu zajęła około 74 miliardów cykli, czyli ponad 23 sekundy. Na tym Domas jednak nie poprzestał.
Badacz celowo zagłodził procesor
Kolejny etap eksperymentu był jeszcze bardziej pomysłowy. Domas zaczął wykonywać serię małych, czterobajtowych odczytów z innego obszaru MMIO o wysokim opóźnieniu. Chodziło o przeciążenie infrastruktury odpowiedzialnej za komunikację PCIe. W ten sposób procesor musiał kolejkować operację odtworzenia stanu za innymi, bardzo wolnymi odczytami.
Można to porównać do ustawienia jednej wyjątkowo wolnej operacji w kolejce, a następnie celowego zablokowania wszystkich dróg prowadzących do jej wykonania. Eksperyment doprowadził do wyniku wynoszącego około 198 miliardów cykli. Przy testowanej częstotliwości przekładało się to na około 62 sekundy.
Jedna instrukcja procesora potrzebowała więc czasu porównywalnego z długością krótkiego filmu.
Jeszcze większy koszmar był możliwy
Domas wskazuje, że można było pójść jeszcze dalej. W eksperymencie wykorzystano również instrukcje AMX dostępne między innymi w procesorach Intel Sapphire Rapids. Mechanizm ten pozwolił zwiększyć obszar przechowywanego stanu z 512 bajtów aż do 8 KB. Przy odpowiedniej konfiguracji mogłoby to doprowadzić do opóźnienia przekraczającego bilion cykli.
To pokazuje, jak bardzo wynik zależy od warunków, w których wykonywana jest instrukcja.
Nie jest to więc sytuacja, w której producent procesora umieścił w układzie pojedynczy rozkaz, który z natury potrzebuje kilkudziesięciu sekund na wykonanie. Badacz stworzył wyjątkowo niekorzystne środowisko i wykorzystał je do wyciągnięcia opóźnienia do ekstremalnego poziomu.
„Najwolniejsza instrukcja” to trochę pułapka
W tym eksperymencie kryje się ważny szczegół. Ranking nie pokazuje po prostu listy instrukcji x86 uporządkowanych od najszybszej do najwolniejszej. Wynik zależy w dużej mierze od tego, co badacz zrobi z konkretnym poleceniem. Ta sama instrukcja może w normalnym programie wykonać się bardzo szybko. Jeżeli jednak procesor zostanie zmuszony do oczekiwania na dane z wyjątkowo wolnego źródła, sytuacja może wyglądać zupełnie inaczej.
Dlatego projekt Domasa jest bardziej badaniem możliwości deoptymalizacji niż klasycznym benchmarkiem procesorów. Jego celem nie jest pokazanie, który CPU jest najlepszy do gier czy pracy. Chodzi o znalezienie granic, do których można doprowadzić wykonanie pojedynczej instrukcji.
Stare procesory też mają swoje miejsce w rankingu
Do eksperymentów Domas wykorzystywał między innymi procesory Intel Core i7-8559U oraz AMD Ryzen 7 5800H. W jednym z testów sięgnął jednak po znacznie starszą konstrukcję.
Procesor VIA Eden, pochodzący z początku XXI wieku, posłużył do sprawdzenia instrukcji rdmsr. Ten rozkaz pozwala odczytywać rejestry MSR, czyli rejestry specyficzne dla danego modelu procesora.
Domas odkrył w układzie VIA nieudokumentowany rejestr znajdujący się pod adresem 0x133. Według jego obserwacji odczyt tego rejestru zapewniał wyjątkowo długi czas reakcji.
Wynik wyniósł około 202 mikrosekund, czyli 161 602 cykle zegara. Na tle 198 miliardów cykli może wyglądać skromnie, ale w świecie pojedynczych instrukcji taki rezultat również jest bardzo nietypowy.
Powstaje nietypowa mapa słabych punktów x86
Projekt jest dostępny publicznie na GitHubie i nie ogranicza się do jednego procesora. Domas ustalił również zasady, które mają umożliwić porównywanie wyników z różnych platform. Do rankingu można zgłaszać dowolne konfiguracje, o ile punktowane jest wykonanie pojedynczej instrukcji.
Nie można natomiast wykorzystywać instrukcji, które mogą zostać przerwane, ani przypadków, w których badana operacja jest emulowana przez moduł obsługi. Czasy są normalizowane względem bazowej częstotliwości procesora. Testy wykonywane są także bez fizycznych modyfikacji sprzętu.
Dzięki temu ranking ma pokazywać możliwości istniejących układów, a nie wynik eksperymentu wymagającego specjalnie przerobionego komputera.
Po x86 mogą przyjść ARM i RISC-V
Najciekawsze może być jednak to, że projekt nie musi zakończyć się na architekturze x86. Domas zapowiada możliwość stworzenia podobnych rankingów dla ARM oraz RISC-V. To otworzyłoby drogę do porównania zupełnie różnych filozofii projektowania procesorów.
Takie zestawienie nie odpowiadałoby oczywiście na pytanie, która architektura jest najlepsza. Pokazywałoby raczej, jak różne mechanizmy procesorów reagują na ekstremalne warunki wykonania instrukcji. Dla osób zajmujących się projektowaniem CPU, systemami operacyjnymi, kompilatorami czy bezpieczeństwem niskopoziomowym może to być wyjątkowo interesujący materiał badawczy.
Everyone's trying to make CPUs faster.
— domas (@xoreaxeaxeax) August 7, 2026
I’m trying to make them worse.
New project: CPU deoptimization.
Searching for the slowest possible machine instructions
x86 single instruction record:
198,002,498,236 cycles, 62 seconds
The assembly hall of shame: https://t.co/G4QnFQjsZx pic.twitter.com/WNaRPf2kRC
Ten badacz już wcześniej robił rzeczy, których nie powinien robić normalny kompilator
CPU Deoptimization Leaderboard nie jest pierwszym nietypowym projektem Domasa. Wcześniej stworzył movfuscator, czyli eksperymentalny kompilator języka C wykorzystujący do generowania programu wyłącznie instrukcję MOV.
Sam pomysł brzmi absurdalnie z punktu widzenia klasycznego programowania. Instrukcja MOV służy przecież przede wszystkim do przenoszenia danych. Domas pokazał jednak, że przy odpowiednim podejściu można wykorzystać ją jako podstawę znacznie bardziej skomplikowanych konstrukcji. Nowy projekt jest równie przewrotny.
Zamiast zastanawiać się, jak wykorzystać procesor maksymalnie efektywnie, badacz pyta, jak bardzo można go spowolnić za pomocą jednej instrukcji.
Procesor potrafi być absurdalnie wolny
Największa wartość tego eksperymentu nie polega na samym rekordzie 198 miliardów cykli. Znacznie ciekawsze jest pokazanie, że wydajność procesora nie zależy wyłącznie od częstotliwości taktowania, liczby rdzeni czy generacji układu. Liczy się również cała infrastruktura znajdująca się za instrukcją: pamięć, magistrale, mechanizmy wejścia i wyjścia, kolejki operacji oraz sposób komunikacji z urządzeniami.
Jeżeli wszystkie te elementy zostaną odpowiednio wykorzystane, pojedyncza instrukcja może stać się potężnym hamulcem.
I właśnie dlatego „izba hańby” dla najwolniejszych instrukcji jest znacznie ciekawsza, niż sugerowałaby jej żartobliwa nazwa. Pokazuje bowiem granice, których podczas normalnego użytkowania komputera praktycznie nigdy nie widzimy.
A rekord Domasa przypomina, że nawet najbardziej zaawansowany procesor można zmusić do bardzo długiego oczekiwania. Wystarczy znaleźć właściwe miejsce, właściwą instrukcję i odpowiednio złośliwe warunki jej wykonania.
CPU Deoptimization Leaderboard nie jest pierwszym nietypowym projektem Domasa. Wcześniej stworzył movfuscator, czyli eksperymentalny kompilator języka C wykorzystujący do generowania programu wyłącznie instrukcję MOV.
Sam pomysł brzmi absurdalnie z punktu widzenia klasycznego programowania. Instrukcja MOV służy przecież przede wszystkim do przenoszenia danych. Domas pokazał jednak, że przy odpowiednim podejściu można wykorzystać ją jako podstawę znacznie bardziej skomplikowanych konstrukcji. Nowy projekt jest równie przewrotny.
Zamiast zastanawiać się, jak wykorzystać procesor maksymalnie efektywnie, badacz pyta, jak bardzo można go spowolnić za pomocą jednej instrukcji.
Procesor potrafi być absurdalnie wolny
Największa wartość tego eksperymentu nie polega na samym rekordzie 198 miliardów cykli. Znacznie ciekawsze jest pokazanie, że wydajność procesora nie zależy wyłącznie od częstotliwości taktowania, liczby rdzeni czy generacji układu. Liczy się również cała infrastruktura znajdująca się za instrukcją: pamięć, magistrale, mechanizmy wejścia i wyjścia, kolejki operacji oraz sposób komunikacji z urządzeniami.
Jeżeli wszystkie te elementy zostaną odpowiednio wykorzystane, pojedyncza instrukcja może stać się potężnym hamulcem.
I właśnie dlatego „izba hańby” dla najwolniejszych instrukcji jest znacznie ciekawsza, niż sugerowałaby jej żartobliwa nazwa. Pokazuje bowiem granice, których podczas normalnego użytkowania komputera praktycznie nigdy nie widzimy.
A rekord Domasa przypomina, że nawet najbardziej zaawansowany procesor można zmusić do bardzo długiego oczekiwania. Wystarczy znaleźć właściwe miejsce, właściwą instrukcję i odpowiednio złośliwe warunki jej wykonania.
Spodobało Ci się? Podziel się ze znajomymi!
Pokaż / Dodaj komentarze do:
Ta instrukcja procesora potrzebuje 62 sekund. Powstała „izba hańby” dla najwolniejszych poleceń x86