Historie
Co se dozvíte v článku
Linpack je známá knihovna původně ve Fortranu 66 pro řešení problémů lineární algebry a vznikla kolem roku 1974. Knihovna Linpack byla časem nahrazena knihovnou Lapack (Linear Algebra PACKage).
Maticové operace se často používaly a stále používají jako benchmark pro měření výkonu počítače v plovoucí desetinné čárce (double precision, float64, FP64). Používá se LU faktorizace husté čtvercové matice, tedy to, co se ve škole učíte jako Gaussovu eliminaci. Počet operací v plovoucí desetinné čárce je zhruba 2/3n3, kde n × n je rozměr naší matice. Když změříme, jak dlouho eliminace trvala, můžeme spočítat počet operací za sekundu tzv. Flop/s (floating point operations per second).
Na stránce Wikipedie naleznete i tabulku s teoretickým Flop/s na takt a jádro běžných procesorů. Například Raspberry Pi 4 má ARMv8 se čtyřmi jádry Cortex-A72 a ten podle tabulky má dvě operace FP64 za takt na jádro. Takže při frekvenci 1,8 GHz (v /boot/config.txt zapnuto arm_boost=1) vychází teoretický výkon Raspberry Pi 4 na 14,4 GFlop/s.
My už jsme Raspberry Pi 4 dvakrát pomocí HPL testovali. Poprvé na 32bitovém OS jsme dostali 11,0 GFlop/s a podruhé na 64bitovém OS 16,3 GFlop/s (tady jsem ale měl přetaktováno na 2,0 GHz). V příštím díle si ukážeme vylepšený postup, který dává 17,1 GFlop/s při 1,8 GHz.
Nejprve se roku 1977 objevil test pro matice 100 × 100 Linpack 100 ve Fortranu. Vyžadoval 80 kB RAM. Roku 1986 pro matice 1000 × 1000 Linpack 1000, který už vyžadoval 8 MB RAM. Poté se roku 1991 objevil High Performance Linpack (HPL) se svou referenční implementací v jazyce C. Zde si můžete zvolit rozměr matice n × n a často se volí tak, aby byla téměř použita celá dostupná paměť RAM. Větší matice totiž dávají větší výkon.
SandyBridge(AVX) 4×3,2 GHz, výkon jako funkce alokované paměti. Teoretický výkon 102,4 GFlop/s
Je to patrně tím, že na začátku se operuje s dlouhými řádky, první řádek má délku n, další n-1 a stále se zkracují. Tím jakoby v čase padal výkon a výsledek HPL testu je průměrný výkon přes celou dobu testu. Potřebnou operační paměť je možné odhadnout jako 8 byte × n2. Paměťová náročnost stoupá tedy kvadraticky, ale časová náročnost kubicky (2/3 n3).
SandyBridge(AVX) 4×3,2 GHz, trvání HPL testu jako funkce alokované paměti.
TOP500
Výsledný výkon v PFlop/s se pak od roku 1993 používá pro žebříček nejrychlejších superpočítačů světa TOP500. Pro zajímavost prvnímu žebříčku z roku 1993 vévodil CM-5/1024 z Los Alamos s „pouhými“ 1024 jádry SuperSPARC na 32 MHz s výkonem 131 GFlop/s. Takže by ho překonal cluster složený z osmi desek Raspberry Pi 4.
Žebříček bývá aktualizován dvakrát ročně (červen a listopad) a kromě výsledku testu HPL (Rmax) je tu i teoretický maximální výkon (Rpeak), který zjistíte prostě sečtením teoretického FP64 výkonu všech jader ve všech uzlech superpočítače. V tom však není zahnuta režie komunikace mezi procesory, rychlosti paměti a další vlivy. Proto se pro řazení do žebříčku používá právě výsledek HPL (Rmax).
V současnosti je nejrychlejší Frontier v Oak Ridge (USA) s procesory AMD EPYC, který má výkon v HPL 1102 PFlop/s. Druhým nejrychlejším je pak japonský Fugaku s procesory ARM A64FX a výkonem v HPL 442 PFlop/s.
Frontier má 8,7 miliónů jader GPU a CPU. CPU má 606 tisíc jader AMD EPYC 3. generace (Zen3) na 2 GHz, celkový výkon je 1102 PFlops/s a příkon 21 MW.
Fugaku disponuje 7,6 miliony jader A64FX 48C s architekturou ARM na 2,2 GHz. Jeho výkon je 442 PFlop/s a příkon 26 MW.
Na TOP500 není uvedeno množství paměti, ale je tam Nmax, tedy velikost matice, která se ještě do RAM vejde. Z toho můžeme odhadnout jednak velikost RAM i dobu běhu jednoho testu. Frontier má Nmax 24 440 832 a Fugaku 21 288 960, to odpovídá 4346 TB a 3297 TB RAM. Vyjádřeno na jedno jádro to je 522 MB/jádro a 453 MB/jádro. Pro srovnání CM-5/1024 má Nmax 52 224 a měl tedy asi 22 GB RAM.
Ještě se zastavme u jader. Fugaku to má celkem jednoduché, má 7 630 848 ARM jader na frekvenci 2,2 GHz, která používají 512bitové SVE (Scalable Vector Extension). Podle Rpeak má teoreticky mít Fugaku výkon 537,21 PFlop/s. To odpovídá 32 Flop na jádro a takt, což může být správná hodnota pro SVE-512. Odpovídá to také AVX-512. Podle změřeného výkonu Rmax 442,01 PFlop/s je výkon jádra na takt 26,3 Flop. HPL tedy na Fugaku dosahuje 82% účinnost.
Frontier je složitější, skládá se totiž z 606 208 jader AMD Epyc na 2 GHz a k tomu 8 335 360 jader GPU AMD Instinct MI250X. Teoretický výkon CPU části můžeme odhadnout, protože Zen3 má 16 Flop na jádro a takt. To dává jen 20 PFlop/s. Takže z celkového teoretického výkonu Rpeak 1685 PFlop/s je většina 1665 PFlop/s díky výkonu GPU.
Výhodou Fugaku je tedy to, že je to homogenní cluster CPU a není potřeba upravovat software, aby využíval GPU u nehomogenního clusteru, jakým je Frontier. To se projeví například v žebříčku HPCG (High-Performance Conjugate Gradient). To je mladší sourozenec TOP500, je sestavován od roku 2017 a počítače v něm doposud dosahují pouze zlomku svých teoretických Flop/s. Fugaku je v HPCG první s 16,0 PFlop/s a až druhý je Frontier s 14,1 PFlop/s.
Dobu běhu jednoho testu odhadneme z Nmax a Flop/s. U Frontier vychází jeden test na 2,5 hodiny u Fugaku na čtyři hodiny. A to je jen ta část testu použitá pro benchmark. Předtím nezanedbatelný čas trvá plnění paměti a potom i kontrola výsledku. Pro srovnání podle tohoto výpočtu bude jeden optimální test na Raspberry Pi 4 s 8 GB RAM trvat asi 15 minut (N=28200, 17,09 GFlop/s). Ale ve skutečnosti test trvá 16 minut (MPI) nebo dokonce 17,5 minuty (OpenMP). Je to proto, že v případě OpenMP je plnění paměti a kontrola dělaná pouze na jednom jádře. Nicméně OpenMP má ve vlastním výpočtu menší režii a ve výsledky dává více Flop/s než MPI.
Raspberry Pi 4B, 4 jádra na 1,8 GHz. Výkon 17 GFlop/s se spotřebou asi 11 W.
Ještě se můžeme podívat na energetickou účinnost počítačů. Tu budeme uvádět v GFlop/s na Watt, prostě vydělíme GFlop/s v HPL spotřebou. Raspberry Pi 4 má jen asi 1,5 GFlop/sW. Fugaku 16,2 GFlop/sW a Frontier 52,5 GFlop/sW. V efektivnosti je od roku 2013 také veden žebříček Greeen500. Prvním v něm je americký Henri s téměř 6000 jádry Intel Xeon Platinum, GPU NVIDIA H100 a spotřebou jen 31 kW. Jeho účinnost je 65,1 GFlop/sW.
Kontrola chyb
V případě HPL se řeší systém n lineárních rovnic Ax=b a velká výhoda HPL je, že se výsledek také zkontroluje. Byla odvozena formule pro normu zbytku |Ax-b|, která bere do úvahy zaokrouhlovací chyby při každé operaci. Pokud je chyba větší než vámi dopředu zvolené číslo (často se bere 16.0), tak test neprošel a došlo k chybě hardware. Ve skutečnosti jsou chyby v důsledku zaokrouhlování v řádu 10-3 a pokud dojde k chybě CPU, vyrovnávací paměti nebo RAM, tak chyba je většinou velmi obrovské číslo.
Matice A se na začátku naplní náhodnými čísly, proto také je dobré test opakovat několikrát. Jednak pro k dosažení lepšího výsledku Flop/s a jednak k větší jistotě správné funkce hardware.
Proč to dělat?
Proč pouštět HPL na svém počítači nebo SBC? Můžete k tomu několik důvodů:
- Chci se přesvědčit, že je hardware stabilní. Pokud projde desítku testů bez chyby, dá se věřit, že CPU, chlazení, zdroj i vyrovnávací paměti stabilní jsou. Pokud navíc použijete téměř všechnu RAM, máte v tom vlastně i test paměti. Negativní výsledek HPL je buď že ohlásí failed u kontrolního součtu, nebo se počítač zasekne, případně se může i restartovat.
- Přetaktovávám (overclocking) nebo snižuji napájení (undervolting) CPU a potřebuji ověřit stabilitu CPU s novým nastavením. HPL je velmi náročný test. Pokud HPL projde, nemělo by docházet k chybám ani s libovolným jiným kódem.
- Chci ověřit Flop/s a tím zjistit, jestli moje CPU drží maximální frekvenci, nebo jestli kvůli přehřívání dochází k tichému snižování frekvence (thermal throttling).
- Chci zjistit Flop/s a zapsat se do TOP 500 :)
Proč to nedělat? Nedělejte to, pokud nemáte opravdu dobré chlazení. Určitě bych to nedělal na Raspberry Pi bez chladiče. I v případě velkého pasivního chladiče, jaký má třeba Odroid M1, je dobré na chladič trochu foukat vzduch, jinak CPU vykazuje thermal throttling, tedy snižování frekvence.
Knihovny
MPI
Vlastní referenční implementace HPL (v současnosti verze 2.3) závisí na dvou knihovnách. První je pro komunikaci mezi procesory a využívá standardu MPI (Message Passing Interface). S pomocí MPI si můžete doma vytvořit velký počítač z několika menších. Limitujícím faktorem je pak rychlost a latence komunikace. U superpočítačů 1 Gb/s ani 10 Gb/s ethernet nestačí a používal se například Myrinet a InfiniBand. Frontier pak používá HPE Slingshot interconnect a Fugaku Tofu interconnect.
Ve skutečnosti tu nebudeme testovat superpočítače, ale jen běžné počítače a SBC, ale i ty jsou v současnosti vícejádrové (SMP, big-LITTLE). Ukážeme si, že se v takovém případě dá bez MPI obejít, pokud použijeme OpenMP. Bohužel ale HPL bez knihovny MPI nepřeložíme.
V takových případech se používají tzv. knihovny MPI stub (pahýl), které jakoby definují MPI funkce na SMP. Bohužel se mi HPL nepodařilo ani s jednou stub knihovnou uspokojit. HPL totiž využívá celkem hodně MPI funkcí. Pokud by se to někomu podařilo, byl bych rád. Já neúspěšně zkoušel FakeMPI, MPI_Stubs a LAMMPS MPI STUBS.
Fungují pouze dvě plné implementace Open MPI anebo MPICH. Takže si jednu vybereme a tu použijeme. Podle mne na výběru nezáleží, výkon bude stejný. V prvním případě nainstalujte balík libopenmpi-dev, v druhém libmpich-dev.
Problém distribuce binárky HPL někomu druhému by se dal vyřešit statickým slinkováním s knihovnou MPI. Ale to se mi také nedaří. Existuje sice přímo stránka s popisem statického linkování Open MPI, ale nefunguje mi to. Poslední možností je nechat linkování dynamické, ale dodávat s binárkou i knihovnu a použít proměnnou LD_LIBRARY_PATH. Bohužel Open MPI vytvoří spoustu souborů a ne jeden .so soubor. V tomto případě je MPICH lepší. Pokud by někdo věděl, jak jednu z těchto MPI knihoven přilinkovat staticky, budu také rád.
BLAS
Dále HPL pro maticové operace potřebuje knihovnu BLAS (Basic Linear Algebra Subprograms). Uvádí se, že místo toho můžete použít VSIPL (Vector Signal Image Processing Library), ale nezkoušel jsem to. Také proto, že poslední verzi má z roku 2014.
Výkon HPL hlavně záleží na tom, jakou knihovnu BLAS zvolíte a jak ji přeložíte. V distribucích jsou většinou velmi pomalé generické varianty. Proto si ji budeme překládat sami. Na výběr je opět několik možností: OpenBLAS, BLIS, ATLAS, ARM Performance Libraries, Intel MKL, Eigen a další.
ATLAS
ATLAS (Automatically Tuned Linear Algebra Software) je myslím z roku 1998 a zajímavý z pohledu kompilace. Při kompilaci totiž zkouší různé varianty algoritmů a měří, jak dlouho trvají. Ve výsledku pak vybere ty nejrychlejší. Kdo to nezkoušel, tak kompilace ATLAS je celkem zážitek. Nemělo to rádo ani změny frekvence procesoru. Kupodivu je možné v binárních distribucích nainstalovat ATLAS jako kompilovaný balíček. Nevím však, pro co bude optimální. Nicméně poslední verze 3.11.41 je z roku 2018.
OpenBLAS
OpenBLAS bych asi doporučil jako první volbu. Vychází z GotoBLAS, který napsal v roce 2002 japonský programátor Kazushige Gotō na univerzitě v Austinu. V podstatě napsal funkce jako ručně optimalizovaný kód v assembleru a tím dosáhl velké rychlosti. U Pentia 4 vzrostl výkon ve Flop/s asi o třetinu.
OpenBLAS vznikl v roce 2011 jako fork GotoBLAS2 a pokračuje v ručně optimalizovaných funkcích (mikrojádrech) pro různé procesory. Je open source s BSD licencí. V současnosti podporuje x86, MIPS, ARM, IBM zEnterprise a RISC-V. Zase je potřeba při kompilaci vybrat, jaký přesně procesor máte, aby byl výkon optimální.
Nově je množné zkombinovat knihovnu pro více procesorů do jedné a za chodu se vybere optimální kód tzv. DYNAMIC_ARCH. Například pro ARMv8 lze od roku 2018 kombinovat generický ARMv8, Cortex-A53, Cortex-A57, Cortex-A72, Cortex-A73, Falkor, ThunderX, ThunderX2T99 a TSV110. Pro x86 je tu DYNAMIC_ARCH od roku 2014 a aktuálně je na výběr mezi Katmai, Coppermine, Northwood, Prescott, Banias, Core2, Penryn, Dunnington, Nehalem, Athlon, Opteron, Opteron_SSE3, Barcelona, Bobcat, Atom a Nano.
Jak si ukážeme později, v případě Intel x86 má na HPL vliv v podstatě pouze to, jestli procesor má instrukce AVX, AVX2, nebo AVX512. Potom má podle již zmíněné tabulky 8, 16 nebo 32 FP64 operací za takt na jádro. Pro AMD Zen má 8 a Zen 2 a 3 16 FP64 operací za tak na jádro. V tomto případě se u x86 počítají jen skutečná jádra, ne HT.
Pokud si ale nainstalujete balíček openblas z vaší distribuce, bude to patrně jen nekombinovaná jedna varianta, která opět nebude optimální.
BLIS
BLIS (BLAS-like Library Instantiation Software Framework, také slovní hříčka na bliss – blaho) vznikl na univerzitě v Austinu v roce 2013. Někdy je BLIS označován jako přepsání GotoBLAS2, který Kazushige Goto napsal na stejné univerzitě. Používá tedy stejně jako OpenBLAS ručně optimalizované mikrojádra v assembleru a výkonově je na tom podobně jako OpenBLAS.
Jejich vlastní testy naznačují, že BLIS by měl být o něco rychlejší než OpenBLAS i jiní konkurenti a to obzvláště pro malé nebo silně protáhlé matice (tedy jeden nebo oba rozměry matice jsou malé). Oba hlavní autoři BLIS Devin A. Matthews a Field G. Van Zee dostali letos v únoru ocenění J. H. Wilkinsona za numerický software.
Porovnání BLIS, OpenBLAS, Eigen a MKL na AMD Zen2 128 jader. HPL používá dgemm (double precision general matrix multiply).
Intel MKL a ARM Performance Libraries
Výrobci procesorů často dodávají vlastní knihovny, které mají optimální výkon na jejich výrobcích. Intel má od roku 2003 svoje MKL (Math Kernel Library, nedávno se to přejmenovalo na Intel oneMKL) a ARM má Performance Libraries.
MKL je zdarma s licencí ISSL (Intel Simplified Software License) a částečně i open source s licencí Apache 2.0. MKL by mělo také jako již zmiňovaný DYNAMIC_ARCH u OpenBLAS detekovat procesor a vybrat za chodu nejlepší kód. Ale kolem roku 2009 se zjistilo, že MKL detekuje a znevýhodňuje procesory konkurence (AMD, VIA) a schválně na nich nepoužívá vektorové instrukce například SSE2, i když je konkurence má. Ve výsledku kód běží na procesoru konkurence pomaleji, než by měl.
ARM Performance Libraries jsem ještě nezkoušel, ale možná je někdy zkusím. Knihovny jsou zdarma, ale jde o uzavřený kód, distribuovaný jen binárně.
Mimochodem AMD pro svoje procesory nemá vlastní BLAS, ale ve svých AOCL (AMD Optimizing CPU Libraries) má už zmiňovanou knihovnu Blis.
Za zmínku možná ještě stojí FlexiBLAS. Jde o rozhraní, které umí jednoduše bez přelinkovávání binárek změnit za chodu implementaci BLAS. Umí pomalý referenční Netlib BLAS a LAPACK (Linear Algebra PACKage), ATLAS, OpenBLAS, BLIS a Intel MKL. Ale zatím je podle všeho jen ve Fedoře od verze 33. I tento přístup však neřeší potřebu odlišných binárních souborů pro různé procesory stejné architektury. Toto pěkně řeší například zmiňovaný DYNAMIC_ARCH z OpenBLAS. Snad se tato novinka brzy prosadí do binárních distribucí.
Příště prakticky
V tomto díle jsme se dozvěděli, jak se sestavuje žebříček nejrychlejších superpočítačů světa TOP500, co to je HPL, jakou má historii, nač bychom ho mohli použít a jaké knihovny jsou k němu potřeba. V příštím díle se budeme více věnovat praxi. Zkompilujeme si BLAS a HPL, ukážeme si, jak se HPL pouští a jak optimalizovat parametry pro co největší výkon.
ČLÁNKY DO MAILU