Optimalizovaná aplikace Einstein@Home I

[Necroman]

Až se mi chce zamáčknout slzu, když si uvědomím, kolik by toho bylo již dnes spočteno, pokud bysme používali optimalizované verze po celou dobu .

[LiborA]

Takže verzí C37 jsem zatím na svém Athlonu64 2800+; 1GB na 333MHz RAM spočítal 6 krátkých (začínají na "Z") WU s nezatíženým kompem (odlogovaný uživatel WinXP). Čas výpočtu 2070 sec. (max. odchylka -0,61 resp. +0,30 sec.). Takže výpočet je to opravdu rychlý. Nechápu ale, jak DUHA dělá ty svý časy, když má relativně pomalejší počítač?

[Bubak]

Nejak nechapu proc tu optim. verzi nevydaj jako oficialni, vypada ze je dostatecne stabilni a ted uz i odzkousena.
Tim by se cely ten projekt zrychlil jeste vic...

[Honza]

To se po mesicich stejne tak muzes ptat u SETI - a stale nic: ani optimalizovana, ani Enhanced.
Nejde jen o to, aby to validizovalo, ale aby byl kod cisty, prohlednuty atp.

Navic zustava problem, ze optimalizace je pouze u Win, ale na ostatni OS neni. Z hlediska konzistence vedeckych vysledku i metodologicky je zadouci, aby se uzival co mozna nejpodobnejsi kod, resp. postup analyzy mezi platformama. Trebas se pletu a nedaval jsem na hodinach metodologie pozor, ale takto mi to pripada a z by to mohlo platit alespon u ved, ktere se radi mezi exaktni.

[JardaM]

Trebas se pletu a nedaval jsem na hodinach metodologie pozor, ale takto mi to pripada a z by to mohlo platit alespon u ved, ktere se radi mezi exaktni.

My jsme metodologii neměli, ale v zásadě máš pravdu. Teď už zbývá jen vyřešit droboulinkou otázku jak to ukočírovat u projektu, kterej je založen na dobrovolnosti a iniciativě. Když se ti to povede, budeš slavnější než Plánička.

[Bubak]

2 Honza: Chapu, ale nejak mi to nesedi s tim, co jsi psal drive. Pokud je v Lin aplikaci bordel a ve Win ne, tak je to tezko "nejpodobnejsi kod". Tak mozna ze by si meli ve Wisconsinu sednout, procistit a sjednotit ten kod do takovy podoby, aby byl jeden a dal se prelozit ruznymi kompilatory....

[vejpuste]

Tak uz taky pocitam s optimalizovanou verzi a casy jsou polovicni. Jenom me trochu prekvapilo, ze originalni i optimalizovana verze maji naprosto stejnou velikost.
Libor

[Bubak]

... originalni i optimalizovana verze maji naprosto stejnou velikost.
Libor

Ano. Nejspis umyslne aby se nemusel upravovat client_state.xml, kde je velikost uvedena. Kdyz se podivas "dovnitr" opt. verze zjistis, ze na konci jsou same nuly....

[Honasss]

2Honza:
Jaks přišel na ten odkaz C37?? Ty umíš maďarsky

edit: aha už chápu... /einstein.phys.uwm.edu/forum

[FordPrefect]

Nechapu, jak muze nekdo delat zvlast verzi pro windows a linux. Detaching from project ...

[azor666]

Teď už zbývá jen vyřešit droboulinkou otázku jak to ukočírovat u projektu, kterej je založen na dobrovolnosti a iniciativě.

S tím bych úplně nesouhlasil, Na dobrovolnosti je založeno jen naše připojení. Za tím projektem musí stát nějaký tým pro který je to "normální práce".
Navíc Einstein pokut vím není open surce, takže o neukočírovatelném vývoji bych nemluvil.

Na projektu je v současné době výkon 40 TFLOPS takže optimalizace se rozhodně vyplatí. Přeci jen zahazování 20 TFLOPS je na pováženou, už jen kvůli elektrice. (o SETI raději nemluvit)

Z hlediska konzistence vedeckych vysledku i metodologicky je zadouci, aby se uzival co mozna nejpodobnejsi kod, resp. postup analyzy mezi platformama.

Naprostý souhlas. Asi ideální by bylo nahodit Einstein2-beta kde by si mohli zkoušet nové optimalizace.

[Honasss]

Ze zahraničních zkušeností:

C37 používá jen x386 instrukce, tedy žádné SSE
Někomu běhá na pentiích A36 lépe než C37, bohužel nemohu potvrdit (do těchto CPU neinvestuju )

[Honza]

2 Honza: Chapu, ale nejak mi to nesedi s tim, co jsi psal drive. Pokud je v Lin aplikaci bordel a ve Win ne, tak je to tezko "nejpodobnejsi kod". Tak mozna ze by si meli ve Wisconsinu sednout, procistit a sjednotit ten kod do takovy podoby, aby byl jeden a dal se prelozit ruznymi kompilatory....

Mozna to na prvni pohled vypada trochu dive.
Vykonny kod muze byt velmi podobny, ale do Linux verze mohou byt staticky linkovane vselijake knihovny a ocuravky, aby to pokud mozno trochu spolehlive chodilo na x verzich Linuxu, ryznch graifckych rozhranich, 32 i 64 bit verzi atp. V tom je vyvoj pro 2K/XP/2k3 a x64 (kterej umi spolehlive emulovat 32-bit Win) trochu jednodussi.
Si dodnes pamatuji, jak mel Carl a Tolu problemi s knihovnama na Linux, takze se to resilo statickym linkovanim pri kompilaci a vselijak. A dost mozna ten madar s optimalizacema narazi na tohle - ze najit vykonny kod mezi ocuravkama, file a graphics knihovnama a slepovanim kolem je trochu problem.

Problem konzistence vysledku mezi platformama, ruznymi druhy CPU a ruznymi kompilacemi je stale- a vsudepritomny...pro vsechny projekty.

[Bubak]

2 Honza: Vypada to divne i na druhy, treti pohled (asi bych mel uz koukat jinam ).
Pises neco o linkovani, ale to je prece vec kompilace. Navic nechapu, co v tom kodu je tak zavisleho na klihovnach. Napada mi jedine grafika (pro me nepouzitelna - at ji klidne vyhodej), ostatni by mohlo mit zavislost jen na glibc.
A to uz se dostavame k tomu, proc ten kod nezverejni. Nebo snad ano? Ja ho nikde nenasel, takze by mi zajimalo, jak se k nemu dostal ten madar....

[Honza]

A to uz se dostavame k tomu, proc ten kod nezverejni. Nebo snad ano? Ja ho nikde nenasel, takze by mi zajimalo, jak se k nemu dostal ten madar....

Jo, to je dobra otazka a mel ji uz forest. Ne, kod jsem nevidel ale taky jsem se po nem nepidil.
Krome grafiky - coz samo o sobe je docela kumst - se muze pouzivat spousty knihoven, treba jako u SETI matematicke na rychle fourierovi transformace a veci kolem. Nevidim do toho tolik, abych to presne popsal, ale neni to pouze o grafice. btw, v te optimalizovane grafika stale jeste je, takze to neni hardcore optimalizace (osekani zbytecnosti) jako ma SETI.
Jinak "klihovna" je hezky preklep Na tech dnes zalezi asi hlavne kniharina...