Hlavní navigace

Vlákno názorů k článku Linuxová záplata na Spectre v2 způsobuje až 50% pokles výkonu od Petr M - No kdo by to byl řekl, že pokud...

  • Článek je starý, nové názory již nelze přidávat.
  • 23. 11. 2018 7:28

    Petr M (neregistrovaný)

    No kdo by to byl řekl, že pokud sdílím funkcionalitu s ukládáním stavu, sdílím i ten stav...

    Pokud už něco sdílet (bez ohledu na to, jestli HW nebo SW) , tak samostatnou instanci, nebo bezstavovovu variantu, která nic nikam neukládá. Za předpokladu, že nechci sdílet ty data.

    Můžu sdílet třeba shifter, data protečou v jednom taktu a jsou fuč. Můžu sdílet ALU, data protečou a jsou pryč. Ale koho sakra napadlo sdílet branch prediktor (který se učí = pamatuje si předchozí stavy) a cache???

    I při psaní programu v blbým Cčku, pokud mám několik vláken, musím přece přemýšlet, jestli ta vnitřní stavová proměnná ve funkci má být statická, nebo jí to dávat zvenčí argumentem. První možnost je rychlá, druhá bezpečná.

  • 23. 11. 2018 8:22

    Jerry (neregistrovaný)

    Koho napadlo sdílet cache nevím, ale pokud bylo cílem maximalizovat výkon multithreadové aplikace, která něco počítá, tedy vlákna přistupujou ke stejným datům a provadí stejný kód, pak je ta volba celkem logická!
    Blbé je samozřejmě tohle všechno, když na procesoru mohou běžet nepřátelské procesy, které využijou každé slabiny, aby se dostali k informacím, ke kterým normálně nemůžou.

    Těžko říct, zda tohle dřív nikoho nenapadlo nebo to ignorovali, ale předpokládám, že spekulativní provádění, cache a další principy vznikaly v době, kdy se na bezpečnost hledělo dost jinak. Vůbec bych se nedivil, kdyby před lety vývojáři dostali zadání, že klíčový jen výsledný výkon (skóre v benchmarcích) a teoretickými blbostmi, které "nikdy" nenastanou, se nemají zdržovat... nějaké roky vše hezky fungovalo, začalo se to používat všude... hups a najednou je všechno špatně. :-)

  • 23. 11. 2018 9:38

    Petr M (neregistrovaný)

    "Koho napadlo sdílet cache nevím, ale pokud bylo cílem maximalizovat výkon multithreadové aplikace, která něco počítá, tedy vlákna přistupujou ke stejným datům a provadí stejný kód, pak je ta volba celkem logická!"

    Není. Nastuduj si "Race Condition"! Nemůžeš pustit dvě vlákna na stejný data, pokud minimálně jedno z nich zapisuje. A pokud se data liší, liší se automaticky i obsah D-cache, registrů,... Shoda branch prediktoru je i v tomhle případě spíš sakra velká náhoda, protože skoky vyhodnocují obecně nějaký různý data. A to i v případě, že nějakou náhodou je shodná I-cache.

  • 23. 11. 2018 10:23

    Jerry (neregistrovaný)

    Nemyslím, že by mělo cenu hádat se o drobnosti, určitě existujou situace, kde to výhodnější bude. Třeba tím, že se data a kód načtou z RAM, když je potřebuje první vlákno, druhému mohou aspoň z části přijít vhod.
    Pochopitelně vlákna nemusí hrabat přímo na stejný byte, aby cache byla přínosem, navíc spousta dat se opravdu jen čte, o těch skocích by se taky dalo diskutovat... ono je to jedno, prostě se na začátku tohle řešení mohlo jevit tak, že v určitých situacích bude výhodnější a ničemu neškodí... zatímco teď už víme, že škodí velmi. :-)

  • 23. 11. 2018 12:21

    Petr M (neregistrovaný)

    Může, většinou na umělé zátěži v benchmarku.

    V praxi stačí splnit jenom několik "triviálních" podmínek:
    1) Musí to být dvě vlákna v rámci jednoho procesu. Jiný proces = jinak mapovaná "velká RAM" = CPU neví, že je tam to samý.
    2) Vzhledem k velikosti I cache musí být vlákna hodně přesně synchronizována.
    3) Nesmí do toho kecat kernel a přehazovat vlákna, zastavovat je,...
    4) Musí se jednat o zpracování (= kompletní řetězec read - modify - write). Vstupní operace, výstupní operace a přesuny přes CPU jsou výkonový nesmysl, to si řídí DMA efektivněj.

    Takže v praxi - překódování videa (na GPU je na to víc jader a HW akcelerace), počítání dlouhé řady hashů (věc, kterou na HT opravdu nechceš dělat kvůli bezpečnosti) a podobný opičárny.

  • 23. 11. 2018 12:25

    Palo (neregistrovaný)

    To s tym DMA mate ako nejaku aktualnu informaciu? Lebo uz par rokov dozadu bol CPU na tieto operacie rychelsi ako DMA. To ze samozrejme cez DMA umozni CPU oddychovat je obcas vyhoda ale nie vykonova.

  • 23. 11. 2018 12:30

    Petr M (neregistrovaný)

    Ono hlavně PCIe tak nějak funguje na principu DMA samo, takže k přesunu dat SATA-RAM, Ethernet-RAM nebo Grafika-RAM si CPU vůbec nečuchne, jenom ovladač skrz CPU řekne kartě, co a kam přesunout a ono se to tak nějak stane.

    Např. podle SATA specifikace požadavek na čtení dostane adresu ve fyzické RAM, kam ty data doručit.

    Proto píšu, že přesuny a I/O operace na CPU už ani nemají smysl.

  • 23. 11. 2018 11:08

    MasoxCZ (neregistrovaný)

    "Vůbec bych se nedivil, kdyby před lety vývojáři dostali zadání, že klíčový jen výsledný výkon (skóre v benchmarcích) a teoretickými blbostmi, které "nikdy" nenastanou, se nemají zdržovat... "

    A já myslel, že varianta "obchodní rozhodnutí maximalizovat výkon a minimalizovat cenu" výměnou za tehdy pouze spekulativní snížení bezpečnosti bylo jako správná hypotéza dávno potvrzeno.