Forum boinc.cz

S tím 1 Creditem není až tak úplně vedle, protože já jsem si například nárokoval v průměru 0,25/WU po optimalizaci.
Je ale pravdou, že jsem na některých WU dostal o dost více než jsem si nárokoval.

Myslím že to byl normální dotaz, nevím proč by se měl mazat

problém je že ten kredit není fixován na WU jako u EAH,CPDN, a +-i u SAH ale je přidělován standartním spůsobem Benchmark*čas
Dále je rozdíl že oproti EAH-SAH kde bylo 100k běžných userů a pár tisíc optimalizátorů tak zde je ten poměr skoro otočený. Většina používá kalibraci BS takže to není tak znát.
Další extrém je 30ti násobné zrychlení.
Pokud je zapnutá kalibrace a ono nemá skoro smysl počítat optimalizovanou aplikaci bez kalibrace (tedy pokut nás zajímají nějaké kredity-podle názvu treádu soudím že ano) tak je najednou za 3 minutovou jednotku 10kreditů

Pravda stím mazáním sem to v tomhle případě trohu přehnal.

EDIT: c) protože pokut sem nikdo nedá nějaký konkrétní měření tak tu budeme omílat jen to co všichni vědí. Že intel je rychlejší na SETI a nejvýhodnější je projekt s optimalizací

jsem si rikal, kdo takovyhle thread muze zalozil. Proc nejsem prekvapeny...?

Mezi developerama byla nedavno debata na toto tema. Resume je pro me snad jen to, ktere jsem zastaval uz davno - ze benchmark*cas je pekne blby mereni, protoze nezohlednuje napriklad rychlost pameti atp.
Nekterym se pozdaval koncept fixniho oceneni, ktery od zacatku pouziva CPDN a na ktery presel EAN. Ale i ten ma nevyhody, protoze nezohlednuje to, ze nekterym aplikacim se lepe dari na starych Intelech, nekterym na novych AMD, doladit to na G5 uz zacina byt problem a jak je to s Intel Core 2 zatim ani vetsina developeru netusi (btw, Conroe si vede velmi dobre).

Vzdy jsem byl odpurce primitniho konceptu: pocitani = ziskavani kreditu a neni divu, ze se mi nezamlouva, pokud mi to nekdo byt naznakem nebo ve vtipu podsouva - napriklad v souvislosti se SZTAKI.
Krome toho, ze pocitam prubezne prakticky vsechny projekty (treba jeste predtim, nez se tady o nic vi), se taky zajimam o to, co ze pocita. A taky kvuli dalsim produktum z BOINC souvisejicim, jak napriklad Boinc Studio nebo BAM, ktere jsem zde propagoval.

Nedavne optimalizace na SZTAKI vytvorila docela specificke podminky, ktere mi umoznili u urcite testovani. Zajimalo me take,
- jak se postavi k optimalizacim (vs. Einstein). Vysledkem je rozumny pristup - prislib zakomponovani optimalizaci do oficialni verze.
- optimalizaci byla (klasicky) otevrena otazka validity vysledku, ktera pro me dodnes nebyla uspokojive zodpovezena. Adam sice priznal, ze podle matematiku ma aplikaci minimalne mezery, ale jak se to projevilo na 11. a 12. dimenzi (mi) jasne zatim neni.
- pocitani SZTAKI v souvislosti s BAM zpusobuje vytvoreni noveho hostID pri kazdem kontaktu se serverem (dusledky si snad v takove konstalaci lze odvodit). Krome postnuti rucni opravy na strane klienta (stejne tak na nekterych dalsich projektech) jsem se dozvedel, ze Adam neni tak uplne svym panem a ma nekdy svazane ruce (asi jako na CPDN). O problemu se vi...
- diky tomu jsem objevil take bug v BAM, ktery Willy zatim opravit neumi, protoze neni schopne chybu replikovat - jedna se o problem toho, ze zaskrtavani projektu na webove strance s nekterym pripojenim k netu nechodi (asi pres nektere HW firewally)
- jelikoz nemam moc pocitacu, nemuzu zkusit zatizeni BS velkym mnozstvim masin, tak tedy alespon velkym mnozstvim WU. Zajimalo me, jak na to bude BOINC core v momente, kdy si musi poradit s opravdu velkym mnozstvim WU v client_state.xml. Hledal jsem otazku na to, proc boinc core generuje klidne giga cteni a zapisu. Mimochodem je to zpusobene tim, ze pred zapsanim noveho client_state.xml se nejprve udelat client_state_next.xml a teprve pote se prepise puvodni. A kdyz ten file ma 2 mega a meni se pri kazdem ukonceni nebo stahnuti nove WU ci pri uploadu...

Tedy neslo mi o SZTAKI jako takove, ale jaksi o chovani boinc core, boinc studia (btw, Doc do nej zapracoval podporu Intel Core 2 a pripadne me pozval na veceri, jestli se dotretice objevim na Korsice), BAM (bug tam stale je)...a jestli jsem pomohl BOINC.sk, tak ze stalo

Abych se taky jednou zapojil:
Po skončení Albertů S4 jsem si krátce zaexperimentoval na dvou mašinách P4 Northwood 2,8, RAM 256 MB.
Následující výsledky jsou přibližné a udávají počet creditů na 1 mašině za 24h:
CPDN.........320
EAH S5.......350
Rosetta.......170
QAH...........200

Výsledek CPDN je poněkud starší, ale do přehledu celkem slušně zapadá.

jsem si rikal, kdo takovyhle thread muze zalozil. Proc nejsem prekvapeny...?

njn. mám docela chuť toho půlku smazat a zbytek rozdělit do ostatních treádů o kreditu. Ale prej na mazání to není tak nic

Fixní kredit za jednotku je naprosto spravedlivy. To že někde je rychlejší Intel a někde Mac není chyba BOINC, ale intelu (AMD). Přece nebudete jednomu malíři pokojů platit 2x tolik za m2, protože to maluje štětkou a ne válečkem. Jak, ale určit délku jednotky? U problémů typu milion kombinací šifry to nebude problém, ale u EAH je už krásně vydět jak C/h lítá o víc jak 10% (na Bruceho farmě, takže mohu zanedbat různé zarížení PC...). Největší problém je, určit kredit za jednotku v okamžiku, kdy nikdo nevý jak dlouho bude trvat. Stačí aby se výpočet nějak větvil a fixní kredit za WU je nepoužitelný (LHC, SETI).
U počítání FLOP vydím 2 nevýhody
a) co je to FLOP a dá se prepočítávat FLOP mezi aplikacemi (a počítači) optimalizovanými pro nonSSE, SSE1,2,3,4(5...) poprípadě PPC, SPARC...
b) Náročnost vs přesnost. buď budeme počítat skutečně každou operaci, ad absurdum hodinu počítám a hodinu počítám kolik sem toho spočítal. nebo tam to počítadlo dám jen jednou zase je to jen hádání a jsou vněm nepřesnosti.
Jen sem chtěl napsat že podstata systému benchark*čas není tak tragická jak vypadá. Problém je v primitivnosti bencmarku v BOINCcore. Je to jako porovnávat všechna auta jen podle maximálního výkonu a neříc co je to za auto, kde bude jezdit...
AFAIK bencmarky které zohledňují i rychlost pamětí (HDD ect) (BTW i v definici Coblestonu je rychlost paměti) přece jsou. BOINC by ale musel vracet více čísel než jen DRY-WET, a výpočet by musel být složitější než násobení (ideálně různý pro různé projekty).
Ale asi to bude vždy méně přesné než FLOPcount.

Vzdy jsem byl odpurce primitniho konceptu: pocitani = ziskavani kreditu a neni divu, ze se mi nezamlouva, pokud mi to nekdo byt naznakem nebo ve vtipu podsouva - napriklad v souvislosti se SZTAKI.

JJ za kredity si stejně nic nekoupíme, tak nemá cenu se kůli nim do krve hádat. nNa druhou stranu by bylo fajn kdyby se podle kreditů dal měřit výkon počítače. a ne furt jen hádat jestli je výhodné počítat s HT nebo ne s Intel-AMD...

Ted pocitam hlavne malarii a ta mi dava priblizne 200 kreditu / den na jednom PC.

Zatim jedu už hodně dlouho v Rosettu. Na A64 2,64GHz to dává kolem 30 kreditů za odpracovanou hodinu. U A64 X2 4600 zhruba 28 kreditů na hodinu na každý jádro, čili kolem 56 kreditů za hodinu pokud na ní jedou obě jádra. Prozatím jsem nikde za hodinu práce nedostal víc kreditů.

Zrovna rosetta neni nejspravedlivejsi v pridelovani kreditu. Ty co maj "nacheatovany" benchmarky tem to dava hodne. Me treba na P4 HT 2,6GHz (2 WU najednou) to dava zhruba kolem 26 kreditu za tri hodiny, na A64 3000+ (na 2200MHz) mi to dava asi neco kolem 30 kreditu za tri hodiny. Takze snad rosetta taky prejde co nejdrive na nejaky spravedlivejsi pridelovani.

Zadny projekt z quorem 1 neni spravedlivy v pridelovani kreditu; "spravedlive" jsou projekty, ktere prideluji kredit fixne za odvezdanou praci, stejdne spravedlive jsou projekty s quorem >2, kde se zase nekdy pocita zbytecne x-krat to same.
Na Rosette se uvazovalo drive o FLOPsech, pote o nejakem systemu a-la Einstein. Az skocni CAPS7 - snad jiz pristi tyden - tak bude prostor to znovu diskutovat a realizovat.

Uz jsem si rikal, kam se podel tento thread - a on byl blbe pojmenovan...proste preklep; napraveno.

Zda se, ze to Rosetta/Ralph mysli opravdu vazne s napravenim sve reputace kolem kreditu.
Na Ralphu se bude testovat kazdy protein/model na narocnost (krome jineho) a podle toho se mu pak urci kreditove ohodnoceni pred tim, ze pujde na ostrou Rosettu.
Sounds like a good plan, I would say...

Vzhledem ke kratkemu vypadku Seti se mi podarilo porovnat vykon na stejnem stroji. Vypadek sice netrval dlouho, ale i tak by to mohlo byt zajimave.
Urcite muze mit nejaky vliv zatizeni pocitacu. Jinak si nedokazu vysvetlit rozdil v Einsteinovi mezi 8 a 9.
Zajimavy je rozdil zapomenute optimalizace LIN Crunch3r SSE na 8 a novejsi LIN KWSN SSE na 9.
Teda formatovani mi tady fakt moc nejde.
Libor

2 vejpuste: Libore, rozumím tomu dobře, že u HT ti kwsn optim počítá déle než ta stará optim?

2 Pepino65: Nevim na co narazis, ale pokud na "Zajimavy je rozdil zapomenute optimalizace LIN Crunch3r SSE na 8 a novejsi LIN KWSN SSE na 9." tak se jedna o pocitace v radku 8 a 9, kde zadny HT nemaji. Pokud upozornujes na nejaky konkretni pocitace, tak napis jejich cisla.
Jinak hlavni porovnavani je Seti optimalizovana oproti Einsteinu - posledni 3 sloupecky.
Libor

Na řádku 3 u P4 3 GHz je uvedena záporná hodnota, tak jsem chtěl vědět, jestli ta stará optimalizace není pro tento typ PC lepší. Viz jak chodíval Einstein bez HT a s HT, kde HT einsteina zpomalovalo..

2 Pepino65 : Zaporna hodnota znamena, ze na P4 3GHz HT mi vychazi SETI WIN KWSN SSE3 o malicko vynosnejsi nez Einstein.
Mozna je to optimalizaci SSE3, kterou Einstein nema a kterou nemam ani na linuxech, protoze pro Linuxy SSE3 optimalizace KWSN neni.
Libor