Vlákno názorů k článku Linuxová záplata na Spectre v2 způsobuje až 50% pokles výkonu od Rhinox - Resenim je proste se na HT vys*at! Bylo...

Resenim je proste se na HT vys*at! Bylo to dobry jako takovej "falesnej" a levnej multiprocessing v casech, kde dvou-jadro bylo vrcholem nabidky. Dnes kdyz mam k dispozici i pro desktop levne 6-8 jadrove CPU uz HT nepotrebuju.

Pro vps-hosting to samy. Dnes jsou k dispozici levne >20 jadrove CPU, tak proc se trapit s HT a riskovat ze se objevi naka bambilionta verze spectre? Tohle je skratka slepa vetva vyvoje, a budouci generace CPU by mela byt bez HT. Narust vykonu minimalni, nestoji to za ty problemy...

btw, mam tady v praci 2x Xeon 4114 (20 cores + HT). Testoval sem na reseni velkejch soustav rovnic metodou ktera pekne skaluje s poctem CPU. Meril sem celkovej cas, a 20cores+HT bylo o ~3% rychlejsi, nez kdyz sem pouzil jenom 20cores. Naco tedy HT? Na nic! Pohrbit tuhle vec, a jede se dal...

Ta tak. Kdyby vykopli HT a flákající se jednotky použili místo branch prediktoru tak, že se pojedou do rozhodnutí obě větve v rámci dvou pipelines. Pak výkon nezávisí na skoku (volí se jeden nebo druhý zpracovaný výsledek) a vnější pozorovatel vidí načtení cache za podmínkou ať je splněná, nebo ne. A nikdo cizí paralelně s taskem nesdílí stavový informace. A kernel při výměně threadu prostě musí uklidit tak jako tak.

Ale pokud se bude spekulovat nad víc než jedním větvením (1. větvení = 2 větve; 2. větvení = 4 větve atd. geometrická řada), tak by se podvětvení stále daly IMO nějak natrénovat.

Větvení je problém kvůli pipeline, že se musí zahazovat co už je hotovo. Pokud je pipeline s 10 řezy, zpracovává 10 (mikro) instrukcí. Když se skok vyhodnotí jinak, těch 10 rozpracovaných instrukcí se zahodí. Branch prediktor se snaží tohle zahazování omezit.
Pokud za skokem další skok následuje po >= 10 instrukcích, vystačíš si s dvěma "pipelinama" pro zpracování, protože při další podmínce je už předchozí slepá větev zahozena.
Při < 10 instrukcích by se holt muselo v té větvi interně vložit pár NOPů, ale furt lepší tři NOPy, než zahozených 10 instrukcí.
Průšvih by to byl akorát v případě cyklu s <10 instrukcema, tam by se musel proložit NOPama a výkon by šel trochu dolů. Tam BP dává lepší výsledky.

Jo to by šlo. Co jiná vlastnost a to že pokud by dneska branch prediktor předpověděl dobře a zároveň pouze ve špatné (= nepředvídané a nepředpočítávané) větvi by bylo plnění cache, tak se ušetří tak stovky taktů kdy by se při špatné předpovědi muselo čekat na RAM?

Nesmysl. To je totéž jako tvrdit, že stejně nesmíš v ČR jezdit víc než 130, tak se všem autům vyndá z jednoho hrnce píst, aby to nikoho ani nenapadlo. Hardware prostě umožňuje efektivnější využití hardwaru a tím zvýšení výkonu výměnou za snížení bezpečnosti, takže ať si každý zvolí co mu s ohledem na jeho potřeby vyhovuje. Samozřejmě je lepší informovaný souhlas a jako výchozí bezpečnější nastavení, ale je kokotina to zatrhnout natvrdo jen proto, že jseš paranoidní a nechceš, aby v NSA viděli jak ti jdou miny a na jaký porno koukáš.

Sice fajn myšlenka, ale problém je, že tady to přepnout prostě nejde.

Prodali ti bezpečnostní dveře, který sice odolají střelbě ze samopalu, ale nemají kvůli rychlejšímu otevírání zámek (hledání klíčů a strkání do dírky přece zdržuje) a ten se ani nedá doinstalovat. Tak se na ně montují petlice a když chceš zamknout zevnitř, musíš napřed ven oknem, odemknout a vrátit se oknem dovnitř. Což je mnohem pomalejší, než kdyby tam ten zámek dli rovnou.

A momentálně vývojáři přemýšlí, jak udělat do dveří díru, skrz kterou bys dosáhl na zámek u té petlice, aniž by utrpěla neprůstřelnost.

Jenomže oni to tak udělali proto, že to zákazníci chtěli, a pořádný dveře odmítali kupovat. Fakt pochybuju, že by IT a následně prakticky všechno bylo tam kde to teď je bez toho, že by posledních 20 let byly k dispozici dostupný procesory. Myslíš, že by v každý rodině byla SPARCstation a každej člen rodiny by měl v kapse SPARCphone, a jupíci by si před roštěnkama ve školní jídelně šudlali iSPARCmini?
Bylo by to na úrovni katolickýho školství v době Jiráskova Temna.

Súhlasím, HT je overrated. Skúšali sme paralelný fingerprint matching na 12 cores+ht a pri paralelizme 12 prestal výkon stúpať. HT som vypol na svojich všetkých masinach.

To by me taky zajimalo, jestli testoval nekdo ten patch i na nativnim non-ht cpu? Jestli se desit toho co jadro 4.20 prinese nebo byt v klidu:)

Nebude to náhodou záležet na architektuře konkrétního CPU? V hlavě to nenosím, ale pokud by cache byly mezi fyzickými jádry sdílené, tak si dovedu představit, že by některé varianty útoků mohly fungovat i bez HT.

2MasoxCZ: A samozrejme taky fungujou, protoze v CPU se sdili prakticky vse. V dalsim kroku se totiz bude resit, ze vsechny CPU pristupujou do stejny RAM. A kupodivu, si tam kazdej jeden muze precist a zapsat co chce a kam chce. A pak se s prekvapenim zjisti, ze to vsechno pouziva jeden disk, o kterym plati totez.

Hyperthreading nie je urceny pre ulohy, ktore jednostranne vytazuju len urcity typ vypoctovyvh jednotiek v CPU ako je riesenie rovnic (FPU jednotky). HT vylepsuje celkovy vykon systemu, kde bezi mix rozlicnych uloh, ktore rovnomerne vyzivalju rozlicne typy jednotiek (FPU, integer, load/store...), vtedy sa da dosiahnut navysenie vykonu o 30-50%.
Je samorejme, ze "skutocne" jadro je ovela lepsie ako to z HT a suhlasim s tym, ze v pripade dostupnosti viacjadrovych procesorov straca HT postupne zmysel. Napriklad POWER8 procesor podporuje SMT8 (to je IBM nazov pre HT - Symetric Multithreading s 8 threadmi na core) ale da sa to v systeme (v AIXe) za chodu menit na SMT4, SMT2 alebo sa da HT uplne vypnut a administrator tak moze odladit vykon systemu podla uloh ktore tam bezia.
POWER9 sa uz dodava v dvoch verziach alebo s SMT8 alebo s maximalne podporovanym SMT4, ktory ma ale na cipe 2x viac jadier ako verzia s SMT8.

Tak mi rekni, jak dokaze beznej uzivatel vytizit cpu s 10 cores + HT? Samotne efektivni vyuziti 10 jader neni tak jednoduche, to musi byt aplikace specielne napsana a nekdy to ani nejde.

Tak naco ma byti na cpu s 10 cores jeste HT? Ja bych bral radsi 12cores bez HT za stejnou cenu (coz by snad plochou cipu mohlo byti +/- na stejno)...

dvě slova: Windows Update.

Běžný uživatel nevytíží ani deset jader. Chyba byla, že si vůbec takový procesor koupil. Zda to má nebo nemá HT na té chybě nic nezmění.

Tolik jader a ještě s HT si bude pořizovat někdo, kdo provozuje třebas virtuálky nebo webový server, který v jednu chvíli obsluhuje desítky požadavků. Prostě na něco, co samo o sobě obnáší desítky vláken, každé dělající něco jiného nebo v jinou chvíli.

Na paralelní výpočty je lepší maximalizovat počet jader * frekvence. HT pomůže jen v hodně specifických paralelních úlohách, které vyžadují jednotky, které jsou skutečně zdvojené (příkladem budiž zpracování textu). Jenže většina zátěže půjde po věcech jako jsou FPU a tam na sebe ta vlákna budou čekat, protože FPU je pomalejší než jedno vlákno. A obvykle jich tam není tolik, aby to upočítalo vlákna dvě.

Takvej beznej user si pusti trebas ... hru ... a takova hra mi naprosto klidne (netvrdim ze efektivne) sezere i 16 jader na 80+% ... a takovej benzej BFU ma 4/6/8 jader i ve svym patlafounu.

Pri konverzii videa dokazem bez problemov vytazit 8 jadier na Ryzen 7. Verim tomu, ze by sa dalo vytazit aj 10 alebo viac jadier.
HT ma ale zmysel hlavne na servroch, kde bezia rozlicne typy uloh, kde ale zase kvoli bezpecnosti HT nie je vhodny :-)

A jakej rozdil v rychlosti konverze je, kdyz pouzivas HT, a kdyz HT zablokujes (i kdyz HT na AMD neni to same co HT na Intelu)? Kazdopadne ja osobne bych bral radsi 9 plnohodnotnejch jader, nez 8+HT...

Dobre napsana rekomprimace videa? Ta by mela umet vytizit libovolny pocet jader (proste tim, ze video rozseka na vic casti). A stejne tak i dalsi ulohy, ktere se daji rozsekat na vice casti.

Wow, sběrač kovu, já už jsem fyzický server neviděl ani nepamatuju :-)

Ja taky ne. Tohle je muj pracovni desktop! :-)

Vypnuti HT je ostatne take prvni vec, kterou na Intel based pocitacich delam.