Administrace komentářů

- co Vám brání v první OMP bloku, pokud Vám jednotlivé OMP thready skákaj, ty thready svázat s jednotlivými jádry? Co vím, tak na většině implementací jsou OMP thready persistentní, nevytvářej se v každym bloku znovu.

- OMP má režii, takže ne vždy se vyplatí paralelizace. Tou režií se ale vysvětlí, proč na X-jádrovém stroji se ne vždy vyplatí X-thredový výpočet a je rychlejší Y-threadový, kdy Y<X. Nijak to ale nedává důvod, aby byl rychlejší výpočet, kde Y>X.

Aby tomu tak bylo, tak by prostě jednotlivé výpočetní thready museli na něco čekat tak dlouho, že to převáží režii s více threadama. To je buď nějakej IO Wait, nebo nerovnoměrný rozdělení práce v OMP blocích (což může znamenat např. hodně špatnou práci s pamětí, kdy jeden thread má vše k dispozici, zatímco druhej čeká na paměť) které způsobí, že polovinu času výpočtu jen dobíhají poslední OMP thready.

- Pokud potřebujete 4x více threadů než je v systému jader (navíc jen HT jader, takže ve skutečnosti je ten poměr ještě větší). Defakto to znamená, že Vaše thready více než 50% času na něco čekají. Neboť jinak by konfigurace 2x více threadů stroj plně vytížila a přitom by měla menší režii: musela by být nutně rychlejší. Nebo může být příčina v hodně nelokalizované práci s pamětí, kdy menší thready se spíš vejdou do cache nebo nějaká jiná podobná anomálie, v každém případě todle chování IMHO není standardní a mluví o tom, že někde v tom programu něco neběží optimálně.

- Ohledně Xeonů a i7: tam máte pravdu, vzdálená paměť je o něco pomalejší: řádově se uvádí na Xeonech kolem 20%, dalších deset procent max možná udělala registrovaná pamět. Rozhodně to nevysvětlí čtyřnásobný propad výkonu. Co to mohlo mít za příčinu je migrace procesu mezi procesory. Ale pak jste museli mít nějakej neopatchovanej stroj, protože todle chování řešili záplaty. Btw., o jakých winech se vlastně bavíme?