r   e   k   l   a   m   a
r   e   k   l   a   m   a

Łatka Google'a na lukę w AMD i Intelach jednak spowalnia. Ale nie zgadniesz jak

Strona główna AktualnościSPRZĘT

Gdy głośno zrobiło się o atakach Meltdown i Spectre, najbardziej poszkodowanym okazał się Intel – wszystkie produkowane od 1995 roku jego procesory były podatne na te zagrożenia. AMD niezwłocznie zapewniło, że architektura jego procesorów na Meltdown jest odporna, zaś w wypadku Spectre wystarczą łatki software’owe, których wpływ na wydajność systemu będzie znikomy. Niestety sytuacja nie wygląda tak różowo, jak czerwoni chcą ją nam przedstawić. Łatki Retpoline, mające zabezpieczyć przed drugą odmianą ataku Spectre, są już dostępne, jednak generowanego przez nie narzutu zlekceważyć nie można.

Łatki Kernel Page Table Isolation błyskawicznie wylądowały w linuksowym kernelu, łatając podatność na Meltdown na procesorach Intela. Decyzją Linusa Torvaldsa nie są one ładowane na procesorach AMD, dzięki czemu nie doświadczymy efektów ubocznych – znaczącego spadku wydajności w obciążeniach roboczych związanych z operacjami I/O, dostępem do sieci i zasobów dyskowych.

Z łatkami na Spectre sytuacja wygląda bardziej skomplikowanie. Atak ten, grożący zarówno procesorom Intela jak i AMD, został zneutralizowany za pomocą łatek Retpoline, stworzonych przede wszystkim przez programistów Google’a. Uniemożliwiają one ataki wstrzykiwania rozgałęzień, poprzez unikanie spekulatywnych niebezpośrednich rozgałęzień w kodzie kernela. Wydana w ostatni weekend wersja piąta łatek to około 200 wierszy kodu dla kernela, połączonych ze specjalnymi łatkami dla kompilatora GCC – i jak zapowiadają jej twórcy, obniży wydajność systemu o jakieś 1,5%. Można to przeżyć, a nawet zrekompensować optymalizacjami, prawda?

r   e   k   l   a   m   a

Zależy jednak w czym. Na łamach Phoronixa/OpenBenchmarking pojawiły się wyniki testów wydajności uodpornionych na Spectre systemów, zarówno częściowo, poprzez same łatki na kernel (retpoline), jak i całkowicie, poprzez łatki na kernel i kompilator (retpoline+gcc). Michael Larabel przetestował zarówno procesory Intel Kaby Lake i Coffee Lake, jak i AMD Ryzen/EPYC, jako że wszystkie one są podatne na Spectre.

Wolniej, szybciej, bez zmian?

Jak można się było spodziewać, w większości syntetycznych obciążeń roboczych zauważalnych różnic nie ma. Ale zarazem widać też, że pojawiają się niespodziewanie nowe wąskie gardła, specyficzne dla danej platformy. Oto najważniejsze problemy, jakie przynosi załatanie Spectre:

  • W teście losowego odczytu danych (Flexible IO Tester) procesory Core i9-7980XE i Ryzen 7 1800X odnotowały po zastosowaniu łatek drastyczne spadki IOPS, odpowiednio 34% i 36%. Co ciekawe, inne testowane procesory Intela i AMD ucierpiały jedynie minimalnie, a nawet (Dual Xeon Gold 6138) uzyskały wydajność nieco wyższą.
  • W teście losowego zapisu danych (Flexible IO Tester) wspomniany Core i9-7980XE utracił od 11% do 21% IOPS, odpowiednio dla łatek retpoline i retpoline+gcc. Niespodzianka: Ryzen 7 1800X nieco po łatkach przyspieszył.
  • W teście sekwencyjnego zapisu danych znów najbardziej ucierpiał Core i9-7980XE, po łatkach szybkość zapisu spadła od 4% (retpoline) do 11% (retpoline+gcc).
  • W teście budowania projektu do kompilacji (Compile Bench Initial Create) najwięcej oberwały procesory Intela: i7-8700K, i9-7980XE i Dual Xeon Gold 6138 odnotowały spadki od 5% do 10%. Procesory AMD wyszły tu obronną ręką.
  • Czas samej kompilacji po zastosowaniu łatek nie uległ wydłużeniu – zarówno w Timed Apache Compilation jak i Timed Linux Kernel Compilation procesory Intela i AMD wykazywały różnice poniżej błędu pomiaru.
  • Jeśli chodzi o czystą wydajność procesora, to zupełnie nie ma czym się przejmować, łatki na Spectre nie powodują tu żadnego mierzalnego zmniejszenia wydajności – pokazały to benchmarki Parboil (OpenMP), Rodinia, lzbench, John the Ripper czy C-ray.
  • Procesor AMD Epyc miał problemy z benchmarkiem webserwera ebizzy, który generuje obciążenia typowe np. dla sklepów internetowych – dużo wątków, częste alokacje i dealokacje dużych obszarów pamięci. Po zastosowaniu retpoline+gcc jego wydajność spadła aż o 13%. Ryzen 7 1800X zachował się zaś dziwnie – przy samych łatkach retpoline w benchmarku tym uzyskał o kilka procent większą wydajność, zaś z łatkami retpoline+gcc stracił 8%. Procesory Intela nie ucierpiały tu zauważalnie.
  • Prawdziwy dramat zaczął się przy obciążeniach bazodanowych. Wydajność Redisa w benchmarku LPOP (usuwanie i zwracanie pierwszego elementu listy przechowanego jako klucz), przyniosło spadki sięgające nawet 35% (Core i3-7100 z łatkami retpoline+gcc). Co ciekawe, wcale nie ma gwarancji, że zrezygnowanie z łatek w kompilatorze zawsze da mniejszy spadek wydajności – w wypadku Ryzena 7 1800X system załatany z retpoline+gcc był sporo szybszy od tego, który miał tylko retpoline. Na procesorze AMD Epyc było już na odwrót.
  • Baza Redis w teście GET okazała się być na procesorze Core i9-7980XE szybsza o 11% po zastosowaniu samych łatek retpoline. Nieco przyspieszył też procesor Dual Xeon. Wszystko inne spowolniło, albo nie zauważyło innych zmian.
  • Serwowanie statycznych stron po Apache (Apache Benchmark) najbardziej dotknęło procesory Intela – i7-8700K stracił 10% wydajności z retpoline+gcc, Dual Xeon Gold spowolnił o 7%. AMD Epyc – przyspieszył tymczasem o okrągły 1%.
  • Benchmark, który był prawdziwym pogromem w teście łatki na Meltdown, tj. PostgreSQL pgbench, w wypadku łatek na Spectre nie wykazał żadnych zauważalnych różnic.

Spectre gorsze jednak niż Meltdown

Jakie można z tego wszystkiego wysnuć wnioski? Podobnie jak w wypadku łatek na Meltdown, załatanie Spectre powodować może spadek wydajności I/O i tych operacji, w których dochodzi do intensywnych interakcji z kernelem. Kluczowym słowem jest tu „może” – ponieważ nie musi. Z dostępnych na OpenBenchmarking.org wyników nie sposób wyciągnąć jakichś ogólnych wniosków – procesory zachowują się bardzo różnie, względem wydawałoby się nawet podobnych obciążeń roboczych.

Oznaczać to może tylko spore kłopoty dla operatorów centrów danych, chmur i usług hostingowych. W razie odnotowania problemów z wydajnością nie będą mogli zignorować detali dotyczących używanego w serwerach hardware. Może się okazać, że akurat ten konkretny model procesora po zastosowaniu domyślnych łatek (retpoline i łatki na GCC niebawem wejdą do głównej linii) powoduje drastyczne opóźnienia, podczas gdy konkurencja nie ma z tym problemu, bo akurat zastosowała inne procesory.

Wybór między Intelem i AMD stał się o wiele bardziej skomplikowany niż dotąd.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.