HyperThreading a škálování při kompilaci a OpenSSL

11.1.2011 12:14 | Přečteno: 2050× | Hardware | | poslední úprava: 11.1.2011 12:20

Před časem jsem zkoumal škálování kompilace na počítači s osmi fyzickými jádry. Vznikla otázka, jaký rozdil je mezi osmi fyzickými jádry a mnohonásobně levnějším řešením se čtyřmi jádry a HyperTheadingem. Konečně se mi dostal do rukou stroj se Sandy Bridge procesorem, na kterém to můžu důkladně otestovat.

Testovací sestava

Intel 2600K (3.4 GHz, Turbo záměrně vypnuté aby nám při měření nemíchalo s výsledky), 16GB DDR3 1333MHz, P67 chipset, Kingston 128GB SSD Now V100, nVidia 570GTX.

Software

Tentokrát jsem nepoužil Gentoo ale Arch. Ano, ano, dospěl jsem. V jednatřiceti- bylo na čase. gcc 4.5.2, jádro 2.6.37, x86_64

Metodika

Překládám vanilkové 2.6.37 s implicitním "Linusovým" .config. HT vypínám v BIOSu. Celý proces kompilace v ramdisku. Měřím přes time make -jN.

Výsledky

Dobré je, že HT při -j2 a -j4 nezpomaluje. Tato situace by teoreticky mohla nastat, kdyby scheduler chybně rozhazoval jednotlivé úlohy. Špatná zpráva je, že zatímco osmijádro kompiluje 1,87x rychleji než čtyřjádro (viz výše odkazovaný článek), tak v případě přidání HT proběhne kompilace pouze 1.2x rychleji.

OpenSSL

Výsledky signs/s pro 2048bit rsa, 1.0.0 c, bn(64,64)

Rovněž zde je vidět, že se graf s HT při multi 4 výrazně láme. Na skutečném osmijádru je charakteristika prakticky lineární až do multi 8 neboť to je jedna z mála úloh, které škálují takřka ideálně.

Závěr

Žádné překvapení- virtuální jádro se ani náhodou nemůže reálnému jádru vyrovnat. Díky tomu může být highend ze začátku roku 2008 stále rychlejší než "vyšší střední třída" ze začátku roku 2011. Na druhou stranu 20 % výkonu navíc je lepší než nic. Rozdíl mezi 2500K a 2600K je hlavně v HT takže pro zájemce o některý z těchto procesorů by to mohla být zajímavá informace.

Tento kousek budu mít ještě nějakou chvíli u sebe takže můžu něco vyzkoušet pokud budete chtít. Integrovanou grafiku ale nevyzkouším- s použitým chipsetem to není možné.

       

Obrázky

Komentáře

[Vskutečnosti Saýc]

Dobra prace!

[Semo]

Kedysi este tusim na Prescotte s jednym realnym jadrom a HT bol rozdiel pri kompilacii jadra cca 7.5 minuty bez HT a 6.5 minuty s HT.

[jb]

Na porovnani(pridani vysledku) by se mi hodilo, kdyby jsi prilozil svuj (nebo jak se zminujes 'linusuv') config. Me se make menuconfig konfiguruje podle configu distribucniho kernelu.

[miho]

Tady se daji prilozit jen obrazky tak jsem to nahral na ulozto: http://www.ulozto.cz/7354447/config

[Heron]

Ke komentáři lze přiložit cokoliv do velikosti 2MB. Nejen obrázky.

[Michal Kubeček]

Me se make menuconfig konfiguruje podle configu distribucniho kernelu.

To proto, že máte jádro přeložené tak, aby obsahovalo svou konfiguraci. Pokud ne, použije se "Linusův" default, který mají všichni stejný. Otázka ale je, jestli autor skutečně použil ten default nebo jestli nevědomky překládal s konfigurací distribučního jádra.

[Michal Kubeček]

Podle časů bych tipoval spíš první možnost.

[jb]

Dekuji za navedeni. V knizce Linux Kernel in a Nutshell to i pisi, ze k vygenerovani default, tj. to co pouziva kernel maintainer, je potreba: make defconfig. Porovnanim obou souboru jsem zjistil, ze autor tohoto clanku skutecne pouzil "Linusuv" default.

[jb]

Vysledky na ( Phenom X6 1055T (s turbem); HDD 7200rpm; Fedora 14 amd64; gcc 4.5.1 20100924 ):

format (prikaz : real, user, sys):

make -j1 : 7m46.623s , 6m33.340s , 1m29.837s
make -j2 : 4m 3.530s , 6m49.002s , 1m32.767s
make -j3 : 2m50.286s , 7m 4.785s , 1m35.060s
make -j4 : 2m13.278s , 7m22.713s , 1m25.566s
make -j5 : 1m43.267s , 7m 4.842s , 1m11.597s
make -j6 : 1m28.963s , 6m54.521s , 1m 1.791s
make -j7 : 1m29.925s , 6m56.535s , 1m 2.248s

[User682]

zdravim,

mam tu Phenom 1075t a vychazi mi podstatne horsi casy (2:15 min, vlastni kernel, pameti 1333Mhz, vse cteno z pameti). Na jake frekvenci Vam bezi pameti ?

diky gf

[jb]

Mam nejobycejnejsi kingston bezici na zakladnich 1333MHz. Procesor je taky na zakladni frekvenci + turbo. Kernel mam distribucni.

[User682]

zdravim,

tak ted to jiz sedi. Pokud se pouzije make defconfig a potom make -j 6 , tak to uz dava rozumne vysledky na 1075t.

Prvni kompilace i s ctenim z disku: 1:35

Druha kompilace i s ctenim z disku: 1:15

Co tu mam vlastni kernel a konfiguraky, tak to trva "podstatne" dele. Asi by se to dalo stahnout o nejakou vterinu - poslouchal jsem jeste nejakou hudbu a bezel mit tu htop. Detaily....

gf

[User682]

zdravim,

ted resim zprovozneni vcera zakoupeneho AMD Phenom x6. Tak jsem zvedavy, jak to dopadne v porovnani s Intelem co se tyce kompilace jadra.

Jinak diky.

gf

[Grunt]

Ne, jak je to jen možné?

[kralyk z abclinuxu]

Zas Grunt je nespokojený
Jasně, že se výsledek dal čekat, ale pěkné je, že máš poruce čísla, takže až zas někdo řekne nějaké to [Citation needed], může se to hodit...

[Grunt]

Use the Source, Luke.

[menphis]

dobra prace,do ted docela me zajimalo kolik % vykonu prida HT v linuxu navic.

jinak pekny pc, to mas na hry?

[brk]

Vrazit tolik prachů do CPU, které neumí ani VT-d mi připadá jako docela slušný úlet. Na co si to kdo pořizoval?

[Michal2]

Divny dotaz. VT-d uzije odhadem tak 2% populace. Takze zbyvajicich 98% na cokoliv.

[Grunt]

Ne. Pokud mobilní telefon i přesto všechno co umí neumí uklidit, oprat a uvařit, tak to není mobilní telefon, ale krabice k ničemu.

[Thunder.m]

Intel Core i7 2600 už mám taky, on je tam ještě rozdíl ve velikosti cache, která je místo 6MB rovnou 8MB, to udělá rozdíl ve výkonu vyšší, ale je fakt že rozdíl v ceně za ten výkon navíc spíš nestojí.

[Vskutečnosti Saýc]

Me by ten rozdil ve vykonu docela zajimal. Pokud vim, L3 se na modernich intelech pouziva primarne na rychly IPC, takze si nejsem jistej, jestli ho nekde jinde mimo zatizeny servery vyuzijes. Stalo by to za to zmerit.

[Trained.Monkey]

Zakladni vyhoda virtualnich jader je lepsi interaktivita s IO operacemi na desktopu.

Pokud mate OS se spatnym multitaskingem (WinXP, Linux 2.6), tak ten pri kopirovani ztrati hromadu casu cekanim na IO operace. A virtualni jadro v tomhle pomoze, protoze druhe muze porad pokracovat.

[Michal2]

Co to tady pises za humorne vymysly. Kdyz proces ceka na IO, tak se uspi a na stejnem jadru muze bezet jiny proces a zadne virtualni jadro k tomu nepotrebuje.

[Kvakor]

Ano, HT nemá s čekáním na I/O operace nic společného, to systém dokáže smyslupně využí HT ne-HT. Na druhou stranu, důvod, proč "virtuální" jádra byla zavedena, je čekání procesoru na pomalou paměť. Například Pentia 4 měla dvacetistupňovou frontu dekódování istrukcí a pokud se nějaký skok či volání nepovedlo odhadnout dopředu (tj. předvídání skoků selhalo), tak se musela celá fronta vysypat a znovu "naládovat", což mohlo v extrémních případech trvat i stovky tiků hodin. A celou tu dobu zbytek procesoru stojí a fláklá se. Kdežto s HT se přidá víceméně jen další fronta plus registry, takže zatímco jedna fronta čeká na paměť, druhá může vesele běžet. Navenek se tím trochu zvýší výkon, ale při pohledu zvnitřku je to jen využití času, který by jinak procesor trávil čekáním.

[pavlix]

Tentokrát jsem nepoužil Gentoo ale Arch. Ano, ano, dospěl jsem.

Každý puberťák si myslí, že dospěl :).