Forum boinc.cz

Je mozne nejak prejit na optimalizovanyho klienta 4.22 ktery ted nedavno zverejnily pro Sulphur Cycle? Mam ted rozjetej model verzi 4.19 na asi 3%.

Ručně na novou verzi nepřejdeš, pokud chceš zkusit novou verzi, jediným řešením je reset projektu a pak doufat, že sosneš SC model a né klasickej "jednoduchej".
dejv

To ne, resetem projektu to resit nechcu. mel sem spis na mysli neco jako u seti (prekopirovani klienta 3x *.exe file)

JVc píše:Je mozne nejak prejit na optimalizovanyho klienta 4.22 ktery ted nedavno zverejnily pro Sulphur Cycle? Mam ted rozjetej model verzi 4.19 na asi 3%.

Pri alfa-testovani Spinup modelu nekdo vymyslel zpusob, jak upgradnout z verze 4.08 na 4.09 - a chodilo to. Bohuzel upgrade na verzi 4.11 jiz nejde, protoze je zmenilo nazvoslovi souboru a dalsi veci. [Po 50 letech SpinUp modelu a prvnim vetsim uploadu nechodi trickle na server (kazdy trickle ma ve SpinUp pres 50kb), tudiz nechodi grafy atp. Navic je dalsich bug po 100 letech, kdyz upload presahuje 30MB atp. Ale to je jina].
Update z 4.19 SC na 4.22 by teoreticky mohl jit - myslim si, ze datove vstupni soubory jsou identicke (jejich struktura datain) a vystupni nejspise take. Zmeny jsou v grafice a samotnych executables, jak jsem psal.

Znamena to rucne se hrabat v client_state.xml a ve \slots.
Sam o teto zmene uvazuji - resp. to, ze ji zkusim, protoze se pri pocitani na zacatku modelu potencionalne vyplati (narust rychlosti atp.). Pocitaji ze mi 4 SC 4.19 modely (2%, 9%, 21% a posledni 95% do ktereho hrabat nebudu) a na zkousku jeden SC 4.22. Mohu tedy odvodit, co se kde meni atp.
Obecne postup: zakazat v BOINCu network, radne zazalohovat, upravit patricne soubory, znovu pustit a pokud to pojede nejakou dobu dobre, tak teprve povolt network.
Pokud se to podela a model skonci, neodesle se na server a muze se dale pokracovat ze zalohy.

Estli budu mit cas, tak to zkusim a o vysledku bych reportoval...pripadne nejaky navod. Hmm, a taky nekam dat ty SC 4.22 soubory...

forest píše:Opravdu velká škoda že nejsou k dispozici zdrojáky od ostatních projektù Napøíklad u CPDN by ten rozdíl byl asi nejznatelnìjší, pøedpokládám o nìkolik set hodin na prùmìrném PC.

Jsem zvedavy, jak dlouho by jsi pocital optimalizovanou verzi nez by model spadnul nebo spocital referencni jednotku

To myslím není argument pro to, proč neuvolnit zdrojáky, i když ohledně nemožnosti uvolnit zdrojáky CPDN už se zde psalo v jiném threadu. Je to paradoxní že ti co k nim přístup mají jej neoptimalizují proto, že na testování nemají čas (nebo chuť) a ti co by čas do testování a optimalizování rádi investovali, ti zase k nim nemají přístup Proto se tedy každá WU na CPDN počítá o několik set hodin dýl než by se počítat musela, což se mně zdá jako dost velké mrhání prostředků a výkonu, který jim lidi poskytují.

2 forest: zdrojaky od CPDN jsme tady s Honzou uz probirali - u CPDN je problem, ze je zalozen na zdroji kodu,ktery jim nepatri, takze nemaji pravo ho zverejnit. Dalsi problem je quorum 1 - takze neni zadna kontrola a zmena, ktera by ovlivnila vysledky at uz zamerne nebo omylem, by pak mohla lehce vracet spatne vysledky bez to aniz by byla objevena. Pri diskuzi jsem uz uvedl, ze prvni prekazka by se asi dala prekonat - napriklad zapojenim jen vybranych dobrovolniku, kteri by byli vazani smlouvou. Druhy problem by se asi musel resit certifikovanim verzi a distribuci jen z jednoho oficialniho zdroje.

Necroman píše:Pouzil jsem ten, co je na truxovych strankach a v pohode, je to komandlajnova verze, takze hezky spustit konzoli a zadat např "rescmp.exe result.sah sample_result.sah" a ono to porovna, jestli je to v toleranci oproti vysledku te same WU z originalniho programu SETI.

Ja uz videl, ze na nekterych masinach skutecne nejede - asi to pouziva nejake DLL, ktere nejsou defaultne na vsech PC. Budu se na to muset podivat, ale nevim, kdy se k tomu dostanu.

Hele, vzdyt preci nedavno byly vydane nove kompilace, ktere jsou zamereny predevsim na zvyseni vykonu vypoctu.
A co ten navod na upgrade SC 4.19 -> 4.22 SC.

Myslim, ze jsi trochu neobjektivni pri posuzovani CPDN z hlediska optimalizaci. Rozhodne jim to neni jedno a snazi se...od zacatku CPDN. Jak uz jsem mnohokrate psal, i Carl by rad 64-bit verzi a snazil se o to...

Se zdrojakama je fakt problem, to uznavam.
Na Rosette je zatim jenom slibuji, jinde rikaji, ze uz optimalizovani jsou.
U CPDN muzes porovnat vypocetni casy ruznych verzi a uvidis, ze tam rozdil je. Nerikam, ze nemuze byt vetsi, ale neni to takova sranda jako u SETI ci jinych jednoduchych projektu.

Ohledne validizace se da snadno pouzivat prave ten vystup teplot, srazek atp. Na grafu je dost dobre videt, jestli to sedi a "referencnim" modelem - tj takovym, ktery ma standardni parametry a od ktereho se vyviji cely prostor parametru.

Honza píše:U CPDN muzes porovnat vypocetni casy ruznych verzi a uvidis, ze tam rozdil je. Nerikam, ze nemuze byt vetsi, ale neni to takova sranda jako u SETI ci jinych jednoduchych projektu.

Ty argumenty s uzavrenosti zdrojaku kvuli autorskym pravum chapu, ale tohle nahore je dost spatny argument. Ve skutecnosti je mnohem slozitejsi optimalizovat neco co je jednoduche, nez neco, co je slozite a velike - to urcite pochopi kazdy. Ve slozitem programu je proste mnohem vice mist, kde se daji nalezt zlepseni, nez v jednoduchem. Kdyz uz je neco jednoduche, je velmi tezke to jeste zjednodusit (tedy zoptimalizovat), protoze tam zbyva mnohem mene moznosti. Pres relativni jednoduchost S@H algoritmu, se aplikaci pomoci chytrych triku podarilo urychlit vuci originalu nekolikanasobne, a to si osobne myslim, ze tam stale jeste jsou rezervy. Takovych moznosti skyta slozita aplikace mnohem vice, a proto je velmi pravdepodobne, ze by mohla jit urychlit jeste lepe nez S@H. Jeden clovek, ale zridka dokaze v optimalizaci udelat to, co dokaze udelat komunita vyvojaru. Kazdy ma trochu jine znalosti a zkusentosti a tedy cim vice lidi se zapoji do zkoumani zdrojaku, tim lepsi vysledky se daji ocekavat. U S@H k optimializaci taky prispela rada lidi, a to diky tomu, ze zdroj i vylepseni byly otevrene.

Je to furt dokola, CPDN se počítá jednou a není třeba model rozesílat dalším třem lidem. SETI a jemu podobné projekty se rozesílají x lidem - mnohonásobně větší výpočetní čas a výsledek? Zatím u mnoha projektů nikde....
dejv

trux píše:Ve slozitem programu je proste mnohem vice mist, kde se daji nalezt zlepseni, nez v jednoduchem.

Jo, sanci ke zlepseni ve bohatem programovem baliku je samosebou statisticky vice, to kazdy chape. A taky je tam vic veci, jak neco podelat.

Krome donekonecna zminovaneho problemu ze zdrojaky, autorskymi pravy atp. je zde zasadni problem validity.
U jednoducheho SETI staci spocist referencni jednotku a tim je prijmuto/zamitnuto, ze aplikace je validni.
Rosetta si muze dovolit vlastni pristup k problemu, ktery ji dela jedinecnym a presto je muze na poli studia proteinu obhajit - hlavne kdyz bude mit vysledky. Nemaji problem s pravy na zverejneni kodu, ale maji stazeny zadek z toho, aby si nekdo nenarokoval nejaky velky kredit ci do kodu neco nezanesl.
U CPDN je treba tydnu a mesicu na testovani a dalsich x mesicu a roku, ze zmeneny model prijme vedecka komunita. Navic tim vyvstava problem, ze ostatni instituce budou pouzivat jine modely (s jinym zdrojakem, jinou kompilaci atp.) a tak tim vznikne mezera, kterou bude snadne napadnou v ramci vedecke komunity. Pokud doprogramuji techinku tricklu (prubezneho odesilani vysledku), grafiku atp, samotne vedecke vypocty to meneni. Je snazsi obhajit sirsi spektrum paramtru klimatickych modelu, nez uziti vlastnich modelu, ktere za sebou nemaji dekady tradice].
SETI je nemusi s nikym srovnavat, nejake srovnani vysledku (kde ze jsou?) v ramci vedecke komunity se moc nekona.

Life science projekty mohou experimentalne validizovat sve nalezi, CPDN je musi obhajovat mezi vysledky jinych projektu podobneho zamereni, u SETI tohle trochu odpada (mohou si napriklad vytvorit umela data se zanesenym signalem a na tom to testovat - tedy v abstraktni rovine).
Jsou proste parametry projektu, ktere se dost lisi - a maji primy vliv na zasahy do zdrojaku (nebo zdrzenlist k takovym krokum).

Takze mi to ztahlo novy model SC s verzi 4.22 a jak se ukazuje, vypocet se zpomalil na jeden trickle asi o jednu hodinu. Pri pocitani s verzi 4.19 mi to ukazovalo priblizne 39,458 = cca 11 hodin a ted s verzi 4.22 mi to pocita za 43,721= cca 12,2 hodiny.

Také jsem zaznamenal zpomalení u starých Celeronů 1,1 Ghz. U novějších strojů jsem naopak zaznamenal zrychlení.

Mohu jen potvrdit co pise Barbar

No nevim, zda je to pravidlem, ale myslim ze Intel Pentium M 730 jeste nepatri mezi starsi stroje.