Výkonnostní dopad všech záplat na bezpečnostní chyby procesorů

Očekávaný výsledek...
Poslední co budete odcházet od intelu, zhasněte prosím...

No je to prusvih. Navic v beznych podminkach je celkove snizeni vykonu dane az nasobkem snizeni v jednotlivych vyuzivanych oblastech, v pripade mnoha virtualu a nested virtualizace ten celkovy propad muze jit i pod 0,5 - to pak znamena vice nez dvojnasobny cas na tutez ulohu. Takze bych docela uvital taky test snizeni vykonu v prostredi zatizeneho hypervisoru, ne na solo virtualu. - Jesteze ted nenavrhuju zadny sizing.

Mě by spíš zajímalo jak to vypadá na trojkových jádrech RHEL/CentOSu aby bylo vidět jak se jim ty backporty na ty vykopávky povedly. Predpokladam že vanilka kernel v produkci používá málokdo.

No tak tech ~7%, to uz neni zanedbatelne. To je tak rozdil jedne generace procesoru. I kdyz SkyLake/KabyLa­ke/CoffeeLake, to je vzdycky rozdil spis pul generace...

A to si pan Krčmář pro ilustraci vybral shovívavě zrovna výsledky Compile Benche. Kdyby zvolil výsledky z web serveru, musel by napsat 15 až 22 %, což je ještě mnohem zábavnější.

Tak sem si precetl puvodni clanek, a je to opravdu jeste horsi. ~20% na nginx? To sem se ted s mym novym procesorem vratil vykonem par let spatky, nekam na uroven IvyBridge!

A to pry jeste nemusi byt konec, protoze v nekterych pripadech (vm) pomuze pry jen vypnout HT nebo agresivne mazat L1-cache. Opravdu pekne "dekuju", Schweintel-e!

Je tu ovšem otázka, jestli server s nginx potřebuje ty opravy. Protože typicky nepouští cizí kód. Dopad na sdílený webhosting je pak věc druhá.

Pomalu se opravdu dostáváme do stavu, že neexistuje žádné magické nastavení bezpečnosti pro všechny a cenou za "dokonalou" bezpečnost je výkon. A tu cenu můžete nebo nemusíte chtít zaplatit.

The Performance Cost Of Spectre / Meltdown / Foreshadow Mitigations On Linux 4.19 ...
Z toho nazvu a clanku sa zda, ze autorovi ide o porovnanie testov pred a po prevaleni afery k sucasenemu obdobiu.
Avsak boli pouzite "up-to-date microcodes/BIOS". Cize testuje sa iba to, co sa da ovplyvnit na urovni OS - s uz aplikovanymi zmenami v mikrokode.
Predpokladam, ze ten rozdiel oproti minulemu roku, s povodnym mikrokodom/BIOSom, by bol este vacsi.
(Moj nazor je cisto subjektivny, nezakladajuci sa na ziadnych podkladoch.)

Vtip intelu je, že pořád inzeruje výkony bez záplat. Docela slušný propad, u AMD není tolik ovšem je tam. Ale zdatně se stím AMD popralo.

Zajímal by mne dopad ba Hypervisor od VMware - ESXi a na virtualizované desktopy Win a linux

Ono je to spíš tak, že nárůstu výkonu se dosahovalo za cenu mírného snížení bezpečnosti. ("Naše I-auto může jet i 240 km/h, když má řidič rychlé reakce. - ale vaše A-auto jen 200!") Jakmile se začne primárně tlačit na bezpečnost, tak je dopad paradoxně horší tam, kde dotáhli výkon "dál". ("Maximální povolená rychlost je 140 km/h, to znamená I-auto je o 41 % pomalejší, ale jenom o 30 % pomalejší.")
Docela by mne zajímalo, nakolik se "srovnal" výkon procesorů v jednotlivých testech.
(Poznámka: ten příklad s auty je vlastně špatně. Spíš než omezení rychlosti je to omezení výkonu nebo otáček motoru, takže dopad na rychlost je daný i dalšími konstrukčními rozdíly.)

Vždycky jsem obdivoval lidi, co dokáží srozumitelně vyjádřit svůj názor.

Ale to platí jen v případě, že je dopad oprav konstantní (maximálka 140Kph) a nezávislý na výkonu CPU. U CPU se dá očekávat, že dopad konkrétních oprav bude spíš koeficient než konstanta.

Ale jinak je to jako závodit proti sportovci který dopuje. Buď jste jeden z deseti milionů a budete dřít jako kůň, taky začnete dopovat, nebo budete mít štěstí a doping se provalí dřív, než budete na sport příliš staří.

No spíše bych to přirovnal (když už F1 někdo zmínil) k rozdílu mezi pneumatikami na sucho a na mokro. Na suchých budete rychlejší, ale jak zaprší, přestává to být bezpečné.

Intel prostě vsadil na to, že to malé teoretické omezení bezpečnosti nepůjde zneužít. AMD a ostatní sice taky, ale ne v takové míře.

Pokud tu bezpečnost zajistíte jinak, nebo ji nepotřebujete, tak můžete na Intelu využít vyšší výkon. Takové případy jsou (typicky výpočetní nebo renderovací cluster plně pod kontrolou jednoho uživatele).