Forum boinc.cz

Kdyz bych ho nebrzdil stale vypocty jinych projektu, tak uz byl - zustava mi jeste 19 hodin; celkem to bude 1462.
Druhy na dalsi masine ukazuje jeste 74 hodin, celkem 1420.

Takze tento tyden ocekavam 2.
Ted pocitam CPDN trochu mene nez driv, ale mi dela prakticky polovinu z 2,5 milionu kreditu.

2 Honza: Parada. Podle stats jeste neni spocteny zadny, tak mozna budel prvni!!

Bude to tenhle model, tak snad je to spravny typ a po ranu jsem se neprekoukl.
Ted ma datum 19/11/2078. Jeste 3 trickle a upload a bude.

Nevim, jestli lze te statistice tak uplne verit - par SpinUp modelu jsme udelali a je tam take 0.
No, alespon prozkousim, jestli ta stats chodi...

Carl se na ty statistiky jeste podiva...

2 Honza: Muzu jen tise zavidet hodnotu 1,27 s/TS. No holt musim kvalitu nahrazovat kvantitou.

Bubak píše:2 Honza: Parada. Podle stats jeste neni spocteny zadny, tak mozna budel prvni!!

Carl uz tu statistiku opravil a pry by to melo sedet (mym odhadem je 61 SpinUp modelu spravne...kolega delal presny seznam kdo ktery spocital a bylo to podbne cislo).
Akorat kliknuti na SpinUp nebo Transient nedava vypis posledniho modelu

Pocet kompletnich modelu ve skutecnosti znamena tech, ktere dojeli alespon do roku 2050

EDIT: Jo, 1.27 je dobrych, druhy ma asi 1.23 nebo podobne. Ale novy Intel Mac dela s patricnym kompilatorem pod 1 sec/TS...kdyby se trochu posteloval OC a pripadne kompiloval 64-bitove, tak by to slo jeste lepe. Holt novy Mac ma tu vyhodu, ze vsechny jeho procaky jsou standardne alespon SSE2, takze se s tim v systemu a kompilatorech muze pocitat...a to se vyplati.

2 Honza: Parada. Tesi me, ze my nesmysly placany na foru prispeli k zlepseni statistik. Diky ti a hlavne Carlovi za to. Mimochodem, rad se dovidam, ze na konci roku neodesel.

Ad Mac: Uz jsme o tom nekde kecali a tys psal ze Intel Mac je Conroe. Pokud teda je app. pro Mac (Tedy BSD bezici na Conroe) tak by asi nebyl takovy problem zkompilovat i dalsi klony. Treba Linux + AMD64, Linux + Xoen atd. Neuvazuji o necem takovym a vytvoreni stranky pro power usery ala Einstein?

Carl ma tusim termin na zacatku unora (letni semestr)...bude se venovat oblasti digital art na nejake univerzite ve Skotsku nebo kde (ach ta moje nonECC memory).

Ted si nejsem uplne jist, jestli novy Mac neni spise zalozen na Core 2 Duo Xeon rady nez desktopovy Conroe. Kazdpoadne ten udaj k performance byl...zase jestli si dobre pamatuji...pro notebook (Merom)

Ze je nejaky kompilator pod novy Mac OS a kremik automaticky neznamena, ze na CPDN maji kompilator s identickymi schopnostmi pro jinou architekturu (nebo ze takovy vubec existuje), vcetne vsech knihoven atp.
Tak trochu se znovu uvazuje o moznosti zkompilovat multithreaded aplikaci...precijen z roustoucim poctem jader bude efektivnejsi jet rychle jeden model nez n modelu vedle sebe, s nizsimi naroky na pamet, disk space etc. (to asi plati obecne)
Navic...kdyz padne jeden model z treba 8, bud proste padne a jede se dal nebo se musi najet zaloha vsech 8 modelu. Uz drive jsem se klonil k variante multithreaded verze (i za cenu rucniho snizeni poctu CPU na danou masinu v BOINC)...s rostoucim poctem jader to zacina byt aktualnejsi (btw, uz je oficialne venku 4-core pro desktop, takze nejen extreme a xeon). Toz huvidime...

Honza píše:Ze je nejaky kompilator pod novy Mac OS a kremik automaticky neznamena, ze na CPDN maji kompilator s identickymi schopnostmi pro jinou architekturu (nebo ze takovy vubec existuje), vcetne vsech knihoven atp.

Co je to za kompilator? Maca skoro vubec nesleduju, ale jelikoz je to (jak tu furt dokola opakuju) BSD, tak bych si tipnul, ze i CPDN kompiluji GCCckem a linkuji to se standartnimi GNU knihovnami. A zrychleni je jen v parametrech ktere zadaji pri kompilaci. Na tom jsem stavel i muj predchozi prispevek. Muzes mi to vyvratit?

P.S.: Muj vyrok z jineho fora se hezky ujal.

Edit: No tak si to vyvratim rovnou sam. Asi pujde o tohle: http://www.intel.com/cd/software/produc ... 267426.htm. Tak to potom jo.

Edit2. Tak to teda ne. ten samy kompiler je i pro ostatni platformy http://www.intel.com/cd/software/produc ... 284132.htm takze by mohli udelat optimalizovany power app pro Win i Lin.

Edit3: jeste doplnim. Pokud ma E@H detekci instrukcni sady procesoru, mozna by to byla cesta i pro CPDN. Vlastne je to v DC stara vec. Stara tak jako distributed.net, ktery je jeste dal a pred spustenim vypoctu spusti v defaulf nastaveni microbenchmark a vybere optimalni core (core tam znamena neco jineho, nezamenujte ho za BOINC core). Neslo by to tak udelat? Treba i za cenu dalsiho wraperu nad (vlastne pod) CPDN app, ktery by jen otestoval moznosti CPU, pripadne dostupnost knihoven a pak spustil prislusnou aplikaci. I v pripade, ze by diky male podpore BOINC core bylo nutno stajnout veskere pripadne optimalizovane app pred spustenim toho wraperu by zrychleni vypoctu melo vetsi vahu nez par mega downloadu navic.

OK, kompilatory zkusim zjistit.

Distributed.net znam, je to preci klasika, nad kterou neni. Vim jak funguje a pro BOINC to nedoporucuji.

Novy BOINC ma detekci schopnosti CPU (a pripadne pristomnosti GPU akceleratoru, ale to zatim spolehlive nefunguje).
Tedy spise nez ze by si aplikace sama osahavala, mel by se o to postarat BOINC core, rici o sobe neco scheduleru a ten by mu mel dat spravnou aplikaci.
Zda se mi to korektnejsi, i kdyz to vyzaduje mit na serveru o poznani vice aplikaci (plati i pro 64-bit).
A take je asi jednodussi zkompilovat stejnou app s ruznymi parametry nez delat zasahy to aplikace, vetvit ji podle instrukci atp. (nejsem programator, tak jestli placam, oprav me).

ad distributed.net: Nerikam ze vsechno je lepsi nez v BOINCu, ale konkretne microbenchmark a vyber spravneho core je dobra vec. A to nejde o app s ruznymi inst. sadami atd. de facto je to stejny kod kompilovany s ruznymi parametry compileru. Lisi se napr pouzitim --O2 parametru (Gentoo pozitivni silenci vi o cem pisu ). Pro novejsi CPU je tech parametru ktere muzou zrychlit vysledny kod spousta.

ad zbytek: Pokud je k tomu podpora BOINC core, tak nechapu kde to jeste vazne. Tak at Carl zkompiluje app pro Conroe pod Win i Lin, v prvni fazi to hodi na web k sirsimu otestovani s vyuzitim anonymous platform a pak uz nic nebrani tomu, aby se CPDN podstatne zrychlila.

Taky nejsem programator. Kdyz si napisu parradkovej scriptik v perlu, kterej mi napr. taha z logu to co mi zajima, tak se nepovazuju za programatora. Nase diskuze ale neni o vetveni a prepisovani zdrojaku. Ja se zatim omezoval jen na moznost lepsi kompilace pro specifickou platformu. Ten muj text byl jen pro pripad, ze by si BOINC neumel rict o napr. LIN glibc_2.3 Conroe app.

OK, tedy takovato zkusenosti s kompilatory:

Jakykoli z Qax switches znici model, vyssi optimalize poslou do kytek ocean (coupled model)
Mac by kompilovan jsem stejne jako Linux a Win s -O3 (optimalizace bez speficikaci na urovni CPU jako Qax apod.).
Tolu pry tam pridal nejaky flag abych zvysil konzistency floating point, jelikoz Mac aplikace po chvily padala (coz asi trosku zpomalilo).

Tudiz je z toho patrne, ze si s tim hrali a proste identifikovali, co nedela dobre.
Vypada to, ze aktualni zkusenosti odpovidaji tomu pres 2-3 lety.

Zustava mi stale nezodpovezena otazka: jak to, ze Mac verze je o tolik rychlejsi?

Musel jsem si precist tohle a uz trochu vim o cem pises.
Stejne je dobre vedet, ze na to v Oxfordu nekaslou a zkousej vymacknout z desitky let stareho zdrojaku co se da.

A treba casem nekdo z nich zodpovi i tu nezodpovezenou otazku cos psal.