Aký je váš vzťah k optimalizovaným klientom?

[Palo M.]

Niekto o nich ešte nevie.
Niekto by ich chcel mať.
Niekto ich má.
Niekto nimi žije.
Niekomu je to jedno.
...

Na stretnutie nemôžem prísť, tak budem otravovať anketami na fóre. Škoda, pri pivku by sa o tom debatilo príjemnejšie... Ale fakt mi to nevyjde.

[Honza]

Ta posledni moznost si zaslouzi rozvedeni.

Prvni tema je, jak zjistit, kterou verzi aplikace danemu stroji priradit. To neni tak samozrejmne. BOINC zvolil cestu, kdy schopnosti CPU (a pocitace) ziskava od OS (a ne specializovanym programem). To ma vyhodu, ze je zaruceno, ze aplikace bude s OS kompatabilni. Na druhou stranu to znamena, ze na stejnem HW ruzne OS davaji odslisne vysledky.
Druhy zpusob je uzivat specializovany kod a-la CPU-Z. Nevyhodou je moznost narazit na to, ze bude trouble se systemem (stare Win a SSE3 atp.).
Treti zpusob je, ze si bude aplikace sama osahavat, co ma za CPU a podle toho vetvit kod aplikace. Nebo se to resi pres wrapper. Timto zpusobem jsme testovali verzi CPDN s podporou SSE3.

Tedy varianta "at si BOINC poradi sam" je jiste lakava, ale reseni samozrejme neni. Navic takove reseni neumoznuje 3rd pary optimalizace, ale pouze oficialni kompilace...coz je zase z urciteho hlediska vyhodou...

[Palo M.]

Ano, je viac ciest ako to vyriesit a je to na dlhu debatu...

Mne sa momentalne zda pomerne rozumna nasledujuca varianta:

• - BOINC-core client zisti schopnosti CPU.
  - Pri requeste o work sa vsetky tieto informacie poslu projektu a projekt posle "najoptimalnejsiu funkcnu" verziu aplikacie ktora je k dispozicii.
  - Moznost manualneho fallbacku (pre pripad necakanych problemov), aby sa dalo poziadat o "neoptimalizovanu" zakladnu verziu.
  - Pripadne aj moznost manualneho override (pytat od projektu konkretnu optimalizaciu) - asi by bolo vhodne urobit to cez konfiguracny subor uplne mimo GUI, aby neznaly uzivatel nenarobil viac skody ako uzitku.
  - Samozrejme ponechat moznost "manualneho" nastavenia aplikacie cez app_info.xml ako je to teraz (pre tych, co vedia co robia; pre vlastne optimalizacie).

Keby totiz BOINC sam podporoval reportovanie schopnosti CPU, dost by to pomohlo projektom, ktore nie su open-source. Len jednoduche prekompilovanie SETI@Home s inymi flagmi, co je pomerne jednoduche, prinasa zlepsenie, takze myslim ze u vacsiny projektov to bude podobne (to by projekty myslim nezatazilo, urobit aspon tolko). Samozrejme, su aj agresivnejsie optimalizacie kde sa modifikuje kod, ale to by mohlo bezat doterajsim stylom - kto chce, manualne si nahodi.

Mna totiz trochu stve, ze by sa mohlo vypocitat omnoho viac vysledkov, keby sa lepsie vyuzil hardware... A vlastne by to malo stvat projekty samotne.

Ale na druhej strane, credit-hunterov musi tesit sucasny stav, lebo ked ma optimalizacie len mala skupina ludi (a credit-hunter je samozrejme medzi nimi) a vacsina pocita neoptimalne, credit-hunter je vyssie v top-liste...

[azor666]

error double post

[azor666]

co to popisuješ v bodech vlastně přesně dělá Einstein home.

-Autodetekce nonSSE/SSE (akos mel fcni detekci SSE3)
-Beta-testování se řeší pres app_info
-manuálně se da prepnout z5 pridanim přadného souboru s názvem
SET_CPU_TYPE0

Problém je ze zjišťovat verzi cpu by mnel dělat BOINC a ne app projektů (je zbytečné programovat 40x totéž)
Podstata je vtom co psal Honza. Má se detekce nechat na OS
+ jednoduché, elegantní
- Widle XP nepoznají SSE3
Nebo mít vlastní kód (za chvíli bude mít boinc i modul pro ovládání kávovaru).

Keby totiz BOINC sam podporoval reportovanie schopnosti CPU
5.8.xx to už dělá
Stou optimalizací je problém jinde. 1+1 spočítaná pomocí SSE nemusí být ta samá 2ka jako při počítání bez SSE. proto třeba na EAH Akosovi "zatrhli" 3rd party optimalizace. Třeba aktuální bug v optimalizaci SAH.

Mna totiž trochu stve, ze by sa mohlo vypocitat omnoho viac vysledkov, keby sa lepsie vyuzil hardware...
Ono největší díry jsou jinde. Samotná optimalizace pro SSE3 nebo pro 64b sice může přinést značný nárůst výkonu (extrémně až 300%-viz ABC) ale v praxi se dostanete tak na 10% procent. Schválně si někdo udělejte na c2d testy optimalizací SAH.

Konkrétně u SETI je díra úplně jinde.
Replication 4, Polovina práce se počítá zbytečně, protože si nedokážou pořídit schopnej server. Nejsou schopní zapojit tvůrce optimalizací do tvorby oficiální app. Jak dlouho se počítalo 3x pomalejší app na klasiku (4.xx)

[Honza]

Konkrétnì u SETI je díra úplnì jinde.
Replication 4, Polovina práce se poèítá zbyteènì, protože si nedokážou poøídit schopnej server. Nejsou schopní zapojit tvùrce optimalizací do tvorby oficiální app. Jak dlouho se poèítalo 3x pomalejší app na klasiku (4.xx)

No, SETI advanced jiz do jiste miry optimalizovany je, v tom bych se SETI zastal.
Ale puvodni aplikace byla take 6x pomalejsi, ne "pouze" 3x

Nejvetsi srajda v tomto je SZTAKI, ktere bylo po optimalizaci 30x rychlejsi (!). Srajda to zustava v tom, ze oficialni klient je nejen velmi pomaly, ale vubec nekvalitni, podpora je velmi miziva, spise nez uprimnosti se clovek docka slibu etc. Ale to uz je skorem of-topic.

Myslim, ze pokud optimalizace, mozna by bylo dobre zacit 32 vs 64-bit verzi. Pokud se nepletu, tak kazdy 64-bit CPU umi zaroven SSE2 a kazdy 64-bit OS zaroven 'umi' SSE2.
Tudiz bych pri detekci 64-bit OS a BOINC core posilal 64-bit verzi (ktera jako pridanou hodnoutu muze mit SSE2 instrukce).

[azor666]

SZTAKI je tragedie. O tomhle projektu se ani nemá cenu bavit. Ale to beru jako alpha. Teoreticky je stable, ale reálně je jen lehce nad úrovní VTU (nebo jak se ten projekt s nejvice kredity jmenoval lol).

Ono je vždycky otázka jestly je levnější HW nebo vývoj SW. Problém je, že BOINC je trochu komunismus. HW je zadarmo a zároveň drahej.

SETI je, že zatím asi největší DC projekt (možná folding....) a to plýtvání je tam naprosto evidentní a navíc dobře vidět. Uznávám, že optimalizace se dá dělat vždy. Třeba někdo za rok příjde se zázračným algoritmem který sníží náročnost o řád. Nebo to přepíšu na gpu a z 8800 bude padat 96 WU za hodinu. Ale posílat jednu WU na 4 počítače je plýtvání nejhoršího kalibru. Co tím získají:
1) Spolehlivost- irelevantní Quorum je 3. V nejlepším případě 25% výkonu SAH čistá tepelná energie. EAH používá Quorum 2 a nároky na přesnost a vědecký backround jsou třídu jinde. (CPDN a rosetta s Quorum 1 neberu ty pracují trochu jinak)
U SAH jsou WU naprosto nezávyslé u EAH ne.
2) Rychlost Signál k nám jde desítky až stovky let. pásky se pak válí pár let ve skříni. A najednou to musí být rychle aby crunchery neměli 100 kreditů pendig.
Dejte mi pokoj stakovýmhle projektem.

Pokud se nepletu, tak kazdy 64-bit CPU umi zaroven SSE2 a kazdy 64-bit OS zaroven 'umi' SSE2.

Mám pocit že IBM 64b powerPC procesory SSE nemají.