Beneficiile hyperthreading-ului pentru multiprocesare?

Gestionez un nod de calcul într-un cluster HTC. Nodul este o mașină Xeon duală cu 56 de nuclee / 112 fire de execuție, iar volumul de lucru tipic constă din multe cazuri de joburi de simulare Monte Carlo cu un singur thread. Benchmark-urile arată că debitul se scalează frumos cu numărul de joburi până la aproximativ 56, cu o oarecare neliniaritate din cauza frecvențelor turbo boost care nu sunt susținute pentru un număr mare de joburi active. Toate acestea au sens pentru mine și aș spune că este comportamentul așteptat.

Lucrul pe care nu îl înțeleg pe deplin este că scalarea este aproape complet pierdută pentru un număr mai mare de locuri de muncă. Trecând la 64 de joburi și mai mult până la 112, debitul rămâne constant: beneficiul rulării mai multor joburi în paralel este complet compensat de durata mai lungă a unui singur job. Știu că scalarea este departe de a fi liniară pentru hyperthreading, dar o scalare nulă m-a surprins puțin.

Pe baza cunoștințelor mele extrem de limitate despre principiul de funcționare al hyperthreading-ului, cred că ar putea fi eficient pentru rularea a două fire ale aceluiași proces, dar nu pentru rularea a două procese separate. Aș avea nevoie de o confirmare în acest sens, pentru a exclude cu siguranță ipotezele unei defecțiuni și, în cele din urmă, pentru a dezactiva hyperthreading-ul.

Hyper threading simplificat profită de faptul că în multe fire de procesare există un timp inactiv când nucleul ar aștepta în mod normal finalizarea altor sarcini. Prin comutarea între două fire de execuție, nucleul procesorului nu va fi inactiv atunci când așteaptă într-un fir, dar poate face ceva util în celălalt thread. Vedea https://www.intel.com/content/www/us/en/gaming/resources/hyper-threading.html

În anumite sarcini de lucru, poate exista foarte puțin astfel de timp de așteptare și, astfel, un singur thread încărcă deja complet un singur nucleu. Partajarea acelui nucleu cu un alt thread nu va avea niciun beneficiu general.

Analogie proastă: Hyper-Threading sau, în general, SMT, este ca o proprietate de vacanță în timp partajat. Programarea tuturor celor 52 de săptămâni ale anului este bine, fiecare își are locul pentru sine. Aduceți mai multe persoane în program, s-ar putea chiar să funcționeze în continuare, profitați de timpul în care facilitățile sunt altfel inactive din cauza anulărilor. Dar mai multe rezervări duble nu vor transforma în mod magic o casă în două.

Miezurile CPU au mai multe tipuri de unități de execuție, întregi, virgulă mobilă și altele. Dar numai atâtea. (Diagramele bloc există pentru a le vedea în designul CPU, vezi de exemplu Lacul Cascade.) Arhitecturile suprascalare încearcă să stoarce mai multe instrucțiuni pe ceas deja. Deci, în timp ce un alt fir hardware ar putea împrumuta o unitate întreagă nefolosită pentru un ciclu, trebuie să partajeze. Iar memoria este întotdeauna prea lentă, foarte probabil DRAM și lățimea de bandă magistrală sunt adevărații factori limitatori.

Testarea creșterii treptate a numărului de locuri de muncă este o modalitate excelentă de a vedea profiturile în scădere ale SMT. Mai ales cu o sarcină de lucru grea de calcul a HTC, care probabil este destul de stabilă și previzibilă. 115% dintre procesoarele dvs. sunt aproximativ ceea ce m-aș aștepta. Nu are rost să merg mai sus.