Intel CPU, folytatás

 ( Zahy | 2018. augusztus 15., szerda - 13:21 )

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

To summarize the problem: essentially, Intel's CPUs ignore their operating system kernel page tables.

...

The processor therefore may consult the page tables to convert the app's virtual memory address to the corresponding physical RAM address. This takes time, and today's Intel CPUs will not wait for a page table walk to complete when they could be doing something more useful. They will speculatively execute code based on a copy of the requested information cached in the L1 data cache, even if the page tables specify that this data is no longer present in physical memory and thus should not be read.

Énnekem ez már magas, hogy hogy tud bármi is működni ezeken a processzorokon. Mi történik, ha a kilapozott terület tartalma - aminek a másolatát még az L1-ben őrizgeti - az közben megváltozott és azon kéne műveletet végezni, de ehelyett az L1-ben lévő kópián teszi, mert épp nincs belapozva?

Nagyjából itt tartok én is, az "even if" résznél kezdődik a jóság.

Kiváncsi lennék hogy a mai processzorok teljesítménye mennyivel csökkenne, ha az összes ilyen spekulatív megoldást kikapcsolnánk, de úgy látom ez hamarosan meg is történik.

Kiváncsi lennék hogy a mai processzorok teljesítménye mennyivel csökkenne, ha az összes ilyen spekulatív megoldást kikapcsolnánk
Úgy várhatóan kb 1/10-ed, 1/20-ad részére változna a teljesítmény.

Célravezetőbb lehet csak az out-of-order végrehajtást beáldozni a gyakorlatban az már kihasználhatatlanná teszi ezeket a fajta hibákat. Azzal csak kb 1/2 - 1/3-ra csökkenne a teljesítmény.
---
Régóta vágyok én, az androidok mezonkincsére már!

"Azzal csak kb 1/2 - 1/3-ra csökkenne a teljesítmény."

Akkor lassan lehet Hajbazer elé járulni Mea Culpára.
Ő már fél éve megjósolta a brutális teljesítmény csökkenést.

Szerintem nem fogják őket kikapcsolni. Kártyavárként dőlne össze a mai softwarevilág, ha a processzorok teljesítménye visszaesne a 15 évvel ezelőtti szintre.

+1

Akkor itt azt mondanam, hogy nem az minosul "szabad felhasznalasu" adatnak amit FB, google, meg hasonlokra feltoltesz, hanem barmi ami digitalis "szamitogepes" vilagba bekerul.

Az az erzesem, hogy ez az egesz, mer csak azert mukodik ugy ahogy, mert mindeket oldalnak az az erdeke, hogy ne doljon ossze.

Ezt a sérülékenységet kihasználni megint nem túl egyszerű. Én nem is a security részen akadtam fennt, hanem, hogy egyáltalán hogy működhet ez így.

Az lehet, hogy érdek, hogy ne dőljön össze, de a kérdés, hogy ez hogy működhetett eddig egyáltalán?

Egyszerű.

Attól működött, hogy az összes mostani sebezhetőségben emlegetett őrültség olyan futási ágon történik meg, aminek a legvégén minden logikai hatása visszatörlésre került (ill átmenetileg olyan helyen tárolódik, ahonnan nem íródik vissza). Vagyis a program tényleges lefutására zéró hatása van.

A baj az, hogy vannak nem logikai jellegű mellékhatások is, amik csak futási időre hatnak. Ilyen szempontból a (cache-elt) olvasás műveletek is mellékhatásosak. Ezt eddig nem tekintette senki problémának (néhány akadémiai elvi fejtegetést leszámítva), egészen amíg nem demonstrálták, hogyan kell kihasználni. DE, ha egy program nem kifejezetten az egyes utasítások végrehajtási idejét méregeti ns-okban, akkor semmi hatása nincs a tévesen spekulált ágaknak.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ez alapján el kell gondolkoznia a gyártónak azon, hogy valami eléggé véletlen módon amúgy helyesen-gyorsan lefutó feladatokat is késleltet.
Ez persze teljesítmény csökkenéssel jár + a bonyolultságot is növeli.
A primitív út a minden visszalassítása.

--
Gábriel Ákos

Tehát magyarán, amit változtatott az adatokon, vagy ami eredményt kapott belőle, az nem került felhasználásra?

Igen. De a lényeg, hogy mindez csak késleltetve derül ki, mivel az elágazási feltétel (legyen az egy explicit conditional branch utasítás vagy implicit, például memória lap "present" bit) kiértékelésének teljesen végig kell érnie a pipeline-on, esetleg memória-olvasásra is várnia kell (ez úgy 200-300 órajelciklus egy mai processzornak, egy nagyságrenddel nagyobb, mint a pipeline hossza). Ekkor derül ki, hogy a processzor ügyesen előredolgozott és az eredmények visszaírhatók és futás ezzel folytatható. (Az esetek 90-99%-ában ez a helyzet). Vagy feleslegesen totális baromságot csinált és minden eredményét el kell tűntetni, mintha meg sem történt volna.
---
Régóta vágyok én, az androidok mezonkincsére már!

Van pl. egy IF-ed, CPU elkezd dolgozni valamelyik ágon az alapján, ami kijött a predictorból függetlenül attól, hogy mi a kiértékelés eredménye (azon addig még dolgozik). A félkész eredményt valahova ideiglenesen elrakja. Ha a kiértékelés eredménye szerint a jó ágat találta el, akkor folytatja a munkát, ha nem, akkor meg kezdi a másikat.

Előnye, hogy - ahogy már írták 90-99%-ban - a jó ágat találja el, így tud párhuzamosítani dolgokat és még mindig kevesebb idő a rontott becslésekkel együtt összességében, mintha mindig bevárná a kiértékelést. Ebben egyébként ma már a fordítók is próbálnak aládolgozni a processzoroknak, hogy olyan kódot fordítsanak, amit a CPU jól tud prediktálni.

Hátránya, hogy önmagában elenyésző (CPU órajelek száma kb.), de mérhető módon észrevehető, hogy ha rossz branchet választott a CPU és újra kell kezdeni a számítást. Ezt használják ki.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

https://www.7-cpu.com/cpu/Zen.html
Branch misprediction penalty = 19 cycles

Nem mondanam elenyeszonek, ha mindig rosszul tippelne, pl. gzip 3x lenne lassabb.

Nem az idot hasznljak altalban, hanem cache mert hatast (mi veszett el, mi kerult be),
a cachebol valo elerest merik..


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Remélem megvan, hogy az a lényeg, hogy a sum(időnyereség jó predikciónál)/sum(mispredictionok általi veszteség) legyen nagyobb, mintha nem lenne prediction, így meg igazából mindegy, hogy sok vagy kevés?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

ez a foreshadow bug?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Közben megjött a Phoronix-en az első benchmark is:
https://www.phoronix.com/scan.php?page=article&item=l1tf-early-look&num=1

Valós workload-nál nem túl vészes, inkább microbenchmarkokban mérhető ki, illetve adatbázisszervernél érezhető a hatása.

Az SMT letiltás, ami nagyon fáj. Azt még alaposabban körül kell járni, hogy ütemező okosításával (azonos fizikai magon futó threadeket gang-scheduling-el mindig párban adni VM-nek) illetve ügyes CPU pinning konfiggal (lásd openstack-ben: hw:cpu_thread_policy=isolate flavour-key) elkerülhető-e az SMT letiltás.
---
Régóta vágyok én, az androidok mezonkincsére már!

Lassan visszajut a vilag oda, hogy meg kell tanulni a fejlesztoknek programozni ?
Nem lesz eleg csak mukodik jovan kodot generalni.

Varom.

Ezt miből szűrted le?

Egyszerű, minden egyes, a fentiekhez hasonló bug javítása lassítja a procikat. Ha a proci lassú, akkor a kódon lehetne optimalizálni.

Ha egy proci lassú akkor több proci kell. Problem solved.
--
Gábriel Ákos

Egy nem párhuzamosított algoritmusnál mire mész velük?

Ha egy proci lassú, lassítsuk le az I/O-t és a memóriahozzáférést, és máris nem a proci lesz lassú.

Ugye azért valahol mélyen te is érzed, hogy nem mindent lehet több darabszámú procival felgyorsítani?

/*
Csak úgy eszembe jutott: anno volt egy UNIX Performance tuning tanfolyama az egyik nagyon nagynevű Jujniksz-gyártónak(*), ahol egy fantasztikus feladaton mutatták meg, hogy milyen baromi jó - és főleg könnyű - dolog ha egyszálúan megvalósított programot átvarázsolunk multi-thread-esre. Elővették az Eratosztenészi-szitát prímkeresésre, bemutatták hogy milyen baromi egyszerű C-ben lekódolni (nyilván nem a C volt a lényeg), és szépen lépésről lépésre végigvezették, hogy mi módon lehet ebből kurva hatékonyan MT-kódot előállítani. Volt egy fő szál, aki csak osztogatta a vizsgálandó számokat, illetve a visszakapott találatokat gyűjtögette és sorbarendezte (majd a legvégén kilistázta), meg voltak a vizsgáló szálak. A végeredmény nagyon korrektre sikeredett: a féloldalas, átlátható C-kódból lett egy kb 3-4 oldalas, messze nem annyira átlátható valami; ami ráadásul az oktatási környezet gépein természetesen lassabban futott, ugyanis kissé kevéssé volt jellemző az 1-2-nél több proci / több szál. Ez a példa nyilván nem azt bizonyítja, hogy a szita alapú prímkeresést nem lehet párhuzamosítani, de az adott környezetben oktatóként nagyon nehéz volt bárkit is meggyőznöm, hogy milyen marha jó ötlet.
*/

Ellenben mint más is jelezte, nem mindent lehet párhuzamosítani, és nem mindenhol tudják meglépni a több-procira áttérést.

(*) előbb egy PC-gyártó, aztán egy nyomtatógyártó kebelezte be őket

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Tegyük hozzá azt is, hogy az, hogy mi volt anno az nem felt3tlen releváns. Egyrészt maguk a nyelvek, módszerek is sokat fejlődtek (ld. .NET-ben az async API*, TPL vagy a funkcionális nyelvek előretörése, immutable adatszerkezetek használata, mert egyszerűbb velük az élet párhuzamos környezetben, lock-free adatszerkezetek megjelenése, stb.) másrészt meg elosztott rendszert is könnyebben építesz: egyre többféle MQ, elosztott db, vagy más célszoftver áll rendelkezésre, amivel jóval egyszerűbb az élet.

* most attol tekintsünk el, hogy retardált lett tőle a syntax

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Valószínűleg arról van szó, hogy a szekvenciális programfuttatás teljesítményének eléggé a határaihoz értünk. A mai szintet is kisebb-nagyobb "csalásokkal" lehetett csak elérni és most némelyik csalásról kiderül, hogy nem elég jó.

Innen továbbskálázni csak a párhuzamosítás irányába lehet. Ebbe az irányba viszont közel sem fejlődött a szoftveripar annyit amennyit kellett volna.

Persze ebben bőven benne volt az Intel keze is, azzal, hogy a mainstream piac ~8 éven át 2C/4T, 4C/4T nagyon esetleg 4C/8T processzorokkal volt lefedve -> ezidő alatt nem volt motiváció 4 szál kihasználása fölé optimalizálni a fejlesztőknek, mert az ügyfélkör túlnyomó részénél úgysincs 4 szál futtatásánál vastagabb hardver.

Több szabvány (a h265 jut hirtelen eszembe, mint jellemző példa) is ilyen előfeltételezéssel lett specifikálva, vagyis ha akarnák sem tudnák nagyon párhuzamosítani implementáció szintjén. Sokmindenen kéne változtatni tervezés szintjén is.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ez home pc világban lehet, hogy így látszik, de amióta van többcpu-s gép (sőt ugye cloud) azóta az algoritmusok kb. végtelen párhuzamos szálon futhatnak, erre is optimalizálnak.
Szűkös környezetben lehet konfigurációs paraméter a szálak száma, hogy ne szívassuk az infrastruktúrát feleslegesen akkor se ha az algoritmus szerint érdemes lenne több szálat indítani mint amennyit az adott környezet elbír.

--
Gábriel Ákos

Ha ez ilyen egyszerűen menne. Végtelen párhuzamosság. Aha, persze. Hálózati sávszél meg az IO az meg már smafu. Futottunk már bele abba, hogy hiába volt elég CPU-nk (bőven), kevés volt a cloud szolgáltatónk sávszélje a gépek között.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem tudom értetted-e a lényeget.
Ha a célpiac 95%-a 4 threadet tud, akkor a product management nem fog fejlesztői erőforrást allokálni, hogy átdolgozzák (újratervezzék) a szoftvert kvázi-végtelen párhuzamos szálra.

Vannak algoritmikus korlátok is, gondolom tisztában vagy vele, hogy nem minden algoritmus párhuzamosítható. Gondolom azzal is, hogy a használt adatszerkezet sokszor meghatározza az algoritmust. Valamint azzal, hogy a párhuzamosításnak van - többnyire kommunikációs, szinkronizációs jellegű - overheadje is, és nagyon esetfüggő, hogy ez a szálak számának milyen függvénye. Fentebb írta Zahy a tanmesét rá, ahol a párhuzamosítás nettó veszteséget okozott, mert az aszinkron feladatszétosztás és eredményvisszagyűjtés nagyságrendileg költségesebb volt, mint az alapfeladat.

Van ahol csak nagy szálszámnál kezdi el megérni (jelentős konstans tényező az overheadben), és van ahol nagy szálszámnál elszáll az overhead (jelentős a lineárisnál nagyobb hatványú tényező az overheadben), nagyon változó hol az optimum, egyáltalán létezik-e olyan tartomány ahol megéri.
---
Régóta vágyok én, az androidok mezonkincsére már!

Chipzilla ismét alkotott. Le kellene sittelni pár döntéshozót ezeknél, megérdemelnék.

Nem az Arm fújja a szelet az intel bugok világgákürtöléséhez? Akár igen, akár nem, nekik ez most nagyon jól jön, hogy a PC piac a célpont.

Bugok egy részében az ARM is érintett.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™