Různé výsledky výpočtu na různých procesorech?

12.5.2007 23:14 | Přečteno: 1857× | Externí paměť | poslední úprava: 12.5.2007 23:51

Milá Sally,
ve škole jsem vžycky dával pozor, ale teď se mi stalo něco, s čím si nevím rady.

Při práci na disertaci pracuju s modelem radiativního transferu DART. Pro radu asi není důležité jak model funguje a co uvnitř dělá.

Stručně: model je to program, který dostane na vstupu vstupní data (makety), pak s nimi počítá (je to několik hodin operací s čísly v plovoucí řádové čárce) a nakonec vysype malý snímek - obrázek.

A kde je ten problém: při výpočtech používám kapacit superpočítačového centra CESNETu, a výpočty můžu směřovat na různé stroje. Když jsem poslal výpočty na počítače s Xeonem a s Opteronem, dostal jsem různé výsledky pro stejná vstupní data.

Nenapadá tě, jak se to může stát? Vždycky jsem si myslel, že když pošlu do dvou počítačů stejná data, dostanu stejné výsledky.

S pozdravem
Tvůj věrný čtenář V.

---

Informace které vím:

• aplikace je 32bitová, oba počítače běží mají 64bitové procesory i jádro
• aplikace dělá hodně operací s čísly v plovoucí řádové čárce
• oba počítače běží na nějakém SUSE - verzi zatím nevím
• problém se projeví na různých strojích z METAcentra
• problém se projeví na různých maketách
• Opteron: Linux XXXXXXXXXXX 2.6.13-15-smp #2 SMP Fri Jan 27 12:39:26 CET 2006 x86_64 x86_64 x86_64 GNU/Linux
  Xeon: Linux XXXXXXXXXXX 2.6.18-xen-smp #3 SMP Wed Dec 13 21:37:56 CET 2006 x86_64 x86_64 x86_64 GNU/Linux

Pro zajímavost přikládám náhled vypočtených dat - data mají vyrovnaný histogram, pro zpracování použití se to nedělá, pro náhled je to pohodlnější.

       

Obrázky

Komentáře

[fakenickname]

Právě sem pařil asi dvě hodiny dooma a když jsem viděl ty obrázky tak sem si říkal jestli to náhodou nejsou nějaké bitmapy z něj ;)

[fakenickname]

btw dik za tip na to metacentrum.. ani sem nevedel ze muzu delat s necim takovym.. uz premyslim cim bych to vyzkousel ;)

[Michal Fecko]

Tak na to moze mat vplyv IMHO asi cez milion faktorov, od nejakej chyby v programe spracuvavajucom vstupne data cez nastavenia systemovych kernelov (volby jadra, praca s pamatou a pod) az po zle postavenie planet Fakt, to by clovek za tym musel sediet hodiny (a aj tak by na nic nemusel prist )

[Käyttäjä 11133]

No postavení planet by se uplatňovalo jen a pouze kdyby se chyby nedaly reprodukovat. Pokud pro stejný vstup dostane stejný výstup na stejném stroji v čase t1 i t2 tak se postavení planet, které je nepochybně závislé i na čase neuplatňuje. (za předpokladu, že t1 není rovno t2) Spíš bych sázel na jinak nastavené systémy. Jiné verze distribucí, kernelů a důležitých knihoven.

[Věroš]

Ty obrázky jsou stromy, konkrétně smrky, z nadiru (z kolmého pohledu zezhora).

[mess]

Tak to bych nepoznal . Ale ten první obrázek se mi líbí víc. To je ten z Xeonu, ne?

[KS]

Ono to může být způsobeno různou implementací některých operací procesoru, jako jsou například ty zmiňované operace s čísly s plovoucím řádovým oddělovačem. Někde jsem četl, že s tím měly problémy projekty distribuovaných výpočtů jako třeba BOINC.

[marbu]

IMHO by vsechny operace mely byt implementovane zhruba stejne (dle ieee 754), hlavni problem je s presnosti, rozsahem a rozlisitelnosti (podle toho, jak velke ma konkretni FPU registry). Ale ne ze bych tomu nejak moc rozumnel, doted jsem si naivne myslel, ze mezi architekturou x86-64/AMD64(Opteron) a EM64T(Xeon) nebude tak velky rozdil

[Miloslav Ponkrác]

Každý fpu (floating point unit) lze u x86 procesoru nastavit do stovek různých režimů, například jde nastavit přesnost, způsob zaokrouhlování, a řada dalších věcí (k nahlédnutí viz nějaká příručka asm pro x86). Existují na to dokonce řídící registry, kde se to nastavuje.

Takže podle nastavení vám jednou fpu může počítat s přesností na x míst a zaokrouhlovat třeba na nejbližší číslo. Podruhé třeba fpu může počítat s přesností na y míst a zaokrouhlovat usekáváním.

Obvykle operační systém nastaví fpu do nějakého defaultníhoé režimu, ale proces to má pevně v rukou, stačí, aby nějaká knihovna, a nebo třeba vy si na začátku pevně nastavil fpu do stejného režimu.

Kromě toho samozřejmě není vyloučeno a je to dokonce pravděpodobné, že fpu se na obou vámi zmíněnných procesorech liší - floating point je jen o přibližných výpočtech.

[andree]

to som nevedel, ze sa to da nastavovat :) ale keby som nieco pocital a potreboval exaktny vysledok, asi by som sa nespoliehal na FP unit procesoru - prave kvoli vsetkym moznym "optimalizaciam", ktore mozu byt v procesore... uz len ked si predstavim, ze pri operaciach s floatom v niektorych pripadoch clovek nemusi dostat presne cislo ani na 1 desatinne miesto... kludne ked chce clovek presne cisla, treba pouzit integer (dobry paradox)

[Kyosuke]

Existují na to dokonce řídící registry, kde se to nastavuje.

A funkce v glibc. Co mi ale přijde divné, je, že by ten algoritmus byl takhle citlivý na zaoukrouhlovací chyby. Tohle je, BTW, také výstižné:

Many programmers like to believe that they can understand the semantics of a program and prove that it will work correctly without reference to the compiler that compiles it or the computer that runs it. In many ways, supporting this belief is a worthwhile goal for the designers of computer systems and programming languages. Unfortunately, when it comes to floating-point arithmetic, the goal is virtually impossible to achieve. The authors of the IEEE standards knew that, and they didn't attempt to achieve it. As a result, despite nearly universal conformance to (most of) the IEEE 754 standard throughout the computer industry, programmers of portable software will have to continue to cope with unpredictable floating-point arithmetic for the foreseeable future.

(zdroj)

[xkesh]

Nenapadá tě, jak se to může stát? Vždycky jsem si myslel, že když pošlu do dvou počítačů stejná data, dostanu stejné výsledky.

No vidíte, takže jste poznal na vlastní kůži, že když na to přijde, tzv. neměnné a absolutně platné přírodní zákony a že když A=B a B=C, tak A=C platí, jen když do toho moc nešťouráme

[Věroš]

To je myšlenka z nějaké Zeměplochy, ne?

[Andrej]

Když zkompiluješ Linux (opravdu pouze kernel) s flagem pro Pentium II a spustíš ho na procesoru Cyrix 686, spadné ESP Ghostscript jako domeček z karet kvůli underflow. (=> Pak to vůbec netiskne...) S flagem Pentium-Pro funguje bez potíží. Paradoxní je, že nebylo nutné překompilovat samotný Ghostscript. (Ten byl v obou případech z binárního balíčku s flagem Pentium-Pro.)

Takže můj intuitivní úsudek je: Ano, může se to stát.

[xsubway]

napr.: What Every Computer Scientist Should Know About Floating-Point Arithmetic

(podporeno "spatnou" zkusenosti z praxe)

[Zdeněk Hurák]

Jestliže do dvou soudobých počítačů pošlu ta stejná data do stejného algoritmu, pak skutečně lehce můžu dostat různé výsledky. Ne ani tak proto, že by se lišil počet významných bitů, či způsoby zaokrouhlování. Od dob přijetí standardu IEEE 754 a IEEE 854 by se počítače zavedených výrobců měly v tomto chovat stejně.

Jednou z příčin, kde se i přes standardizaci může objevit rozdíl, je tzv. FMA (fused multiply add). Čili hardwarová architektura, která dokáže spojit násobení a sčítání a zvyšit tak efektivitu. Skutečně, ona operace

A = B + C*D

je velmi užitečná operace v mnoha numerických úlohách, a tak se vyplatí mít ji "speciálně zadrátovanou". Namátkou, využijete ji velice silně při násobění matic, při řešení jakýchkoliv rekurentních rovnic atd.

A teď, kde je problém? Uvažujte například násobení dvou komplexních čísel (z a z'=z_komplexne_sdruzene) ve floatové aritmetice:

z = x+iy z' = x-iy

Jejich součin je zřejmě: zz' = (x+iy)(x-iy) = x^2+y^2+i(yx-xy) = x^2+y^2

Tedy čistě reálné číslo. Avšak při použití FMA je možné získat velice malinkou komplexní složku. To prostě proto, že procesor s FMA počítá imaginární složku ne jako

temp1 = y*x temp2 = x*y (ale na pořadí samozřejmě nezáleží) imag_slozka = temp1-temp2

což by byla skutečně ryzí nula, nýbrž jako

temp1 = y*x imag_slozka = temp1 - x*y

Z hlediska vnesení zaokrouhlovacích chyb, mezi dvěma výše uvedenými kroky je samozřejmě výrazný rozdíl. V prvním případě jde o tři operace, a tak je zaokrouhlovací chyba vnesena třikrát. Ve druhém (FMA) případě je zaokrouhlování prováděno pouze dvakrát.

Že si nevymýšlím, je možné vidět na následujícím příkladě v Octave

octave:1> A = rand(3,3) + j*rand(3,3)

A =

0.20974 + 0.43455i 0.50108 + 0.38016i 0.24643 + 0.90169i 0.33751 + 0.39598i 0.22127 + 0.58548i 0.58724 + 0.88980i 0.84237 + 0.18959i 0.67795 + 0.99298i 0.33828 + 0.00156i

octave:2> C = rand(3,3) + j*rand(3,3)

C =

0.213787 + 0.961981i 0.469730 + 0.922373i 0.560915 + 0.462651i 0.930401 + 0.763539i 0.146290 + 0.423445i 0.015814 + 0.004987i 0.286520 + 0.579304i 0.581899 + 0.806029i 0.685377 + 0.171148i

octave:3> A = C'*C

A =

2.83744 - 0.00000i 2.08081 - 0.07856i 0.87902 - 0.79612i 2.08081 + 0.07856i 2.26041 + 0.00000i 1.23141 - 0.75886i 0.87902 + 0.79612i 1.23141 + 0.75886i 1.02798 - 0.00000i

octave:4> A - A'

ans =

0.00000 - 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 - 0.00000i

Na první pohled to možná vypadá, že jsme skutečně dostali nulu, ale nenechte se zmást:

octave:5> format hex

octave:6> A - A' ans =

Columns 1 and 2:

0000000000000000 bc91200000000000i 0000000000000000 3c90000000000000i 0000000000000000 3c90000000000000i 0000000000000000 3c70800000000000i 0000000000000000 0000000000000000i 0000000000000000 0000000000000000i

Column 3:

0000000000000000 0000000000000000i 0000000000000000 0000000000000000i 0000000000000000 bc8a000000000000i

Shrnutí: při srovnávání výsledků numerických výpočtů na různých platformách je nutné dnes brát i v úvahu přítomnost či absenci, povolení či zakázání některých novějších technologií jako například FMA (a možná i jiné, nevím, nejsem expert).

[Aleš Kapica]

Díky za uvedení do problematiky. Poslední dobou se mi stávalo, že mi za určitých situací vycházely blbě kontrolní součty velkých souborů.

[Filip Jirsák]

Kontrolní součty se ale počítají celočíselně. A tam musí výsledky přesně sedět, ať je spočítáte kdekoliv. Ty samé druhy výpočtů se provádějí např. i u elektronického podepisování (koneckonců i u šifrování), a rozhodně není přípustné, aby elektronický podpis na jednom PC byl ověřen a na jiném by se dokument zdál porušený. Nebo aby na jednom počítači bylo možné dokument rozšifrovat, a na jiném ne.

[xvasek]

K tomu bych jenom přidal, že aby byly výsledky alespoň porovnatelné, musí být výpočet stabilní - tzn. práce se zaokrouhlovací chybou musí být udělaná pro všechny výpočty (během těch několika hodin) tak, aby byl její vliv vždy zanedbatelný. Zde uvedený případ očividně moc stabilní není.

[Věroš]

Ano, to mne taky napadlo, že ten výpočet není numericky stabilní - i když mne to vzhledem k povaze výpočtu překvapuje.

Počkám na novou verzi a budu to reportovat autorům (o důvod víc, proč mám rád open source, tam si to můžu najít a opravit sám, což tady u closed-source nejde )