benchmarks

[vejpuste]

Koukam na tohoto clovickajakej ma vysokej benchmark 9999/9996 ty cisla vypadaji nejak podezrele

Vzhledem k casum je to jasne. Podvod. Bohuzel se takovym asi nevyhneme a melo by se to resit nejak systemove.
Nejhorsim prikladem je v tomto Rosetta, kde nekteri z niceho nic zacnou delat desitky tisic kreditu denne.
Snad se to casem nejak vyresi a kredit bude srovnatelny.
Libor

[trux]

Podvod bych to nenazyval. Ten system benchmarku je spatny a nesmyslny a proto se tolik machinuje s optimalizovanymi klienty a benchmarky, ktere se to snazi napravit optimalizovanym behem benchmarku. Bohuzel ale ta optimalizace benchmarku nikdy nebude respektovat optimalizaci S@H aplikace.

Hodnota kreditu referencni jednotky (o delce 27924.8 Gflop) spocitana referencni masinou (= 1Gfpops/1Giops) je 32,32 cobblestonu - spocitano podle vzorecku ([whetstone]+[dhrystone]) * wu_cpu_time_in_sec / 1728000. To znamena, ze manipulace benchmarku tak, aby vysledky za plnohodnotne jednotky byly kolem 30 - 35 cobblestonu jsou naprosto v mezich legitimity, i kdyz samozrejme je to bastl, a melo by to byt vyreseno systemove - jak uz jsem davno rikal, pomoci kalibracnich jednotek.

Ono by to provizorne slo i jednoduseji (i kdyz mene presneji), pomoci vyuziti korekcniho faktoru pro vypocet odhadu casu, ktery uz tam mame - ten koeficient zhruba odpovida stupni optimalizace. Kdyby se jim tedy Claimed Credit podelil, tak by se ziskal mnohem presnejsi kredit nez pomoci samotneho benchmarku.

Popravde receno, dlouhodobe ignorovani techto problemu ze strany oficialniho tymu mi dost leze na nervy, a uz jsem si zacal hrat s upravenou verzi, ktera ty benchmarky bude kalibrovat spravedliveji. Chci vyuzivat nejen toho korekcniho koeficientu, ale i kalibrace pomoci referencni jednotky + verifikace pomoci beznych plnohodtnotnych jednotek, aby se zabranilo manipulaci. To zabezpeceni je trochu slozitejsi - samozrejme rizeni celeho procesu ze strany serveru by bylo mnohem lepsi a spolehlivejsi, ale myslim si, ze i takovato verze by byla mnohem spravedlivejsi nez soucasny hon za benchmarky, ktery navic zpusobuje deformaci kreditu u jinych projektu.

[Honza]

Me se libil ten napad s adaptivni a pouze castecne redundantni jednotkou v ramci kazdeho projektu, podle ktere by se hodnotilo skore masiny co do spolehlivosti (jak vykonu, tak stability).
V pocatcich CPDN se uvazovalo o tom, ze by nova masine (ktere je prideleno nove HostID) dostala kratsi CPDN model - predevsim kvuli testu stability. Samosebou to lze pouzivat i na mereni vykonu.

Taky mi soucasny stav benchmarku (a popravde ani 3-4x nasobneho pocitani) nevyhovuje...a sotva mne utesi, ze tyto problemy CPDN netykaji

[vejpuste]

Konecne jsem dostal ten Opteron 254. 2,8 GHz a 1M L2 cache. V instrukcich ma jenom SSE2. Myslel jsem, ze uz SSE3 bude, ale neni.
Linuxovy bogomips : 5521.40

Naparstuv boinc pro P4 dava :
3636 double precision MIPS (Whetstone) per CPU
7131 integer MIPS (Dhrystone) per CPU

Naparstova seti aplikace pro SSE2 :
Zatim jsou casy velice vyrovnane : 1929-1939 s. Ale bezi zatim jenom chvilku.
Vypada to na RAC 900. Uvidime, jaka bude realita.

Chtel bych na tom nekdy zkusit Wokna s Crunch3r aplikaci, ale to asi az po novem roce.
Libor

Nepovedlo se mi spustit Naparstuv BOINC pro AMD64. Moc jsem to nezkoumal, ale mozna by daval benchmarky lepsi.
RAC jednoho procesoru je zatim 875. setiathome_SSE2-naparst-r3.4 dela jednotku prumerne za 1800 s.

Zkusil jsem na to dat pro porovnani wokna :
Truxuv 5.3.6tx12 dava benchmark 3538/11490.
Crunch3r Athlon64 SSE3 pocita za 2100 s. Vzhledem k tomu, ze je ta wokenni optimalizace novejsi, tak jsem ocekaval lepsi vykon nez na Linuxu. Ale tesi me, ze je Naparstova Linuxova verze lepsi i kdyz je starsi. Stejne na tom pojede Linux.
V CPUZ se ukazala SSE3 i kdyz v cat /proc/cpuinfo se neukazuje. Vyzkousim jeste naparstovu oprimalizaci pro SSE3 a uvidime.

Predbezny vysledek pokusu :
Truxuv BOINC dava lepsi benchmarky ve woknech.
Naparstova seti aplikace je lepsi nez Crunch3r.
Netestoval jsem to na stejnych jednotkach, takze to neni uplne presne, ale vysledek vypada docela zrejme.
Zitra to vratim na Linux a zkusim SSE3 a BOINC core pro AMD64.
Libor

[alwin]

Muze me nekdo vysvetlit co vlastne znamenaji hodnoty Whetstone a Dhrystone. Delam benchmark cca 1x mesicne a pokazde je to o par bodu mensi nez predchozi.

[azor666]

White je výkon ve float (operace s plovoucí čárkou)
Dry je výkon v integer- celých číslech.

Obecně je Benchmark v boinc dost nepřesný a hodnoty bych bral jen orientačně. Navíc projekty postupně přechází na bodování, které není založené na benchmarku,

[sj-shark]

need help

Linux. P4 na 3.4GHz, 1MB cash, pocita kolem 100 den

2007-03-04 02:52:49 [---] Number of CPUs: 2
2007-03-04 02:52:49 [---] 1052 floating point MIPS (Whetstone) per CPU
2007-03-04 02:52:49 [---] 852 integer MIPS (Dhrystone) per CPU

co s tim? to je horsi nez duron

tohle je celkem, ok pocita kolem 600 za den
Intel(R) Xeon(R) CPU 5130 @ 2.00GHz, taky linux

2007-03-04 09:36:11 [---] Number of CPUs: 2
2007-03-04 09:36:11 [---] 1736 floating point MIPS (Whetstone) per CPU
2007-03-04 09:36:11 [---] 4160 integer MIPS (Dhrystone) per CPU

[Honza]

Posledni verze BOINC?

Pristi verze by mely byt kompilovany novejsim kompilatorem (+ knihovny), takze je sance na dorovnani benchmarku s Win.

Nebo ze by proste P4 stala za prd a bylo horsi nez duron?

Jestli te trapi kredit, tak pocitej neco, kde se ten blbej benchmark nepouziva...