Testování vysoce výkonných výpočetních aplikací - Testing high-performance computing applications

Vysoce výkonná výpočetní technika aplikace běží na masivně paralelní superpočítače skládá se z souběžné programy navrženo pomocí vícevláknové, modely s více procesy. Aplikace se mohou skládat z různých konstrukcí (vlákna, místní procesy, distribuované procesy atd.) s různou mírou paralelismu. Ačkoli vysoce výkonné souběžné programy používají podobné návrhové vzory, modely a principy jako sekvenční programy, na rozdíl od sekvenčních programů obvykle ukazují nedeterministické chování. Pravděpodobnost chyb se zvyšuje s počtem interakcí mezi různými paralelními konstrukcemi. Podmínky závodu, datové závody, zablokování, zmeškané signály a živý zámek jsou běžné typy chyb.

Výzvy

Paralelní programy lze rozdělit do dvou obecných kategorií: výslovně a implicitně paralelní. Pomocí paralelních jazykových konstrukcí definovaných pro vytváření procesů sdělení a synchronizace učinit aplikaci výslovně paralelní. Pomocí nástroje nebo paralelizující překladač převést sériový program na paralelní, je implicitně paralelní. Obě kategorie jsou stejně náchylné k chybám.

Heisenbugs

Souběžné aplikace by se měly správně provádět při každém možném plánu podprocesů v podkladovém operačním systému. Tradiční metody testování však detekují několik chyb, hlavně kvůli Heisenbugs [1] problém. Heisenbug je chyba, která se změní nebo zmizí, když dojde k pokusu o jejich izolaci a prověření pomocí debugger, přidáním některých konstrukcí, jako jsou požadavky na synchronizaci nebo příkazy zpoždění.

Neopakovatelnost

Další problém je způsoben nepředvídatelným chováním plánovač. Rozdíly v zatížení systému ovlivňují chování plánovače. Toto chování nelze ručně změnit. Aby bylo možné čelit tomuto neurčitosti, musí být program spuštěn mnohokrát v různých prostředích provádění. Přesto není zaručeno, že bude možné chybu reprodukovat. Většinu času program běží správně a chyba je viditelná pouze při splnění konkrétních podmínek. Výsledkem je, že neopakovatelnost souběžných programů je hlavním zdrojem blokování reklam třetích stran pro detekci chyb. Jako příklad zvažte následující.

prázdnota vlákno1(prázdnota *t){   mutex_lock(A);   mutex_lock(b);   // dělat nejakou práci   .   .   .   mutex_unlock(b);   mutex_unlock(A);}
prázdnota thread2(prázdnota *t){   mutex_lock(b);   mutex_lock(A);   // dělat nejakou práci   .   .   .   mutex_unlock(A);   mutex_unlock(b);}

Je zřejmé, že to má problém způsobit zablokování. Přesto to může způsobit zablokování v některých bězích programu, zatímco v jiných může fungovat úspěšně.

Efekt sondy

Efekt sondy je vidět v paralelních programech, když jsou příkazy delay vloženy do paralelních programů, které čelí problémům se synchronizací. Tento efekt, stejně jako Heisenbugs, mění změny chování, které mohou zakrývat problémy. Detekce zdroje efektu sondy je velkou výzvou při testování paralelních aplikací.
Hlavní rozdíl mezi efektem Probe a Heisenbugs spočívá v tom, že Heisenbugs jsou vidět, když jsou během testování přidány další příkazy zpoždění a / nebo požadavky na synchronizaci do souběžné aplikace, zatímco efekt sondy je vidět, když vývojář přidá příkazy zpoždění do souběžných aplikací se špatnou synchronizací.

Strategie testování

Rozdíly mezi sekvenčními a souběžnými programy vedou k rozdílům v jejich strategiích testování. Strategie pro sekvenční programy lze upravit tak, aby byly vhodné pro souběžné aplikace. Byly také vyvinuty specializované strategie. Testování obvykle zahrnuje navrhování testovacích případů a kontrolu, zda program přináší očekávané výsledky. Takže chyby ve specifikaci, funkčnosti atd. Jsou detekovány spuštěním aplikace a jejím podrobením testovacím metodám, jako je Funkční testování, Bílá krabička, Černá skříňka a Testování šedé skříňky.[2] Statická analýza se také používá k detekci chyb ve vysoce výkonném softwaru pomocí metod, jako je Analýza toku dat, Analýza toku řízení, Cyklomatické složitosti, Analýza úniku vlákna a Statická analýza krájení najít problémy. Použití statické analýzy před testováním funkčnosti může ušetřit čas. Může zjistit, „v čem spočívá chyba“, najít zdroj chyby. Techniky statické analýzy mohou detekovat problémy, jako je nedostatek synchronizace, nesprávné synchronizace, předpovědět výskyt zablokování a po čekání chyby v setkání.

Podrobnosti:

Deterministické plánování / reprodukovatelné testování

Neurčitost plánování má dva zdroje.[1]

1. Časové krájení
Plánovač přepíná kontexty ve stejných časových intervalech. Tento interval závisí na rychlosti jednotlivých procesorů, stavu hierarchie mezipaměti paměti a zatížení systému. Dokonce i na stejném procesoru se při stejném zatížení interval mírně liší kvůli malým odchylkám frekvence systémových hodin.
2. Poruchy stránky
Plánovač pozastaví program, pokud a chyba stránky dojde, nechat další vlákna pokračovat, zatímco systém načte stránku. Protože výskyt chyb na stránce závisí na tom, jaké další procesy běží, načasování kontextového přepínače bude neurčité.

Aby se souběžné programy mohly opakovat, používá se externí plánovač. Testovaný program je vybaven tak, aby přidával hovory do tohoto plánovače. Taková volání se uskutečňují na začátku a na konci každého vlákna i před každým požadavkem na synchronizaci. Tento plánovač selektivně blokuje podprocesy provádění udržováním semaforu přidruženého ke každému podprocesu, takže v daném okamžiku je připraveno k provedení pouze jedno podproces. Převádí tedy paralelní nedeterministickou aplikaci na sekvenci sériového provedení, aby dosáhla opakovatelnosti. Počet rozhodnutí o plánování provedených plánovačem serializace je dán vztahem -

(N * K / P) * {(N + P)!}
Kde 
N = počet vláken
K = potenciální body přepnutí kontextu
P = rozpočet preventivních kontextových přepínačů

Testování zaměřené na zpětnou vazbu

Pro získání přesnějších výsledků pomocí deterministického plánování lze zvolit alternativní přístup. Několik správně umístěných předvoleb v souběžném programu může detekovat chyby související s datovými závody.[1] Chyby se nacházejí v klastrech. Existence jedné chyby vytváří vysokou pravděpodobnost více chyb ve stejné oblasti kódu. Každý průchod testovacího procesu tedy identifikuje části kódu s chybami. Další průchod důkladněji prozkoumá tyto sekce přidáním volání plánovače kolem nich. Povolení spuštění problematických míst v jiném pořadí může odhalit neočekávané chování.

Testování související s časováním

Tato strategie zajišťuje, že aplikace nebude náchylná k efektu sondy. Zdroje chyb, které způsobují účinek sondy, se mohou pohybovat od problémů s vytvářením úkolů až po problémy se synchronizací a komunikací. Požadavky na zkoušky související s časováním:[3]

  • Doba zpoždění se musí lišit
  • Body zpoždění musí pokrývat vhodná umístění programu
  • Pro vyvolání efektu sondy je nutné vložit, odebrat nebo přemístit příkazy zpoždění

Počet testovacích případů na sadu vstupních dat je: 

nC1 + nC1 + … + nC1 = 2n -1
Kde n = celkový počet synchronizací, vytváření procesů a komunikačních volání.

Tato rovnice má exponenciální pořadí. Aby se snížil počet testovacích případů, použijte buď metodu deterministického provedení (DET), nebo Technika vícenásobného provedení Používá se (MET). Musí být vyřešeny různé problémy:

  • Zpožděné provedení
Přidání zpoždění je přímý úkol. Typický příkaz sleep () lze použít k vložení zpoždění.
  • Rozhodování o tom, kam vložit zpoždění
Místa vložení jsou známá jako body zpoždění. Protože cílem testovacích případů souvisejících s načasováním je detekovat chyby synchronizace, komunikace a vytváření podprocesů, jsou před tyto příkazy přidány příkazy delay.

Výhody

  • Snadná implementace na více procesorech bez nutnosti objednávat požadavky na synchronizaci.
  • Není třeba generovat souběžný graf
  • Efektivnější pro detekci poruch
  • Celkový počet testovacích případů je menší, ale pokrytí kódu je větší, kvůli statické analýze

Veškeré testování Du-Path

Tato metoda používá koncept páru definování a použití, aby bylo možné určit cesty, které mají být testovány.

Strategie ověřování

Ověření softwaru je proces, který dokazuje, že software funguje správně a plní zamýšlený úkol tak, jak je navržen.

Zkušební výpočty

Do systému se vstupuje za účelem vygenerování známého výsledku. Tento pár vstup-výsledek lze získat z předchozích empirických výsledků a / nebo manuálních výpočtů.[4] Toto je test na úrovni systému, který lze provést, pouze pokud jsou integrovány všechny příslušné moduly. Kromě toho pouze ukazuje, že chyby existují. Neposkytuje žádné podrobné informace o počtu chyb, jejich umístění nebo povaze.

Symetrické testy

Tyto testy se používají především pro vědecké simulace. Výstup simulace často nelze předvídat. Jelikož se tyto simulace pokoušejí popsat vědecké zákony, je nutné simulaci ctít všechny symetrie v teorii. Existenci chyb lze tedy detekovat změnou vstupních podmínek v linii symetrie a následným porovnáním získaných výsledků s externě odvozenými výsledky.[4]

Obrázek 1: Distribuce dat

Ve vědeckých výpočtech leží většina dat v centrální oblasti podmínek simulace. Ve výsledku je obtížné provést testování hraniční hodnoty [2] s experimentálními daty v reálném čase. Střed simulace (například pro datovou hodnotu 10 na obrázku 1) se tak posune na jednu z hranic, aby se efektivně otestovala okrajová podmínka.

Paralelní implementační testy

Testy paralelní implementace se obvykle používají pro aplikace, které používají modely programování distribuované paměti, jako je předávání zpráv. Tyto testy se často používají u programů, které používají běžné mřížky procesorů.[4][je zapotřebí objasnění ]

Globální součet

Mnoho paralelních databází používá k provádění dotazů distribuované paralelní zpracování. Při provádění agregační funkce, jako je součet, se používá následující strategie:[5]

  • Vypočítejte částečný součet lokálně a souběžně u každého procesoru pomocí dat přítomných v přidružené diskové oblasti.
  • Přidejte tyto místní mezisoučty a získáte konečný výsledek.

Konečný výsledek může obsahovat určitou chybu zaokrouhlování, protože každý procesor nezávisle zaokrouhluje místní výsledky. Jedním z testů je zajistit, aby k takovým chybám nedocházelo. To vyžaduje ukázku, že agregovaný součet je nezávislý na rozkladu. Alternativní schéma součtu je odeslat všechny jednotlivé hodnoty jednomu procesoru pro součet. Tento výsledek lze porovnat s distribuovaným výsledkem, aby byla zajištěna konzistence.

Nástroje

Microsoft šachy

Tento nástroj eliminuje neurčitost pomocí deterministického plánování. Sleduje dříve naplánované cesty a zaručuje, že pokaždé, když se provede nová cesta plánu.[1][je zapotřebí objasnění ]

Reference

  1. ^ A b C d Thomas Ball; Sebastian Burckhardt; Peli de Halleux; Madanlal Musuvathi; Shaz Qadeer (květen – červen 2011). "Předvídatelné a progresivní testování vícevláknového kódu". Software IEEE. 28 (3): 75–83. doi:10.1109 / MS.2010.64.
  2. ^ A b Umění testování softwaru, druhé vydání. John Wiley and Sons. 2004. s. 256. ISBN  978-0-471-46912-4.
  3. ^ Cheer-Sun Yang; Lori L. Pollock (1997). "Výzvy v automatickém testování vícevláknových programů". Sborník příspěvků ze 14. mezinárodní konference o testování počítačového softwaru: 157–166. CiteSeerX  10.1.1.52.8791.
  4. ^ A b C Stephen Booth; David Henty (2004). "Strategie ověřování vysoce výkonného výpočetního softwaru". „Softwarové inženýrství pro aplikace vysoce výkonných výpočetních systémů (HPCS)“ Workshop W3S - 26. mezinárodní konference o softwarovém inženýrství. 2004. str. 24–26. doi:10.1049 / ic: 20040413. ISBN  0-86341-418-4.
  5. ^ Korth, Henry. Koncepty databázového systému. McGraw-Hill.