Benchmarki na 5.8.11

Zaczęty przez Bober, 14 Luty 2007, 16:16

Bober

Jakie macie wyniki na kliencie 5.8.11?
Bo ja na dwurdzeniowym Pentium D 3Ghz mam:
14.02.2007 16:12:42||   Number of CPUs: 2
14.02.2007 16:12:42||   1495 floating point MIPS (Whetstone) per CPU
14.02.2007 16:12:42||   1572 integer MIPS (Dhrystone) per CPU


Wydaje mi sie to troche malo i przez to malo zada :(

kempler

Ja na Duron 650@770 mam:


2007-02-14 16:39:25||   Number of CPUs: 1
2007-02-14 16:39:25||   680 floating point MIPS (Whetstone) per CPU
2007-02-14 16:39:25||   1158 integer MIPS (Dhrystone) per CPU



Zaraz będe instalował 5.8.11 na drugim kompie to też napisze

EDIT:
Celeron M 1.6 GHz


2007-02-14 18:36:06||   Number of CPUs: 1
2007-02-14 18:36:06||   1384 floating point MIPS (Whetstone) per CPU
2007-02-14 18:36:06||   2860 integer MIPS (Dhrystone) per CPU

Kury Nas pogryzą, Raptory zeżrą....

cezar

U mnie na Pentium4  2.0 daje takie rezultaty:

2007-02-14 20:37:06 [---] Running CPU benchmarks
2007-02-14 20:38:05 [---] Benchmark results:
2007-02-14 20:38:05 [---]    Number of CPUs: 1
2007-02-14 20:38:05 [---]    2718 floating point MIPS (Whetstone) per CPU
2007-02-14 20:38:05 [---]    5096 integer MIPS (Dhrystone) per CPU
2007-02-14 20:38:06 [---] Resuming computation





gaciu

Oto co wyciaga Athlon64 X2 4600+ bez OC:


2/14/2007 11:02:51 PM||Benchmark results:
2/14/2007 11:02:51 PM||   Number of CPUs: 2
2/14/2007 11:02:51 PM||   2273 floating point MIPS (Whetstone) per CPU
2/14/2007 11:02:51 PM||   3212 integer MIPS (Dhrystone) per CPU

Bober

Pentium M 1,5 Ghz:
2007-02-15 04:28:00||   Number of CPUs: 1
2007-02-15 04:28:00||   1323 floating point MIPS (Whetstone) per CPU
2007-02-15 04:28:00||   2750 integer MIPS (Dhrystone) per CPU
2007-02-15 04:28:01||Resuming computation

KrzychuP

Athlon XP 2500+ 1.84GHz 512 MB RAM

2007-02-15 09:36:40||Benchmark results:
2007-02-15 09:36:40||   Number of CPUs: 1
2007-02-15 09:36:40||   1407 floating point MIPS (Whetstone) per CPU
2007-02-15 09:36:40||   2263 integer MIPS (Dhrystone) per CPU

D_T_G

1884 floating point MIPS (Whetstone) per CPU
4539 integer MIPS (Dhrystone) per CPU


emik

Athlon XP 2500+ 1GB RAM - LINUX SuSE 10.2 Linux 2.6.18.2-34-default i686:


czw 15 lut 2007 17:14:57 CET||Benchmark results:
czw 15 lut 2007 17:14:57 CET||   Number of CPUs: 1
czw 15 lut 2007 17:14:57 CET||   1452 floating point MIPS (Whetstone) per CPU
czw 15 lut 2007 17:14:57 CET||   2247 integer MIPS (Dhrystone) per CPU


Thomas

Wszystko ładnie pięknie, ale ten temat powstał chyba po to żeby porównać wyniki y 5.8.11 z wcześniejszymi wersjami :). W każdym razie mam podobny komputer jak emik i KryzchuP (1 GB RAMu, Athlon 2000+@1950 MHz – więc pracuje jak Athlon 2800+ - o ile takie coś istnieje :) ) i pod windowsem XP i 5.4.11 – bez optymalek wychodzi – 1672 floating points i 2848 integer points (sorry że nie w kodzie ale na innym kompie pracuje).

Bober

Nie ten temat powstał, żebym ustalił czy mój Pentium D ma normalne wyniki czy nie :P

Ale nie tylko oczywiście. Widzę już, że jest duży rozrzut w wynikach i niekoniecznie wiem z czego wynikają. Np ciekawi mnie też wynik P4 cezara, który jest lepszy niż C2D D_T_G - stąd prośba do cezara o wyjaśnienie (na pewno to wynik na 5.8.11?).

Tomislaw

---------- 09:05 16.02.2007 ----------

2007-02-16 00:01:05||   Number of CPUs: 2
2007-02-16 00:01:05||   1992 floating point MIPS (Whetstone) per CPU
2007-02-16 00:01:05||   3066 integer MIPS (Dhrystone) per CPU

VISTA BASIC/C2D E6400/GA-965-DS4/1 GB DDRII PC-6400
Boinc 5.8.11
po 13 minutach znów odpaliłem benchmark i było:
2007-02-16 00:14:07||   1999 floating point MIPS (Whetstone) per CPU
2007-02-16 00:14:07||   4140 integer MIPS (Dhrystone) per CPU

chyba trzeba zrobić więcej pomiarów i uśrednić.

---------- 09:57 ----------

i jeszcze jeden benchnark spod XP-ka
E6600/ASUS P5B Deluxe/2GB DDRII RAM PC-6400
2007-02-16 00:55:12||   Number of CPUs: 2
2007-02-16 00:55:12||   2156 floating point MIPS (Whetstone) per CPU
2007-02-16 00:55:12||   4522 integer MIPS (Dhrystone) per CPU



MadMan

Bo benchmark na dwurdzeniowcu trzeba zrobić tak: uruchamiasz BOINC Managera i Task Managera, w Task Managerze klika się prawym na "boinc.exe", po czym "ustaw koligację" i zostawia 1 rdzeń, boincmgr.exe - podobnie, po czym robi się benchmarka. Po zrobionym benchmarku najlepiej wyłączyć BOINC Managera i włączyć na nowo, inaczej może liczyć tylko jednym rdzeniem.
img]http://www.boincstats.com/signature/user_83293_banner.gif[/img]

bartsob5

Cytat: "Bober"Nie ten temat powstał, żebym ustalił czy mój Pentium D ma normalne wyniki czy nie :P

Ale nie tylko oczywiście. Widzę już, że jest duży rozrzut w wynikach i niekoniecznie wiem z czego wynikają. Np ciekawi mnie też wynik P4 cezara, który jest lepszy niż C2D D_T_G - stąd prośba do cezara o wyjaśnienie (na pewno to wynik na 5.8.11?).

to raczej wynika z tego, ze kolega D_T_G uzywa linuksa, a jak wiemy, na linuksie benchmarki sa i zawsze byly slabsze.

Bober

Chciałbym zauważyć, że wynik kompa cezara jest najlepszy z dotychczas zaprezentowanych, więc nie wiązałbym tego z systemem.

D_T_G

:-k
Dla pewności 3krotnie uruchomiłem ./boinc -run_cpu_benchmarks w terminalu, w bashu jako root, przy wyłączonych X'ach i pokillowanych niepotrzebnych procesach:

2007-02-16 11:08:35 [---] Starting BOINC client version 5.8.11 for i686-pc-linux-gnu
2007-02-16 11:08:35 [---] log flags: task, file_xfer, sched_ops
2007-02-16 11:08:35 [---] Libraries: libcurl/7.16.0 OpenSSL/0.9.8d zlib/1.2.3
(...)
2007-02-16 11:08:35 [---] Processor: 2 GenuineIntel Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz [fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm]
2007-02-16 11:08:35 [---] Memory: 1010.96 MB physical, 2.01 GB virtual
[...]
2007-02-16 11:08:35 [---] Running CPU benchmarks
2007-02-16 11:09:37 [---] Benchmark results:
2007-02-16 11:09:37 [---]    Number of CPUs: 2
2007-02-16 11:09:37 [---]    1898 floating point MIPS (Whetstone) per CPU
2007-02-16 11:09:37 [---]    4671 integer MIPS (Dhrystone) per CPU
==================================================   =====
2007-02-16 11:12:18 [---]    1890 floating point MIPS (Whetstone) per CPU
2007-02-16 11:12:18 [---]    4293 integer MIPS (Dhrystone) per CPU
==================================================   =====
2007-02-16 11:13:50 [---]    1892 floating point MIPS (Whetstone) per CPU
2007-02-16 11:13:50 [---]    4682 integer MIPS (Dhrystone) per CPU


Bober

Ok. cezar potwierdził mi swój wynik. Wielkie dzięki. Chyba przetestuję dziś parę P4.

cezar

Choć chyba proporcjonalnie do wyników nie zbieram punktów. No ale ważne że jest ich coraz więcej :)





Bober

Cytat: "MadMan"Bo benchmark na dwurdzeniowcu trzeba zrobić tak: uruchamiasz BOINC Managera i Task Managera, w Task Managerze klika się prawym na "boinc.exe", po czym "ustaw koligację" i zostawia 1 rdzeń, boincmgr.exe - podobnie, po czym robi się benchmarka. Po zrobionym benchmarku najlepiej wyłączyć BOINC Managera i włączyć na nowo, inaczej może liczyć tylko jednym rdzeniem.

Oto efekt:

16.02.2007 12:44:24||Starting BOINC client version 5.8.11 for windows_intelx86
16.02.2007 12:44:24||Processor: 2 GenuineIntel               Intel(R) Pentium(R) D CPU 3.00GHz [x86 Family 15 Model 4 Stepping 7] [fpu tsc pae nx sse sse2 mmx]
16.02.2007 16:04:41||Running CPU benchmarks
16.02.2007 16:04:42||Suspending computation - running CPU benchmarks
16.02.2007 16:05:42||Benchmark results:
16.02.2007 16:05:42||   Number of CPUs: 2
16.02.2007 16:05:42||   1493 floating point MIPS (Whetstone) per CPU
16.02.2007 16:05:42||   2381 integer MIPS (Dhrystone) per CPU


Jest sporo wiecej. Dzieki.

Bober

A i jeszcze obiecany P4 (zeby nie bylo, wszystko to sa kompy wydzialowe, wcale nie moje :P ) moze dlatego tez maja nizsze wyniki.
16.02.2007 16:21:55||Starting BOINC client version 5.8.11 for windows_intelx86
16.02.2007 16:21:55||log flags: task, file_xfer, sched_ops
16.02.2007 16:21:55||Processor: 1 GenuineIntel  Intel(R) Pentium(R) 4 CPU 2.60GHz [x86 Family 15 Model 2 Stepping 9]
                                                                                                                                            [fpu tsc sse sse2 mmx]
16.02.2007 16:22:35||Running CPU benchmarks
16.02.2007 16:22:36||Suspending computation - running CPU benchmarks
16.02.2007 16:23:37||Benchmark results:
16.02.2007 16:23:37||   Number of CPUs: 1
16.02.2007 16:23:37||   1344 floating point MIPS (Whetstone) per CPU
16.02.2007 16:23:37||   2756 integer MIPS (Dhrystone) per CPU
16.02.2007 16:23:38||Resuming computation

cezar

2007-02-18 12:14:16 [---] Starting BOINC client version 5.8.11.32  for windows_intelx86
2007-02-18 12:14:16 [---] log flags: task, file_xfer, sched_ops
2007-02-18 12:14:16 [---] Libraries: libcurl/7.16.0
2007-02-18 12:14:16 [---] Data directory: M:\Program Files\BOINC
2007-02-18 12:14:16 [---] BOINC 5.8.11.32 - 32 bit Windows Edition by Crunch3r
2007-02-18 12:14:16 [---] enabled features:
2007-02-18 12:14:16 [---] -cpu_affinity
2007-02-18 12:14:16 [---] Processor: 1 GenuineIntel               Intel(R) Pentium(R) 4 CPU 2.00GHz [x86 Family 15 Model 2 Stepping 4] [fpu tsc sse sse2 mmx]
2007-02-18 12:14:16 [---] Memory: 511.48 MB physical, 865.66 MB virtual
2007-02-18 12:14:16 [---] Disk: 39.06 GB total, 11.11 GB free
2007-02-18 12:14:16 [---] Running CPU benchmarks
2007-02-18 12:14:16 [---] Project communication failed: attempting access to reference site
2007-02-18 12:14:18 [---] Access to reference site succeeded - project servers may be temporarily down.
2007-02-18 12:15:18 [---] Benchmark results:
2007-02-18 12:15:18 [---]    Number of CPUs: 1
2007-02-18 12:15:18 [---]    983 floating point MIPS (Whetstone) per CPU
2007-02-18 12:15:18 [---]    1916 integer MIPS (Dhrystone) per CPU



A to wyniki po zmianie klienta na Crunch3r'a. Zobaczę jak bedą się liczyły próbki i jak punktowały.





D_T_G

Cytat: "bartsob5"to raczej wynika z tego, ze kolega D_T_G uzywa linuksa, a jak wiemy, na linuksie benchmarki sa i zawsze byly slabsze.

Rozgorzała ciekawa dyskusja na forum WCG, nie zapoznałem się jeszcze z całą, ale właśnie natrafiłem na ten fragment:

Cytatthe foundation is in part still based on SETI logic How benchmarks are calculated . What Keck said on the redo of the benchmark is new to me (see nothing in the 2007 CVS log to date)....can't say 5.8.11 or 5.8.12 done anything for me (5.8.14 test version is out). Was only aware of it being reworked so that linux would get a matching value to windows.... an old sore i think more or less resolved.

:)


kret

hmmm..czyli dla Windy w sumie się nic nie zmieniło, ale poprawili w 5.8.11 szybkość na linuxie? :> mmm..niiiice :] może sobie to sprawdzę :)

D_T_G

Cytat: "kret"hmmm..czyli dla Windy w sumie się nic nie zmieniło, ale poprawili w 5.8.11 szybkość na linuxie? :> mmm..niiiice :] może sobie to sprawdzę :)



Improvements in Claimed and Granted Credit with Linux BOINC 5.8.x



CytatHi, I would just like to that everyone involved for the putting the effort into addressing the claimed and granted credit under GNU/Linux.  



I have had BOINC 5.8.8 on my system for around a month and am about to upgrade to BOINC 5.8.11. I have noticed a definite improvement in my claimed and granted credit under Linux, certainly enough to keep to keep this casual cruncher happy  



Before I was usually claiming lower than the granted credit, now I consistantly claim higher, and the granted credit is usually higher than before as well.



So to everyone running Linux who hasn't upgraded yet, do it it is well worth your while.



:-$



Opisałem to już właściwie w [link nie aktualny]tym wątku.


kret


bartsob5

ale wciaz te benchmarki sa o ok 16% slabsze w moim przypadku...

D_T_G

---------- 20:46 05.03.2007 ----------

less points with BOINC 5.8.8 for FightAIDS@home

CytatWell, (Whet+Dhry)*Duration / Claim = Divisor. Depending on the WU it is either about 492 or 513. Your hourly claim is around 12.95.

Why the divisor is not the 480 exact - always on my P4 - i dont know, but on my (windows) C2D it varies from 480 to 484. Anyway, Dr. Anderson seems to have tweaked the algorithm. With a before of about 30 and now 55-65, things look to be in much better shape on Linux.....one day if flop counting becomes a reality, all credits will be exactly identical no matter what platform.

---------- 08:53 06.03.2007 ----------

Wczoraj samoczynnie odbyły się u mnie benchmarki na 5.8.15, dopiero później to odkryłem. Wyniki były takie:

2007-03-05 09:25:53 [---]    1792 floating point MIPS (Whetstone) per CPU
2007-03-05 09:25:53 [---]    4278 integer MIPS (Dhrystone) per CPU


Postanowiłem znowu wyłączyć Xy i wszystko co niepotrzebne i przeprowadzić serię 3 benchmarków, ale na trzech się nie skończyło ;)

2007-03-06 08:08:45 [---]    1847 floating point MIPS (Whetstone) per CPU
2007-03-06 08:08:45 [---]    4432 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:10:16 [---]    1850 floating point MIPS (Whetstone) per CPU
2007-03-06 08:10:16 [---]    4440 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:16:42 [---]    1850 floating point MIPS (Whetstone) per CPU
2007-03-06 08:16:42 [---]    3869 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:20:17 [---]    1849 floating point MIPS (Whetstone) per CPU
2007-03-06 08:20:17 [---]    4436 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:22:56 [---]    1851 floating point MIPS (Whetstone) per CPU
2007-03-06 08:22:56 [---]    3774 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:25:03 [---]    1849 floating point MIPS (Whetstone) per CPU
2007-03-06 08:25:03 [---]    3844 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:28:30 [---]    1847 floating point MIPS (Whetstone) per CPU
2007-03-06 08:28:30 [---]    3866 integer MIPS (Dhrystone) per CPU
====================================
2007-03-06 08:36:17 [---]    1851 floating point MIPS (Whetstone) per CPU
2007-03-06 08:36:17 [---]    4422 integer MIPS (Dhrystone) per CPU


Więc jeśli chodzi o floating point to we wszystkich benchmarkach są one praktycznie te same, od 1847-1851 (1792 przy włączonych X-ach), zmniejszyły się w porównaniu do 5.8.11 (1890-1898). Testy integer różniły się już znacznie, od 3774 do 4440 (4278 przy włączonych X-ach), one również się zmniejszyły w porównaniu do 5.8.11, gdzie wynosiły 4293-4682, przy czym zazwyczaj oscylowały w okolicach 4650, teraz 4400.

---------- 08:47 20.03.2007 ----------

MASAKRRRA!

Dziś postanowiłem wypróbować 5.8.17 i... zostaję!! Bartsob - spróbuj koniecznie na linuksie!

Powyżej widzicie wyniki benchmarków na poprzednich wersjach, większość z nich robiona była przy wyłączonym X'ach i wszelkich niepotrzebnych procesach, teraz po upgradzie włączyłem ją bez ceregieli, przy włączonych X'ach, KDE, berylu itd. a mimo to wyniki są znacznie lepsze:

Cytat2007-03-20 08:26:22 [---] Starting BOINC client version 5.8.17 for i686-pc-linux-gnu
2007-03-20 08:26:22 [---] log flags: task, file_xfer, sched_ops, task_debug
2007-03-20 08:26:22 [---] Libraries: libcurl/7.16.0 OpenSSL/0.9.8d zlib/1.2.3
(...)
2007-03-20 08:26:22 [---] Version change (5.8.15 -> 5.8.17)
(...)
2007-03-20 08:27:24 [---] Benchmark results:
2007-03-20 08:27:24 [---]    Number of CPUs: 2
2007-03-20 08:27:24 [---]    2208 floating point MIPS (Whetstone) per CPU
2007-03-20 08:27:24 [---]    6391 integer MIPS (Dhrystone) per CPU

:D ... Bug to czy ficzer? 8-[

---------- 12:54 23.03.2007 ----------

Kilka ciekawostek (wyłuskane z forum WCG)

1)Dlaczego benchmarki na Linuksie są słabsze niż na Windowsie? (choć z 5.8.17 to już może być przeszłość...)

Cytat
Cytat2. Linux credit system compared to Windows credits system is unfair! (Ok, thats hearsay, but if you hear dozens of linux users saying the same...


This is being worked on. The problem is that Windows compilers cheat when compiling benchmarks. The compiler writers competed with each other back in the 1990's by eliminating code that does not produce a result, which speeds up the benchmarks substantially.

2)Nieświadome śrubowanie benchmarków na Linuksie przez własną kompilację (x86_64) i tego konsekwencje:

CytatAh, you missed out the "built it myself" bit. Sounds like you broke the benchmark (quite by accident) by optimising it away.

You see, compiling the client with all sorts of optimisations and extra CPU features makes absolutely no difference to the work you crunch for WCG. None. Zero. Sorry.

So, if you turn on loads of extra features in building the client, then the benchmark will go super-fast (after all, the entire benchmark can generally fit into L1 cache) - but the actual work is unaffected. Until you come to calculate the points you will claim. And the super-fast and completely wrong benchmark provides you with a totally wrong claim.

And WCG penalise crazily high claims. Partly to stop you getting an insanely high score, and partly to alert you to the fact that your benchmark is out of whack.

Please ask if any of this is unclear.

The bottom line is this: if you have a fancy super-fast computer, then you get more points by doing more work. You do not get more credit for doing the same work as someone else. You should claim exactly the average for each work unit - only you will be claiming for many, many more work units.

CytatIt's probably in part this, as I enabled vectorization, but there's another factor: CPU throttling for power saving. When the BOINC client runs the benchmarks, it does so using normal priority, therefore the CPU clock governor increases the CPU frequency. But when the application is run, using the lowest priority the possible, the CPU governor will not increase the CPU frequency above base-line. At least this is how the governor works in Linux. So it's probably a combination of both factors.

As I suggested above, other projects ignore the claimed credit by the client and just assign credits depending on the number of operations in the WU, if possible, and the time it took to complete.

I'll rebuild the client without vectorization, but I ask you to consider the effects of CPU throttling as well.

CytatIt wasn't enabling vectorization that undid the benchmarks, but what I stated earlier about Linux ignoring low-priority applications when throttling the CPU clock whereas the benchmarks are run with normal priority, when the CPU clocked is pegged up.

It's pretty bad on this particular system because it varies the CPU clock between 1 and 2.2GHz, thus the discrepancy between claimed (based on benchmarks results with the CPU clock pegged) and the actual credits (based on the application running with the CPU clock throttled).

I submitted a patch in the BOINC development mailing-list to correct this and it should be in the next client release.

Meanwhile, I rebuilt the client with this patch and the benchmarks results are lower, reflecting the actual performance of this system when the CPU clock is throttled. I will keep an eye on its results.

CytatIn Linux the CPU clock governor doesn't consider processes running with idle priority when deciding whether the system load warrants an increased CPU clock frequency. It makes sense, for it's fair to assume that a process at idle priority has no dead-line. In that system specifically, the CPU remains at 1GHz.

However, the BOINC client runs the benchmarks with normal priority, therefore when the CPU clock governor notices the increased system load, it pegs the CPU clock frequency. In that system, to 2.2 GHz.

Thus, the GFlOps reported by the benchmark is not the same available to the applications. My proposed patch makes sure that both run at the same priority. On Linux systems which enabled the CPU clock governor, clients won't "overclaim" anymore and on those systems which didn't enable it, there'll be no difference.

I could set the system to peg the CPU clock frequency (powersave -f), but it's a server in a rack and letting the CPU clock frequency vary dynamically is preferable, as I don't want to increase the closet temperature and jeopardize the rack reliability to crunch for WCG.

CytatBy running the benchmarks with the same idle priority as the applications, the system now claims an amount of credit closer to the granted credit: (...) And no punishments!

Interesuje to kogoś w ogóle? :P


AL

Zawsze mnie ciekawiło dlaczego użytkownicy linuksów są w benchmarkach poszkodowani. Z tych odpowiedzi też to jakby dokońca nie wynika. Czy nie da się po prostu w kliencie linuksowym zaimplementować jakiegoś odpowiednika wskaźnika wg. którego  były by mnożone te benczmarki względem tych windowsowych?

D_T_G

Cytat: "AL"Zawsze mnie ciekawiło dlaczego użytkownicy linuksów są w benchmarkach poszkodowani. Z tych odpowiedzi też to jakby dokońca nie wynika. Czy nie da się po prostu w kliencie linuksowym zaimplementować jakiegoś odpowiednika wskaźnika wg. którego  były by mnożone te benczmarki względem tych windowsowych?

To powinno być maksymalnie uniwersalne, tym bardziej, że kernel Linuksa jest ruchomym celem ;) Tymczasem benchmarki na 5.8.17 wyglądają już baardzo obiecująco :P


AdNet

Właściwości procesora:
     Typ procesora                                     AMD Athlon 64, 1800 MHz (9 x 200) 2800+
     Nazwa kodowa                                    Newcastle S754
     Pamięć fizyczna                                   1024MB  


2007-03-25 23:27:40||Running CPU benchmarks
2007-03-25 23:27:40||Suspending computation - running CPU benchmarks
2007-03-25 23:28:41||Benchmark results:
2007-03-25 23:28:41||   Number of CPUs: 1
2007-03-25 23:28:41||   1674 floating point MIPS (Whetstone) per CPU
2007-03-25 23:28:41||   3008 integer MIPS (Dhrystone) per CPU
2007-03-25 23:28:42||Resuming computation



Po małym przetaktowaniu na 3000+


2007-03-25 23:36:18||Benchmark results:
2007-03-25 23:36:18||   Number of CPUs: 1
2007-03-25 23:36:18||   1866 floating point MIPS (Whetstone) per CPU
2007-03-25 23:36:18||   3376 integer MIPS (Dhrystone) per CPU
2007-03-25 23:36:19||Resuming computation


Tyle że moja wersja BOINCa to 5.8.15
Dlaczego robicie Benchmarki (i jak się domyślam pracujecie) na wersji 5.8.11 ?? Jest w czymś lepsza ?

Bober

Wątek powstał, gdy 5.8.11 było najnowszą wersją.

AdNet

Czyli rozumiem, że macie już x.xx.15 ??
Czy jednak starsze wersje są w czymś lepsze (tu skojarzenie na wino i kobiety)

D_T_G

---------- 18:14 14.04.2007 ----------

Na 5.9.3 benchmarki na linuksie powróciły na stary niższy poziom, mimo kontynuacji zachwalanego przejścia na glibc 2.4... jak się okazuje wzrost benchmarków w większej mierze zawdzięczamy przejściu na nowe gcc 4.x, choć rzeczywiście najlepsze efekty daje on w połączeniu z glibc 2.4.

---------- 21:46 28.11.2007 ----------

Podczas dyskusji w innym wątku przypomniał mi się ten temat. Od czasu kiedy tu w tym wątku (poprzednia strona) odkryłem, że 5.8.17 ma b. fajne benchmarki to od tego czasu na nim siedzę. Tymczasem wychodziły nowe wersje, i nie śledziłem za bardzo sytuacji. Postanowiłem nadrobić te zaległości i przetestowałem wszystkie wersje linuksowe boinca od wersji 5.8.10 do 5.10.28 (do ściągnięcia stąd, 5.8.17 - też!). Benchmarki przeprowadzałem jednokrotnie, w wirtualnym terminalu (yakuake), w kde 3.5.8 bez wynalazków typu compiz-fusion, podczas testów przypatrywałem się gkrellmowi (dzięki czemu łatwo zauważyłem błędne nice drugiego benchmarku w 5.8.10), w tle działał azureus i opera. Kernel to 2.6.23.8 z patchem CFS-v24 (hmmm, właściwie to go obwiniam za zaobserwowane kilkudziesięciosekundowe freezy systemu podczas przeglądania www jak się ma załączonego boinca, chyba trza to gdzieś zgłosić...), skompilowanym jako preempt kernel, timer 1000Hz.

Linux pingwin 2.6.23.8-tojemoje #1 SMP PREEMPT Thu Nov 22 22:04:12 CET 2007 i686 i686 i386 GNU/Linux

Processor: 2 GenuineIntel Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz [Family 6 Model 15 Stepping 6][fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo



Efekt - na razie zostaję przy 5.8.17 :] Nie wie ktoś jakie benchmarki mają wersje x86_64?


kret

a można podobie założyć, że te wersje mają lepsze benchmarki na win?

D_T_G

Cytat: "kret"a można podobie założyć, że te wersje mają lepsze benchmarki na win?

Raczej nie, bo afaik te anomalie to nie efekt zmiany kodu odpowiedzialnego za benchmarki, ale eksperymentów z tworzeniem jak najbardziej uniwersalnych binarek, które by śmigały na jak najszerszej gamie dystrybucji, b. dobre wyniki uzyskiwano po kompilacji dla najnowszych glibc, używając najnowszego gcc, ale takie binarki sypały się na wówczas najpopularniejszej dystrybucji (yyyy, óbóntó narombany murzyn czy siakoś tak ;) ). Jeśli chodzi o 5.8.17 to jeśli Ci się nie sypie na starcie, to możesz śmiało ich używać :)

#1:
Cytat: "KSMarksPsych"They used a newer version of glibc to compile for 5.8.17 (to try to equalize benchmarks between Linux and Windows). But because it didn't work on older systems they pulled it as the recommended version and put back 5.8.16 on the download page.

#2:
Cytat: "Nicolas"Yes there was a change. A more recent version of the gcc compiler is used, getting better optimizations and in turn more accurate benchmarks. By default it uses glibc 2.4. I think it's possible, but not so easy, for the developers to use a new compiler with an older glibc. I was unable to install 5.8.17 on Ubuntu Dapper, which is Ubuntu's "Long Term Support" version; I guess a lot of people run that version. So I suggested going at least one version back, that is, using glibc 2.3 on BOINC.