Ostatní diskuse o projektu

[nenym]

Asi ano

Kód: Vybrat vše

SunflowerBlender
Linux running on an AMD x86_64 or Intel EM64T CPU 	4.79 	23 Jan 2011 | 12:51:03 UTC
Linux running on an AMD x86_64 or Intel EM64T CPU 	4.79 (mt) 	23 Jan 2011 | 13:43:05 UTC

Přitom na linuxu jede mt aplikace mnohem efektivněji. Na 4CPU Winech je CPU time 2x run time, an 4CPU linuxu je CPU time 3,5 x RUN time.

[gigadisk]

App_info.xml

Kód: Vybrat vše

<app_info>
<app>
    <name>blender</name>
    <user_friendly_name>Blender</user_friendly_name>
</app>
<app>
    <name>sunflowerblender</name>
    <user_friendly_name>SunflowerBlender</user_friendly_name>
</app>
 <file_info>
    <name>blender_4.74_windows_intelx86.exe</name>
    <status>1</status>
  <executable/>
 </file_info>

<file_info>
    <name>windows_unzip.exe</name>
    <status>1</status>
    <executable/>
</file_info>

<file_info>
    <name>windows_zip.exe</name>
    <status>1</status>
    <executable/>
</file_info>

<file_info>
    <name>blender_4.74_windows_intelx86.exe.zip</name>
    <status>1</status>
    <executable/>
</file_info>

<file_info>
    <name>infozip_license</name>
    <status>1</status>
</file_info>

 <file_info>
    <name>sunflowerblender_4.79_windows_x86_64__mt</name>
    <status>1</status>
  <executable/>
 </file_info>

 <file_info>
    <name>sunflowerblender_4.79_windows_x86_64__mt.zip</name>
    <status>1</status>
 </file_info>




 <app_version>
    <app_name>blender</app_name>
    <version_num>474</version_num>
    <platform>windows_intelx86</platform>
    <avg_ncpus>1.000000</avg_ncpus>
    <max_ncpus>1.000000</max_ncpus>
    <flops>3102094680.073825</flops>
    <api_version>6.3.10</api_version>
    <file_ref>
        <file_name>blender_4.74_windows_intelx86.exe</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>windows_unzip.exe</file_name>
        <open_name>windows_unzip.exe</open_name>
    </file_ref>
    <file_ref>
        <file_name>windows_zip.exe</file_name>
        <open_name>windows_zip.exe</open_name>
    </file_ref>
    <file_ref>
        <file_name>blender_4.74_windows_intelx86.exe.zip</file_name>
        <open_name>blender_4.74_windows_intelx86.exe.zip</open_name>
    </file_ref>
    <file_ref>
        <file_name>infozip_license</file_name>
        <open_name>infozip_license</open_name>
    </file_ref>
</app_version>

<app_version>
    <app_name>sunflowerblender</app_name>
    <version_num>479</version_num>
    <platform>windows_x86_64</platform>
    <avg_ncpus>5.000000</avg_ncpus>
    <max_ncpus>5.000000</max_ncpus>
    <flops>27518938349.714260</flops>
    <plan_class>mt</plan_class>
    <cmdline>--nthreads 5</cmdline>
    <file_ref>
        <file_name>sunflowerblender_4.79_windows_x86_64__mt</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>windows_zip.exe</file_name>
        <open_name>windows_zip.exe</open_name>
    </file_ref>
    <file_ref>
        <file_name>windows_unzip.exe</file_name>
        <open_name>windows_unzip.exe</open_name>
    </file_ref>
    <file_ref>
        <file_name>sunflowerblender_4.79_windows_x86_64__mt.zip</file_name>
        <open_name>sunflowerblender_4.79_windows_x86_64__mt.zip</open_name>
    </file_ref>
    <file_ref>
        <file_name>infozip_license</file_name>
        <open_name>infozip_license</open_name>
    </file_ref>
</app_version>

</app_info>

MT Task sunflowerblender bude počítán od teď na určitých jádrech. Stačí upravit hodnotu max_cpus a avg_cpus a <cmdline>--nthreads 5</cmdline> na počet jader. Důrazně doporučuju počítat vzorcem (CPU_Jáder/2)+1 = 8/2 = 4 + 1 = 5 aby se nespustily dva tasky současně. Dále jsem si všimnul chyb, pokud mi BOINC přepne z BURPu na jiný projekt, task okamžitě spadne, asi budu muset prodloužit přepínání, mezi projekty, ale už teď se mi zdá, že je to nastaveno na 4 hodiny.(Neměl, bylo to na 60 minut, proto to padalo). Jinak tato úprava funguje a poslal jsem i validní výsledek.

PS: App_info.xml může vypadat určitě i jednodušeji, bohužel však nevím co by se ještě dalo ubrat. Možná platform a flops by tam být ještě nemuselo.

[Don_Carlos]

21.3.2011 20:28:58 BURP Message from server: SunflowerBlender needs 8678.00 MB RAM but only 8172.14 MB is available for use.

Jako co je moc to je moc
Chtěl jsem zkusit něco napočítat s tím, že zároveň testnu optimalizovanou app pro Sandy Bridge (s AVX instrukcemi). Tak nic...

[nenym]

Renderfarm.fi a T4Theory je totéž přes kopírák.

[gigadisk]

Na serveru je zase hodně práce, teď mě týden omezovala hláška, že potřebuju 8GB RAM a že mám jen 6GB, tak mi to nechtělo nic poslat, přemýšlím, že si pořídím ke stávajícím dalších 3x2GB. Ale už by to byl docela extrém jet na 12GB RAM, o tomhle se mi dřív ani nesnilo, když jsem si sestavu pořizoval. Jinak moje úprava APP funguje skvěle a mám další dva thready volné na počítání Primegridu(gpu), Einstein(2 thready volné) a je škoda, že tohle nikomu nepomohlo zvednout volný výkon CPU, který pak zahálí.

[nenym]

Mně na BURPu vadí, že při ukončení úlohy restartuje BOINC, takže tasky bez checkpointu začínají od nuly. Nebo se už umravnil? Tvoji úpravu jsem vyzkoušel a sama o sobě funguje sqěle.

[nenym]

Linux aplikace se chova podstatne kulturneji, pri skonceni ulohy se restart Boincu nekona a navic je asi lepe napsana, pomer mezi CPU time a run time je vyrazne lepsi. Dovoluji si predhodit app_info (je to prima inspirace gigadiskem, prepsana do linux aplikace a upravena pro sestijadro)

Kód: Vybrat vše

<app_info>
<app>
    <name>sunflowerblenderlin</name>
    <user_friendly_name>SunflowerBlender (Linux)</user_friendly_name>
</app>

<file_info>
    <name>sunflowerblenderlin_4.81_x86_64-pc-linux-gnu__mt</name>
    <executable/>
</file_info>

<file_info>
    <name>infozip_license</name>
    <executable/>
</file_info>

<file_info>
    <name>linux_zip_x64_r600</name>
    <executable/>
</file_info>

<file_info>
    <name>linux_unzip_x64_r600</name>
    <executable/>
</file_info>

<file_info>
    <name>sunflowerblenderlin_4.81_x86_64-pc-linux-gnu__mt.zip</name>
</file_info>

<app_version>
    <app_name>sunflowerblenderlin</app_name>
    <version_num>481</version_num>
    <platform>x86_64-pc-linux-gnu</platform>
    <avg_ncpus>4.000000</avg_ncpus>
    <max_ncpus>4.000000</max_ncpus>
    <plan_class>mt</plan_class>
    <api_version>6.13.0</api_version>
    <cmdline>--nthreads 4</cmdline>
    <file_ref>
        <file_name>sunflowerblenderlin_4.81_x86_64-pc-linux-gnu__mt</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>infozip_license</file_name>
        <open_name>infozip_license</open_name>
    </file_ref>
    <file_ref>
        <file_name>linux_zip_x64_r600</file_name>
        <open_name>linux_zip_x64_r600</open_name>
    </file_ref>
    <file_ref>
        <file_name>linux_unzip_x64_r600</file_name>
        <open_name>linux_unzip_x64_r600</open_name>
    </file_ref>
    <file_ref>
        <file_name>sunflowerblenderlin_4.81_x86_64-pc-linux-gnu__mt.zip</file_name>
        <open_name>sunflowerblenderlin_4.81_x86_64-pc-linux-gnu__mt.zip</open_name>
    </file_ref>
</app_version>
</app_info>

Plneho vyuziti vsech sesti jader jsem dosahl featurou <ncpus>7</ncpus> v cc_config, u procesoru s HT je to zcela zbyecne, u procesoru bez HT se mi to jeví býti účelným. Preji mnoho uspechu v dalsim laborovani.
EDIT: pro úplnost - vzhledem k nebývalému záboru RAM aplikací BURPu k ní provozuji na X6 1090T na CPU low-RAM projekt mersenne a na GPU (GTX260) DistrRTgen, funguje bez problémů i s PG PPS Sieving, ale pak je optimální nastavení cc_config <ncpus>8</ncpus>. Jiný GPU projekt jsem nezkoušel, předpokládám, že kromě GPUGRIDu by neměly být žádné potíže.

[nenym]

Provedl jsem nějaké pokusy s mt aplikacemi na 64bit Widlích (Xeon) a 64bit Linuxu (X6 1090T). Zde jsou výsledky
- vzhledem k benchmarku je Windows aplikace asi 2x výkonnější, než na Linuxu, může to ovšem být vlastnostmi AMD, časem otestuji i na Widelním AMD
- Linux aplikace se chová zcela kulturně
- Windows aplikace při startu udělí systému takový kopanec, že se úlohy v Boincu restartují (počítají od předchozího checkpointu)
- lze provozovat s app_info s definovaným počtem threadů, jednodušší cesta je však featurou <ncpus> v cc_config sdělit Boincu, že má o 50% více jader, než ve skutečnosti, pak je CPU dokonale vytíženo (v určitých úsecích mt aplikace BURPu využívá pouze jedno či dvě jádra)
Doporučení
- na Widlích k BURPu provozovat pouze projekty s dostatečně častými checkpointy, ideálně po 1 minutě, maximálně po 4
- BURP by měl mít 3-4x vyší RS, než součet ostatních aktivních projektů s nataženými úlohami, jinak core přepne občas na ostatní projekty bez zařazení tasku BURPu, což je vzhledem k featuře <ncpus> poněkud nesmyslné a nevhodné, protože DCF nabývá nereálně velkých hodnot
- nedávat zbytečně velký buffer, BURPu se natáhnou pouze 4 úlohy a pak by core mohlo vzhledem k poměru RS poslat souběžné projekty do panic mode; mně se osvědčil buffer velikosti 6-10x možná zásoba BURPu (tj. při hodinových úlohách BURPu buffer 0,25 až 0,4)
BURP je neuvěřitelný žrout RAM i disku, takže není pro každý počítač. Na Widlích je nutné počítat s tím, že při startu tasku bude celý stroj 1 až 1,5 minuty dokonale tuhý.

[nenym]

....vzhledem k benchmarku je Windows aplikace asi 2x výkonnější, než na Linuxu, může to ovšem být vlastnostmi AMD, časem otestuji i na Widelním AMD

Po dalších pokusech je jasno. Na AMD X6 1090T je Windows aplikace stejně málo výkonná, jako Linux aplikace. Bohužel nemohu porovnat výkonnost aplikací na 4CPU Xeonu, anžto Linux na něm nemám.
Poznatky k optimalizaci výkonu celého PC, platí pro CPU bez HT (tam může být lepší strategie app_info).
- app_info s omezeným počtem threadů funguje, ale jako celek je výhodnější nepoužít app_info
- featurou <ncpus> zadat počet jader na 2n-1 (4CPU na 7; 6 CPU na 11), blender si kupodivu vezme olik skutečných jader, kolik právě potřebuje
- jako ideální souběžný projekt na Linuxu je Primaboinca/Mersenne/Simap, na Widlích Primaboinca (další dva lze též provozovat, ale na Linuxu mají větší výkon)
- počet souběžně počítaných úloh průběžně pendluje od n-1 do 0 podle toho, kolik si právě bere blender
- systém někdy rozdělí výkon mezi více souběžných tasků (maximálně o 1, než by bylo potřeba), pak stoupá DCF a poměr run time/CPU time, výkonnosti blenderu se to však nedotkne a stroj je dokonale vytížený i v momentech kdy blender neví co chce a jeho zábor CPU plandá mezi 25 % až 70 % v sekundových intervalech, toto se projevuje zejména u kratších úloh pod 1hodinu CPU time

EDIT 11.4.2012: Barevně odlišené části NEplatí pro core verze 6.12.xx+, pro zamýšlený účel je nutné použít app_info. Toto však již není nezbytností, protože projekt vylepšil WUgenerator a poměr CPU time/Run time je přijatelný. Kopanec po stratu tasku na widlích zůstává, tasky jiných úloh začínají výpočet od předchozího checkpointu. Je zcela nevhodné přepínat task za běhu (přepínat výpočet jinam), většinou končí havárií BURP tasku => v BM nastavit přepínací dobu delší, než výpočet BURP tasku a mít velmi malou zásobu aktivních tasků ostatních projektů, aby core nepropadlo panice.

[Pallando]

Máte taky problém s jednotkami? Několik se mi jich spočítalo, ale čtyři poslední skončily z mně neznámého důvodu chybou.

[nenym]

Blender 4.81 mt je celkem stabilní, ale velmi agresivní aplikace. Při startu tasku a vždy při přechodu na další hladinu Boinc vypadá, jako kdyby restartoval. Protože ostatní tvoje zhavarované tasky spočítali, hledej problém někde u sebe. Ne však v BURPu, ale co jsi změnila od doby, kdy ti počítal bez chyb (GPU projekt, film na počítači, spuštěný antivir nebo defrag, upgrade Wirouz bez restartu....může to být cokoli).

[Pallando]

Tak na BURP kašlu, další jednotka s chybou, tak nebudu plýtvat výkonem (nevidím žádný rozdíl oproti tomu, co jsem dělala nebo co jelo v době, kdy se jednotky počítaly správně).

[nenym]

Projekt se rozhodl následovat Renderfarm.fi ve vylepšeném přídělu. Přidaná hodnota proti konkurenci je v rozhoupání granted credit až do stavu mořské nemoci. Tři extrémy z posledních 24 hodin (4CPU Xeon 2,83 GHz Win XP 64bit 8 GB RAM), jde o různé série, každá má trochu jinou nesymetrii jednotlivých threadů a tedy poměr Run time/CPU time:
- run time 1,277.50/ CPU time 4,162.56/ kredit 154.57,
- run time 1,298.13/ CPU time 4,210.09/ kredit 38.24,
- run time 1,086.66/ CPU time 3,164.92/ kredit 122.54
nicméně v průměru je výnos okolo 40s CPU time/kredit.
Upravil jsem návod k použití.

[hanbanaroda]

To jako fakt? Dva dny práce na čtyřech jádrech za 203 kreditu?

http://burp.renderfarming.net/result.ph ... id=7258532

[nenym]

Kolik od té doby uplynulo vody ...... příděl několikrát změnili. Co jsi vyfasoval ty je však nějak extrémně málo, já naposled (26.10.) dostal na X6 1090T kredit za 155s CPU time, což je sice dost pod benchmarkem, ale ještě to ujde. Na Intelu jsem hodně dlouho nezkoušel, ten však vychází o dost lépe.
Renderfarm.fi je s kreditem také v původních kolejích - maximálně benchmark, spíše však méně.

[vkliber]

hanbanaroda : vítej ve světě náhodného kreditu.


Přiznám se, že tento projekt mi zcela vypadl z hlavy, úplně se míjel mé pozornosti, tak jsem to chtěl hned napravit. Naštěstí jsem si ještě nedokoupil paměť :

Zpráva ze serveru: SunflowerBlender needs 5564.00 MB RAM but only 4013.40 MB is available for use.

[hanbanaroda]

26.10.2012 0:11:38 | BURP | Zpráva ze serveru: SunflowerBlender needs 12957.37MB more disk space. You currently have 9698.63 MB available and it needs 22656.00 MB.

Tak za toto mně dali těch 203... Ještě to s nima zkusím, ale jak mně doslova potrestají podobným kreditem, tak na nich nakašlu.

EDIT: 145 000s na čtyřech jádrech - chyba výpočtu - 0 kreditů. Au, to bolí.

[vkliber]

BURP je fakt síla .

Úkol 7711060 na i7-3770 (s vypnutým HT ), na Win7 64-bit, doba výpočtu 1 den, 9 hodin, 36 minut ... obdrženo 17.83 kreditů.
To je potencionální RAC 12.73 na jedno jádro ... to jsem snad míval více, když jsem před 8 lety začínal na starém Intel Pentium4 1.8GHz (ten ale určitě neměl potřebných 0,5G RAM ).

[nenym]

Payday:

"Payday" is a development subproject of BURP. The main objective is to retroactively perform a correction on all granted credit since the introduction of CreditNew and subsequently replace or accompany CreditNew as the main credit granting algorithm for BURP. Secondary objectives are to make it way simpler to understand than CreditNew, make it credit-stable both in short-term and long-term measurements and at the same time make it fairly transparent to the community what is going on.

It will never be perfect, but it will very likely become a bit better than CreditNew.

The basic way that credit will be calculated with Payday is this:
Amount of work done per hour * hours it took * cobblestone factor = your credit
Oldschool BOINCers will find this very similar to the original credit system - and this is no coincidence since that system served as inspiration for Payday.

Sessions 1114 through 1144 have been credited. Around 0.3M more credit.

Dohledal jsem, že tyto sessions jsem chroustal na začátku dubna 2011, dnes mi přistál extra kredit na BURPu ve výši 1403.
Lépe pozdě, než-li ještě později. RAC a granted credit jednotlivým taskům projekt neupravuje, pouze připisuje extra kredit.

[vkliber]

Přiznám se, že tento projekt mi zcela vypadl z hlavy, úplně se míjel mé pozornosti, tak jsem to chtěl hned napravit. Naštěstí jsem si ještě nedokoupil paměť :

Zpráva ze serveru: SunflowerBlender needs 5564.00 MB RAM but only 4013.40 MB is available for use.

Paměť jsem si již dávno dokoupil, myslel jsem že 12GB bude dostatečných ... není

Message from server: Blender needs 11899.00 MB RAM but only 10941.34 MB is available for use.

Musel jsem jít až na 98% RAM pro BOINC.