Forum boinc.cz

Zaujimalo by ma aky optimalizovany klient by ste mi dporocuili na climaprediction.
Na procak Barton 2200mhz

Na setiho je toho tunak kopu ale na climaprediciton som nic nenasiel.A pripadne by som poziadal i o nejaky jednoduchy navod.
Momentalne mam mam boinc 4.45


dik

Na CPDN optimalizace neexistuje (alespon o ní nevím).

no ale pokial viem tak sa da optimalizovat snad i ten manager..........
teda ak je to k niecomu

Optimalizace samotného Managera (soubor Boinc.exe) existuje...ale ta pomůže akorát ke zvýšení benchmarku procesoru a tím pádem si budeš nárokovat větším kredit.....to je ti ale u CPDN na nic, protože každý dostává stejný kredit za spočítaný model...Optimalizace Boincu pomáhá u jiných projektů.

Presne tak, jak pise Bony - u CPDN se pocita odvedena prace a ne (ne)smyslny benchmark.

Optimalizovat CPDN je velmi osemetne. 1 milion radek zdrojaku ve Fortranu s C++ (40MB v 600 souborech) vyvijeny po desitky let a aby takto extremne slozite vypocty davali stejne vysledky na vsech CPU a platformach a model neuletel do zmrzle koule je ukol casove narocny a temer nadlidsky.
Uziti -SSE2 nejspise zpusobilo padani CPDN na nekterych starsich procesorech AMD.

Experimenty se 64-bitovou verzi nejsou take uplne snadne - navysseni rychlosti je hezke, ale modely nestabilni. O tom uz jsem ale psal...

Honza píše:Optimalizovat CPDN je velmi osemetne. 1 milion radek zdrojaku ve Fortranu s C++ (40MB v 600 souborech) vyvijeny po desitky let a aby takto extremne slozite vypocty davali stejne vysledky na vsech CPU a platformach a model neuletel do zmrzle koule je ukol casove narocny a temer nadlidsky.

No, ono to neni zase az tak hrozne. Casove narocne to sice casto je, ale milon radku rozhodne neznamena, ze je clovek musi vsechny studovat. Optimalizace se vetsinou provadi dvema zpusoby:

Prvni neni narocny temer vubce a dokaze ho delat i clovek, ktery neni zadny veliky programator, ale ma jen zkusenosti s kompilaci - staci v kompileru nastavit parametry specificke pro urcite procesory - jiz to muze vykon zvysit klidne i nekolikanasobne.

Druhy zpusob je uz narocnejsi a vyzaduje skutecneho profika v programovani, ale neznamena to, ze musi cely program znat. Dela se to tak, ze se program zkompiluje s pridanim kodu pro profiler a pak se jim zanalyzuje - ten ukaze presne, ktere funkce ci radky jsou volany nejcasteji, a ktere zaberou nejvice casu. Pak se programator soustredi na optimalizaci prave techto kritickych mist, coz predstavuje jen mizive procento zdrojoveho kodu.

To, ze temer vsechny projekty s vyjimkou SETI nemaji zdrojovy kod verejny, povazuji za velice nestastne, a je to hlavni duvod proc 90% vykonu venuji prave S@H. Dokud projekty nezverejni kod, a dokud clovek nevidi co vlastne pocita a jestli je vykon skutecne vyuzit smysluplne, nehodlam na nich plytvat strojovym casem. Uz to, ze CPDN pouziva Fortranovy program z sedesatych let a nejsou ochotni ho zverejnit, svedci o svem. Vsadim vlastni boty na to, ze ten vypocet neskutecne plytva vasim strojovym casem a zbytecne uzira vykon, ktery by mohl byt vyuzit mnohem lepe a efektivneji. Vzhledem k veku programu a pouzitemu jazyku, bych se nedivil, kdyby aplikace sla zoptimalizovat ne 2x jako u S@H, ale velmi pravdepodobne 10x, a dost mozna i o nekolik radu. Je skutecne velmi smutne, ze se vyvojari CPDN nechyti za nos a zdrojaky nezverejni - bylo by to ke prospechu vsech. To, ze jej doposud nezverejnili, svedci jen o tom, ze je v nich bud neco proprietarniho, co chteji vyuzit komercne, nebo je v tom neco, za co se stydi (mizerne vyuziti darovaneho strojoveho casu), anebo neco, co chteji zatajit (pocitani neceho jineho, nez tvrdi).

Dokud CPDN a jine projekty svuj pristup nezmeni, nikdy nemohou pocitat s takovou popularitou jako S@H.

Optimalizace jsme jiz diskutovali a neni k tomu asi moc co dodat.
Snad jen to, ze optimalizovat CPDN nejak moc nejde globalne - tedy nastavenim kompilatoru. Ruzne promenne se pocitaji s ruznou presnosti a prave optimalizace nejak vedla k nekonzistentnim vysledkum. Ani prechod na ciste 64-bit pry neni resenim.

Ano, neni treba znat ten kod cely a uz vubec neni treba jej cely optimalizovat. Stacilo by optimalizovat hlavne ty vypocty. Jenze ty jsou rozesete v ruznych mistech.

Problem s copyrightem uz jsem take diskutovali. Neni s moci CPDN team kod uvolnit, protoze proste neni jejich. Maji jen pravo k jeho uzivani. A UK Met Office svuj kod jentak neda. Nejspis v autorstvi kodu za ta desetileti figuruji i dalsi subjekty - statnich instituce, univerzity, mozna i nejake non-UK/zahranicni subjekty atp.

Nejsem si jist tim, kolik naroste vykon optimalizaci kodu. Narust s optimalizace kompilaci lze odhadnout z pokusu, ktere byly. Jednalo se radove o desitky procent, mozna tak 1/3 vykonu diky pouziti SSE2 a 64-bitu. Urcite by to slo lepe, mozna o 1/2 pouze optimalizaci kompilace. Vzdy to vsak koncilo nestabilitou modelu, nekonzistenci mezi ruznymi CPU/OS a co ja vim jake jeste obtize.
Optimalizovat by sel i pristup k souborum. To by sice vypocet moc neurychlilo (protoze to jde stejne pres cache), ale setril by se tim trochu disk; s mensi defragmentaci.

Hlavni obtiz vidim v casove narocnosti. Nejde jen o limit casovych moznosti programaoru (Carl a Tolu), ale i testovani. Trva tydny a mesice na nejlepsich desktopech nove verze otestovat (primitivni SETI si vystaci s hodinama). Pokud s tim bude CPDN spokojen, je zde jeste problem prijmuti vedeckou komunitou, srovnani s UK Met Office a dalsimi subjekty. To trva v dobrem pripade mesice, v horsim trebas 2 roky.
Jelikoz se jedna o velmi citlive tema, kde na vysledcich velmi zalezi, nikdo se do toho tolik nehrne. Verim, ze obdobny jev - zdrzenlivost vuci optimalizacich - je pozorovatelny i dalsich vedeckcyh projektu, ktere chteji publikovat nejake vysledky. Presto se o to u CPDN snazi, zkousi ruzne kompilatory i parametry nastaveni a...vetsinou se narazi.

U SETI moc zprav o vysledcich pocitani nebo dokonce relane vysledky asi clovek cekat nemuze. Proto tomuto projektu svuj cas moc nevenuji. Ale to je osobni volba a to sem asi nepatri.

Proc ostatni projekty moc neoptimalizuji? Nebo jsem to moc nevidel...mas nekde k tomu diskusi, kde by byly videt nejake vysledky?
Jak vychazi 64-bit u ostatnich projektu?
Proc nezkousi -paralel optimazici?
Kolik projektu ma vice nez jednu aplikaci, kterou by bylo treba optimalizovat?

Honza píše:Snad jen to, ze optimalizovat CPDN nejak moc nejde globalne - tedy nastavenim kompilatoru. Ruzne promenne se pocitaji s ruznou presnosti a prave optimalizace nejak vedla k nekonzistentnim vysledkum.

To se na me nezlob, ale to je dost nesmysl. CPU-specificke optimalizace v zadnem pripade neovlivnuji vysledky nebo algoritmy, ale jen a pouze zamenuji jiste sekvence strojoveho kodu, kodem dostupnym jen u specifickeho CPU, ktery je mnohem efektivnejsi ale jinak identicky s tim obecnym. Takze pokud maji po takove optimalizaci nestabilni vysledky, znamena to jen, ze bud nevedi presne co delaji, nebo nasli chybu kompileru (a meli by to tedy resit s pomoci Intelu - pokud vim pouzivaji Intel kompiler), anebo maji v programu vazne chyby. Tomu poslednimu nasvedcuje i znacna nestabilita CPDN. To ze je ta aplikace tak nestabilni na znacnem procentu pocitacu, svedci o tom, ze v ni jsou skutecne vazne problemy. Je dost nesmysl, aby algoritmus daval ruzne vysledky podle zateze pocitace. To by temer vylucovalo pouziti pocitacu na cokoli jen trochu duleziteho. Chyby pameti ci procesoru mohou nejake chyby vysledku operace zpusobit skutecne jen ve vyjimecnem pripade, a i to je vetsinou zabezpeceno ruznymi mechanismy na nekolika urovnich. Ta nestabilita CPDN spise svedci o zavaznych chybach aplikace, nez o problemech hardware.

Honza píše:Ano, neni treba znat ten kod cely a uz vubec neni treba jej cely optimalizovat. Stacilo by optimalizovat hlavne ty vypocty. Jenze ty jsou rozesete v ruznych mistech.

To neni zadny problem. Z analyzy profileru se proste vybere nejdriv to nejhorsi misto, zoptimalizuje se, a pak se jde na dalsi. Prave tech prvnich par nejhorsich mist dava nejvetsi zlepseni rychlosti.

Honza píše:Problem s copyrightem uz jsem take diskutovali. Neni s moci CPDN team kod uvolnit, protoze proste neni jejich. Maji jen pravo k jeho uzivani. A UK Met Office svuj kod jentak neda. Nejspis v autorstvi kodu za ta desetileti figuruji i dalsi subjekty - statnich instituce, univerzity, mozna i nejake non-UK/zahranicni subjekty atp.

UK Met Office nabizi kod celkem bez problemu cele britske akademicke komunite (viz. treba http://www.met.rdg.ac.uk/~uwern/UM/support/), a nemyslim si, ze by nemeli na vylepsovani zajem. Kdyz uz nic jineho, meli by se tedy snazit do optimalizace zapojit vice britskych vedcu a studentu. Doposud je na projekt Met Office / NCAS napojeno 15 britskych univerzit, to znamena, ze ke zdrojaku ma uz i tak pristup znacny pocet lidi, takze bych se divil, kdyby Met Office na jeho utajeni nejak extremne lpel. Vsadim se, ze by o sirsi spolupraci klidne byli ochotni diskutovat, jen kdyby se je nekdo tech soucasnych uzivatelu k tomu snazil primet.

OK, na optimazaci jses jiste vetsi specialista. Rad bych znal tvuj komentar na nasledujici....

Basically the past 4-6 weeks I have uncovered a lot of serious issues pertaining to running a coupled model as a 32-bit job a la our old slab model. The main problem is the coupling between the atmosphere & ocean is very sensitive, and the atmosphere works fine in 32-bit but the ocean wants 64-bit; so when you couple that all hell can break loose! Most annoyingly things seemed to drift and go unstable but you wouldn't see it until timestep 20,000 or so!

But we seem to have worked these issues out OK, the problem is in the higher optimizations such as the "-ax" options on the Intel Fortran compiler to use SSE2 extensions, Pentium IV stuff etc, will truncate things enough on the 32-bit floats so that eventually it wrecks things. So we are not using the "-ax" optimizations now; although we are able to use the version 9 compiler which seems pretty fast anyway.

No, jestli vsechny akadamicke instituce v UK pouzivaji leta patny kod, tak to potes.

Nejde o utajeni kodu, ale o jeho zverejneni. Na tom odkazu sami pisou, ze nektere informace nejsou public. JO, UK univerzity k tomu maji pristup - kdo dalsi?
Univerzity, ktere ten kod pouzivaji na nejakem svem klusteru nebo pro studyjni ucely, nebudou asi chtit investovat prostredky do optimalizace. Stejne tak samotny UK Met Office, ktery mam novou a dost vykonnou hracku a jde jim o spolehlivost a ne tolik o rychlost. Zustava asi CPDN se svym nasazenim na desktop masiny, kde by se to uzilo nejvice. Jenze ty ted maji dost starosti se zapracovanim pokrocilejsich modelu a rozjeti dalsich projektu v ramci CPDN.

Jak ze je aplikace nestabilni na znacmen procentu pocitacu? Muzes nejak kvantifikovat? Kolik z nich je overclockovanych? Jak zjistit, ze ty pocitace jsou jinak OK?
Jak se na nekolika urovnich zabezpecuje chyba pameti v tak slozitych vypoctech?

Honza píše:OK, na optimazaci jses jiste vetsi specialista. Rad bych znal tvuj komentar na nasledujici....

No, on preci jen optimalizovana kompilace programu chce trochu vic nez jen proste zapnout "-ax" option (Processor-dispatch option - automaticky v realnem case vola funkce nebo knihovny specificke pro dany detekovany procesor). Obzvlaste pokud maji smichane 32 a 64 bitove prostredi, tak musi zajistit zarovnani (alignment) promennych a pametovych bloku, anebo i zamezit cross-opimalizaci pres tyto dve casti, a havne poradne pohlidat konverzi typu. Krome "-ax" jsou jeste desitky dalsich nastaveni kompilatoru, ktere mohou mit obrovsky vliv na rychlost. Navic neni vzdy smysluplne pouzivat univerzalni -ax, nebo jine globalni optimalizace, a optimalizaci jen na rychlost. U vetsiny programu (a obzvalste u vetsich a komplikovanejsich aplikaci) je spise potreba optimalizovat na misto, omezi univerzalni kod a dynamicke knihovny, kompilovat kazdy modul s dobre uvazenymi (a pokud mozno otestovanymi) parametry kompileru, a pouzivat optimalizaci jen na mistech, kde je to skutecne potreba. Ono totiz optimalizace na cas vetsinou vygeneruje az nekolikanasobne objemnejsi kod, ktery pak zabere mnohem vice operacni pameti, a to je samozrejme kontraproduktivni, protoze to tu tezce ziskanou rychlost zase zbytecne srazi. Holt clovek i pri optimalizaci musi trochu myslet, mit nejake zusenosti, a hlavne vedet jak takovy program, kompilator i vlastni pocitac presne funguji - to rozhodne pomaha. Nestaci jen znat programovaci jazyk a matematiku. Nemluve o tom, ze skutecna optimalizace pak znamena mnohem vice nez jen pridavani parametru kompilatoru - pro to, aby kmpilator dobre optimalizoval, je casto nutne nektere funkce dost pozmenit, ci kompletne prepsat, a to nekdy dokonce tak paradoxne, ze je takovy kod na prvni pohled mnohem pomalejsi a delsi.

Honza píše:Nejde o utajeni kodu, ale o jeho zverejneni. Na tom odkazu sami pisou, ze nektere informace nejsou public.

Jo, tomu rozumim, ale nemyslim, ze je problem poskytnout kod dobrovolnikum zavazanych pod NDA (non-disclosure agreement)

Honza píše:Univerzity, ktere ten kod pouzivaji na nejakem svem klusteru nebo pro studyjni ucely, nebudou asi chtit investovat prostredky do optimalizace. Stejne tak samotny UK Met Office, ktery mam novou a dost vykonnou hracku a jde jim o spolehlivost a ne tolik o rychlost.

Berkeley nestoji pomoc dobrovolniku ani korunu (naopak velka cast lidi, kteri prispivaji programatorsky, prispivaji i penezne - staci se podivat na hvezdicky na diskuzich o optimalizaci). A prave pokud jde o stabilitu, meli by radeji kod otevrit, nebo alespon poskytnout dobrovolnikum pod NDA. Tito dobrovolni vyvojari S@H nejen podstatne zrychlili, ale nasli i nekolik chyb, a zlepsili stabilitu. Vic oci proste vic vidi. Kazdy ma trochu jine zkusenosti a jine schopnosti - v S@H jsou assembleri jako Tetsuji, matematici jako Harald, kompiler experti jako Nad, a spousta dalsich sikovnych lidi, kteri s vylepsovanim kodu pomahaji.

Honza píše:Jak ze je aplikace nestabilni na znacmen procentu pocitacu? Muzes nejak kvantifikovat? Kolik z nich je overclockovanych? Jak zjistit, ze ty pocitace jsou jinak OK?

No to skutecne netusim, ale podle toho, jak tady i na jinych forech neustale slysim o crashich pod CPDN, a podle toho, ze i sam rikas, ze CPDN je mnohem citlivejsi, jak na hardware tak na optimalizace, a taky kdyz vidim, ze si stezujou lidi, kterym pocitac bez problemu projde dlouhym zatezkavacim testovacim programem, ale sejme ho CPDN, tak spise nabyvam dojem, ze nejaky problem prece jen muze na strane CPDN byt.

Honza píše:Jak se na nekolika urovnich zabezpecuje chyba pameti v tak slozitych vypoctech?

Jednodussi nebo slozitejsi kontrolni, regulacni a opravne mechanismy jsou skutecne zabudovane na vsech urovnich - od samotnych pametovych cipu, pres cele pametove bloky (a nejen ECC pameti), systemove cipy, cpu, BIOS, OS, kompilery, az po aplikace. Samozrejme, kdyz jsou ty problemy s pameti zavazne, tak k poskozeni dat dojit muze, ale je mi divne kdyz vidim psat lidi, kterym dlouhodoby test pameti neukaze problem, ale CPDN prece jen spadne. Ale i v pripade, ze je to skutecne hardwarem, tak pravidelne spadnuti aplikace nebo dokonce OS, znamena uz docela znacny problem - to, ze se chyba pameti (normalne jde jen o nejakou tu bunku) trefi zrovna do vykonneho kodu, nebo do nejakeho pointeru (chyba v datech by se hned tak neprojevila crashem), muze taky znamenat, ze ta aplikace bud prilis casto realokuje casti vykonneho kodu, nebo je vykonny kod neskutence roztazeny, nebo se zbytecne casto prealokovavaji bloky pameti pointru,... Netvrdim, ze je tam nutne neco spatne, ale pokud je to tak komplexni, ze stabilita je problemem, pak by mozna stalo za uvahu zabudovat vice mechanismu na kontrolu a zpracovavani takovych vyjimecnych udalosti (exception handling). To ale skutecne muze byt nad moznosti jen dvou nebo tri vyvojaru (nbo kolik jich tam je), jejichz hlavnim ukolem jsou predevsim vedecke vysledky a tedy hlavne matematicke algoritmy a mene jiz systemarina a low-level programovani. Prave proto by otverenost kodu byla take vhodna.

Honza píše:Stejne tak samotny UK Met Office, ktery mam novou a dost vykonnou hracku a jde jim o spolehlivost a ne tolik o rychlost. Zustava asi CPDN se svym nasazenim na desktop masiny, kde by se to uzilo nejvice. Jenze ty ted maji dost starosti se zapracovanim pokrocilejsich modelu a rozjeti dalsich projektu v ramci CPDN.

A nebylo by lepší si dát napřed trochu práce s optimalizací a až potom se vrhat do dalších a dalších modelů?
Myslím si že urychlením o 1/3 (jak jsi to odhadl sám, spíše si myslím minimálně 2x jako u Seti) by tu časovou prodlevu (než by se pořádná optimalizace udělala a otestovala) rychle dohnali.

Mám obdobný pohlad na věc jako Trux, je to mrhání výpočetním časem, energií a v závěru i penězmi nás všech. To nemyslím pouze projekt CPDN, ale všechny projekty, u kterých nejsou aplikace náležitě oprimalizovány.
Ale i tak budu pokračovat se stejným rozdělením výkonu mezi projekty, pouze mně trochu mrzí ten ,,promrhaný čas,,

@ forest - souhlas. Urcite by to bylo lepsi, ale takto to dela pouze SETI. Ostatni maji kod uzavreny a neoptimalizovany zaroven - a to maji pouze jednu jednodussi aplikaci.
U CPDN je tlak na nove modely a nove vypocty, protoze jsou na to nejspis vazane granty, lidi na tom delaji projekty vcetne doktoratu atp. Takze Carl ani Tolu si nemohou moc vyskakovat a na nejake low-level optimalizace nemuze byt pomysleni.
Delat optimalizce u CPDN znamena pro vedatory mesice zdrzeni kvuli testovani stability i konzistence vysledku, nasledne tydny oprat a dalsi mesice testovani. Vim, ze by se takove usili ve finale vic nez vratilo...zkus ale nekoho z akademiku presvedcit

@ trux - otevreny kod SETI jiste pomuze. Jak s optimalizaci, tak s nalezenim chyb ci navrhem lepsich algoritmu (vedeckych i programatorskych). Nejsem si jist, kolik programatoru by rozumnelo tak velkemu projektu jako CPDN natolik, aby byly schopni chyby nalezt ci vhodne optimalizovat. U SETI se proste zkusi jina sada paramtru kompilatoru a za hodinu, dve je vysledek videt. U CPDN to trva nekdy par hodin a model spadne, nekdy tyden. Nektere veci se poznaji az po spocitani celeho modelu - napr. SC az v 5. fazi vypoctu. Pravda, nektere veci lze testovat i jinak - napriklad pouzitim extra kratkych modelu (144 timestepu) jsme testovali client-server komunikaci, upload a podobne.

Za optimalizaci CPDN bylo dost hlasu - pocinaje pouzitim SSE2/3 nebo 64-bitoveho kodu. Snad budou mit kluci po vypusteni Coupled Modelu cas, aby jim trebas nekdo dal tipy a mohli jsme to odzkouset...

No a teď si položme otázku, zda je větší mrchání času neoptimalizovaný klient CPDN či to, že u SETI se jedna jednotka počítá 4x
dejv

Overeni vysledku je bezesporu skvela vec. V prvni rade jde prece o vedecke vysledky z techto vypoctu a zmrsene vysledky, at uz zamerne ci jakkoli jinak jsou k nicemu

dejvidek píše:No a teï si položme otázku, zda je vìtší mrchání èasu neoptimalizovaný klient CPDN èi to, že u SETI se jedna jednotka poèítá 4x

OK, zpet k tematu. Novejsi build Coupled Modelu, resp. jeho SpinUp faze (200let v jedne fazy, 5.184.000 timestepu) je na AMD of cca 20% rychlejsi. Take doslo k dalsi zajimave zmene - drive rychlejsi Linux ted ztraci tuto vyhodu a snad naopak Win jsou s timto modelem trochu rychlejsi.
Pokud se nastaveni kompilatoru osvedci, Carl nejspis prekompiluje i klasicky slab model a sulphur cycle.
BOINCView u SpinUp jobu mi hlasi, ze za 150dni bude hotovy - pokud to do ty doby nespadne, nebude se model vracet (coz je u tohoto typu ulohy vcelku bezne) atp.