D. Použití klauzule schedule
Paralelní oblast má alespoň jeden bariéry na jeho konci a mohou mít další překážky v něm.Na každé bariéry ostatní členové týmu musí čekat poslední podproces doručení.Chcete-li minimalizovat tuto dobu čekání by sdílené pracovní distribuovány tak, aby všechny podprocesy dorazit bariéry na přibližně stejnou dobu.Pokud některé, sdílené práce obsaženy v pro konstrukce, schedule pro tento účel lze použít klauzuli.
Při opakovaných odkazy na stejné objekty, volba plán pro konstrukce může být určen především vlastnosti paměti systému, jako například přítomnost a velikost mezipaměti a zda jsou časy přístupu paměti jednotné nebo nerovnoměrného.Tyto úvahy může provádět lepší každý podproces důsledně odkazují na stejnou sadu prvků pole v řadě smyček, i když některé podprocesy jsou přiřazeny relativně méně práce v některých smyčky.To lze provést pomocí statické plán hranice stejné pro všechny smyčky.V následujícím příkladu, nezapomeňte, že nula se používá jako dolní mez v druhé smyčky, přestože k by více fyzických plánu nejsou důležité.
#pragma omp parallel
{
#pragma omp for schedule(static)
for(i=0; i<n; i++)
a[i] = work1(i);
#pragma omp for schedule(static)
for(i=0; i<n; i++)
if(i>=k) a[i] += work2(i);
}
V příkladech zbývající se předpokládá, že paměť není přístup dominantní posouzení a pokud není uvedeno jinak, všechny podprocesy se zobrazí srovnatelné výpočetní prostředky.V těchto případech výběr plánu pro pro konstrukci závisí na sdílené práce, která má být provedena mezi nejbližší předcházející překážky a bariéry předpokládané uzavření nebo nejbližší další bariéry, pokud je nowait klauzule.Pro každý druh plánu stručný příklad ukazuje, jak je pravděpodobně nejlepší volba typu plánu.Stručný popis následuje každý příklad.
Statické plán je vhodná pro nejjednodušší případ paralelního oblast obsahující jeden pro konstrukce s každé opakování vyžadující stejné množství práce.
#pragma omp parallel for schedule(static)
for(i=0; i<n; i++) {
invariant_amount_of_work(i);
}
Statické plánu je charakterizována vlastnosti které získává každý podproces přibližně stejný počet iterací jako ostatní podprocesu a každý podproces nezávisle určit počet iterací, které jí.Synchronizace je tedy pro distribuci práce a za předpokladu, že vyžaduje každé opakování stejné množství práce, by měly být dokončeny všechny podprocesy v přibližně ve stejnou dobu.
Pro tým p nechat podprocesů, ceiling(n/p) být celé číslo q, který splňuje n = p * q - r s 0 < = r < p.Jeden provádění statické plánování pro tento příklad by přiřadit q iterací na první p–1 vlákna, a q r iterací na poslední podproces.By přiřadit jinou implementaci přijatelné q iterací na první p r vlákna, a q-1 iterací na zbývající r podprocesů.To ukazuje, proč program neměli spoléhat na podrobnosti o konkrétní implementaci.
Dynamické plánu je vhodné pro případ pro konstrukce s iterací vyžadující různou nebo dokonce nepředvídatelné množství práce.
#pragma omp parallel for schedule(dynamic)
for(i=0; i<n; i++) {
unpredictable_amount_of_work(i);
}
Dynamické plánu je charakteristická vlastnost, kterou žádný podproces čeká na bariéry pro delší než jej jiný podproces bude proveden jeho konečné iterace trvá.To vyžaduje, aby iterací přiřadit postupně podprocesy, které budou k dispozici synchronizace pro jednotlivá přiřazení.Zadáním bloku minimální velikost lze snížit režii synchronizace k větší než 1, aby podprocesy jsou přiřazeny k v době, dokud méně než k zůstat.Zaručuje, že žádný podproces čeká na bariéru, která je delší než trvá jiný podproces bude proveden jeho konečné shluk (nejvíce) k iterací.
Dynamické plánu může být užitečná podprocesy přijímat různé výpočetní prostředky, které má mnohem stejný účinek jako různé částky pro každou iteraci práce.Podobně dynamický plán může být také užitečné, pokud podprocesy dorazit pro konstrukce v různých časech, když se vyskytuje v některých případech s asistencí plánu může být vhodnější.
S asistencí plánu je vhodné pro případ, kdy podprocesy mohou dorazí v různou dobu na pro konstrukce s každou iteraci vyžadující o stejné množství práce.Tato situace může nastat, pokud, například pro konstrukci předchází jedna nebo více oddílů nebo pro konstrukce s nowait klauzule.
#pragma omp parallel
{
#pragma omp sections nowait
{
// ...
}
#pragma omp for schedule(guided)
for(i=0; i<n; i++) {
invariant_amount_of_work(i);
}
}
Jako dynamické, s asistencí naplánovat záruky, které žádný podproces čeká na bariéru déle, než má jiný podproces bude proveden jeho konečné iterace nebo konečné k iterací, pokud velikost bloku k je určena.Mezi takové plány s asistencí plánu je charakterizována vlastnost vyžaduje co nejmenším synchronizací.Velikost bloku k, přiřadí Typická implementace q = ceiling(n/p) nastavení iterací na první dostupný podproces n se větší z n-q a p * ka opakujte, dokud jsou přiřazeny všechny iterací.
Při výběru optimální plán není jasné, jak je pro tyto příklady runtime plánu je užitečná při zkoušení různých plánů a velikosti bloku dat bez nutnosti upravit a znovu zkompilujte program.Může také být užitečné při optimální plán závisí (nějakým způsobem předvídatelné) vstupních dat, které program použije.
Chcete-li vidět příklad kompromis mezi různé plány, zvažte sdílení 1 000 iterací mezi 8 vláken.Předpokládejme, že existuje výchozí množství práce, které v každém opakování a použít jej jako jednotku času.
Spustit všechny podprocesy ve stejnou dobu statické plánu způsobí konstrukce provést v jednotkách 125, žádná synchronizace.Ale Předpokládejme, že jeden podproces je 100 jednotek pozdní doručení.Vyčkejte zbývajících sedm podprocesů pro 100 jednotek na bariéry a čas spuštění pro celé konstrukce se zvyšuje 225.
Protože jak dynamické a s asistencí plány zajistit, aby žádný podproces čeká více než jednu jednotku na bariéry, zpožděné podproces způsobuje jejich spuštění pro konstrukci zvýšit pouze na 138 jednotek, případně zvýšené zpožděními ze synchronizace.Pokud takové prodlevy není zanedbatelný, bude důležité, že je počet synchronizací 1000 dynamické , ale pouze 41 pro s asistencí, za předpokladu, že výchozí velikost bloku jednoho.Velikost bloku 25 dynamické a s asistencí i dokončit v 150 jednotek plus zpoždění z požadované synchronizace číslo, které nyní pouze 40 a 20, resp..