WinRAR

WinRAR 3.51

Pokud se ptáte, proč testujeme s WinRARem 3.51, který neumí využít více jader, odpověď je snadná. Testovat jsme začali až s procesorem Core 2 Duo a to ještě tak nešťastně, že právě s touto verzí a nikoli s 3.6, která již více jader využít umí. Takto vypadá práce s WinRARem 3.51 ve čtyřjádrovém procesoru:

Vesměs jakoby pracovalo stále jen jedno jádro, i když se některá další občas střídají. Z tohoto pohledu dopadlo čtyřjádro ještě překvapivě dobře.

Vliv počtu jader na běh vícevláknové aplikace

WinRAR 3.61

Nadělali jsme si však do zásoby testy s WinRARem 3.61, který už multithreading podporuje, a zkusili s ním jeden takový zajímavý trik. Co se stane, když necháme WinRAR 3.61 běžet na různých jádrech? Označme si je pro jednoduchost jako 0, 1, 2 a 3. Předpokládejme, že jádro 0 necháme samotnému systému, který toho sice sám o sobě moc nenadělá, ale brzdit by nám WinRAR mohl. Zkusíme tedy nechat WinRAR běžet na jádrech 1+2, dále 1+3, 2+3 a jako poslední situaci si dáme 1+4. A srovnáme to i s během na všech čtyřech jádrech. Názorná ukázka zatížení procesoru ve zmíněných situacích:

Jádra 1+2 Jádra 1+3 Jádra 2+3 Jádra 1+2+3 Jádra 0+1+2+3

Ptáte se, co nás k tomuto testu vedlo? Procesor se skládá ze dvou čipů a jen dvě a dvě určitá jádra spolu sdílejí kus L2 cache, zatímco jiná dvě a dvě jádra nikoli. Pokud se nám podaří trefit situaci, kdy WinRAR běží na dvou jádrech, která spolu nesdílejí L2 cache, asi by měl být výsledek jiný než za situace, kdy WinRAR poběží na dvou jádrech, která spolu L2 cache sdílejí. Problém je jen ten, že neumíme odhadnout a spárovat jádra podle fyzického umístění v procesoru ;-). Ale můžeme to zkusit vydedukovat.

Budeme-li vycházet z faktu, že Windows vidí procesory jako tzv. APIC ID a řadí je v systému zleva doprava od 0 do 3, pak se dá říci, že dvě jádra sousedící vedle sebe ve správci úloh vlevo sdílí jednu část L2 cache a druhá dvojice vpravo sdílí druhou část L2 cache. Ono by to ostatně platilo i v případě, kdyby byla jádra řazena podle APIC ID zprava, jenže tak to nebude, protože možnost nastavit spřažení (tzv. „Affinity“) ve správci úloh jasně ukazuje, že zakážeme-li aplikaci používat „CPU 0“, spadne zatížení prvního grafu zleva. Obdobně to pak funguje i u ostatních jader.

Pokud se ještě ptáte, jak můžeme vědět, že APIC ID 0 a 1 představují jádra na stejném kousku křemíku a tedy spolu sdílejí L2 cache, odpověď nám poskytne možnost vypnout v BIOSu Core Multiplexing Technology. Vypnutím dojde k vyřazení druhého jádra na obou kouscích křemíku, čímž se procesor tváří jako dvoujádrový a každé jádro má pro sebe vlastní nesdílené 4 MB L2 cache. CPU-Z 1.35 v takovém případě ukazuje přítomnost pouze „Core 1“ a „Core 3“, která mají za normálních okolností (při zapnuté Core Multiplexing Technology) APIC ID 0 a 2.

Výše nastíněné modelové situace běhu multithreadového WinRARu 3.61 na vybraných jádrech se tedy podle této teorie dají také vysvětlit takto: Situace „1+2“ rovná se běhu na dvou jádrech, které spolu nesdílí L2 cache a každé by mělo mít celé 4 MB. Totéž by měla představovat situace „1+3“, kde se jen ze druhého kousku křemíku používá druhé jádro místo prvního, jinak žádná změna. Situace „2+3“ by však měla představovat běh WinRARu na jednom kusu křemíku, kdy obě jádra sdílejí L2 cache. Aby nám výsledky neovlivňovalo zpomalování „málo zaměstnaného procesoru“, bylo vypnuto šetření energií EIST, aby procesor stále běžel na 2,66 GHz. A tady jsou výsledky.

Nutno říci, že z těchto výsledků dvakrát nadšeni nejsme. I zkusili jsme podobný pokus udělat s jiným benchmarkem. Slovo dostal tentokráte CineBench ve 32bitové verzi. Ten alespoň zatěžuje všechny využitelné procesory na maximum. Snad se tam výsledky trochu zlepší.

CineBench

S CineBenchem jsme se snažili o vyšší přesnost a tak byl každý test proveden čtyřikrát, z čehož byl vyroben aritmetický průměr. CineBench pokaždé prováděl výpočet pomocí čtyř softwarových vláken nezávisle na tom, kolik mu jich bylo správcem úloh Windows přiděleno.

CineBench využívá všechna přidělená jádra naplno, takže nejmarkantnější rozdíly jsou v samotném počtu přidělených jader. Čtyři se liší od tří a tři se liší od dvou, dalo by se říci, že tak, jak by to asi mělo vypadat. V grafech jsou navíc uvedeny průměrné odchylky měření od průměru naměřených hodnot. Nejmenší rozptyl mělo tedy měření se všemi jádry, naopak největší se třemi, kde nás to ovšem moc netrápí, protože výsledek odpovídá očekávání. Podívejme se však na práci jen se dvěma jádry.

V obou případech (jak s WinRARem, tak CineBenchem) byla nejpomalejší situace, kdy podle výše vyřknuté teorie využívá aplikace dvě jádra, která spolu sdílejí L2 cache (a navíc má z těchto měření na dvou jádrech nejmenší rozptyl, takže výsledky jsou relativně spolehlivé). Pozoruhodné je však rozdílné chování v situacích, kdy aplikace využívá jedno jádro z půlky křemíku a nějaké jádro ze druhého křemíku. Jakoby na tom výběru jádra ze druhého křemíku taky záleželo, a to mnohdy více než na tom, zda vybereme dvě jádra se sdílením L2 cache nebo dvě jádra s vlastní L2 cache. Vysvětlit by se to však dalo také tím, že naše teorie je chybná a procesory se o L2 cache dělí v nějakém jiném pořadí – třeba tak, že jádra 1 a 3 jsou na stejném křemíku, tudíž situace 1+2 i 2+3 by znamenala, že jádra spolu v takových případech L2 cache nesdílejí (čímž by se vysvětlily ty hodně podobné výsledky).

Nějaký závěr z toho však přeci jen vyvodit lze. To, zda aplikace pracuje na jádrech se sdílenou nebo nesdílenou L2 cache, je ve vícejádrovém prostředí celkově dost zanedbatelné. Intel Smart Cache byl nejspíše dobrý nápad, který vycházel z faktu, že by se mělo pomoci také aplikacím, které více jader nevyužijí. Taková aplikace bude mít při práci s jedním jádrem k dispozici celou L2 cache (v rámci jednoho kousku křemíku), což se počítá.