CPU SMP benchmark

UNIX haladó

Ajanljatok nekem olyan benchmark programot Unixra, ami:

- altalanos Unix kod (eloszor AIX-en futtatnam, tehat nem compizbench)
- alkalmas a nyers CPU (esetleg +memoria) teljesitmenyenek meresere
- alkalmas massziv SMP teljesitmeny meresere
- forrasbol elerheto
- optimalizalast is lehetove tesz
- idealis esetben C, hogy keveset kelljen szenvednem vele
- lehet Java is, csak menjen IBM Java 1.5-tel
- nem 'GCC constrained', azaz xlC-vel is le tudom forditani
- kis meretu (nem egy tobb 100 MB-os tudomanyos-fantasztikus diplomamunka)
- disk I/O-t nem akarok figyelembe venni

Amiket probaltam mar:

- openssl speed sha256 -multi X
Sajnos a nagy teljesitmeny miatt infinity-re fut sok eredmeny, illetve kicsit 'keresztbeallnak' az adatok. 


kicsi: md5              10439.62k    35632.25k    95992.75k   165455.19k   212558.05k
nagy : md5                   INFk   187505.58k   276401.27k   212169.37k    84041.42k

- ubench
Tobb mint 10 eves kod, es egyaltalan nem hozza az elvartat, ugy tunik, szinte csak a szalak szama az egyetlen tenyezo, ami tobbletet ad. Emellett nem engedi meg az -O2 -nal magasabb optimalizalast, mert az 'eltorzitja az eredmenyt'. 


kicsi: Ubench CPU:   123033
nagy : Ubench CPU:  6295049

- Java Grande threads
Sajnos az egyik szekcio mar nem fordul az IBM Java 1.5-tel. Meg ez se mai csirke.

A dolog surgos, mert hamarosan at kell adnom a gepet.

  • 3920 megtekintés

( LGee | 2010. 05. 07., p – 11:06 )

PS. Barmilyen 'sajat' C kodot is szivesen kiprobalnek. Nincs mit elrontani... ;-)

bravuros kod... 


 $ make aix-ppc32
        ln -sf ppc32.h arch.h
        make ../run/john ../run/unshadow ../run/unafs ../run/unique  CC=cc  CFLAGS="-c -qunroll=2 -qarch=ppc -qchars=signed"  LDFLAGS="-s -lbsd"  OPT_NORMAL="-O2"  OPT_INLINE="-O3 -Q=99 -w"
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 DES_fmt.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 DES_std.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 DES_bs.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 BSDI_fmt.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 MD5_fmt.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 MD5_std.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 BF_fmt.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 BF_std.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 AFS_fmt.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 LM_fmt.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 batch.c
1506-261 (W) Suboption 2 is not valid for option unroll.
        cc -c -qunroll=2 -qarch=ppc -qchars=signed -O2 bench.c
1506-261 (W) Suboption 2 is not valid for option unroll.
"bench.c", line 38.10: 1506-296 (S) #include file "mpi.h" not found.
"bench.c", line 318.60: 1506-045 (S) Undeclared identifier MPI_LONG.
"bench.c", line 319.25: 1506-045 (S) Undeclared identifier MPI_SUM.
"bench.c", line 319.37: 1506-045 (S) Undeclared identifier MPI_COMM_WORLD.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 2.


Stop.

Attol meg, hogy hasznaltad, ezek szerint nem ertetted meg. Az mpi alapu benchmarkok vagy memoria savszelesseg/kesleltetes korlatosak, vagy a halozati savszelesseget/kesleltetest vagy IPC-t. Es ha meg nem is fektetlenul korlatosak ezekre, jelentosen torzithatjak az eredmenyeket. A benchmarkok elso alapszabalya: csak azt vizsgald, amire kivancsi vagy!

Az MPI-vel szerintem nem is tudsz klasszikus tobbszalu alkalmazast csinalni, mivel mar maga az MPI daemon (ami az uzenetkuldest vegzi) egy onallo processz. Ha egy tobbszalu programod egyik threadje uzenetet kuld a masiknak, akkor az bizony keresztulmegy also hangon valamilyen IPC-megoldason esetleg egy socket-en (figyelj! itt az IO es ez a gyakori eset). Indits el egy MPI-t hasznalo programot, aztan lodd ki az mpi processzt! Futni fog a te programod? Nem. Nalatod.

Illetve a kovetkezo lenne a kerdesem: hogy tudsz tobbszalu programot csinalni MPI kornyezetben, ha nem hivsz pthread_create()-et? Sehogy. Amikor kiadod az mpirun -n 8 parancsot, akkor az mpirun script 8 egyszalu processzt indit a programbol, nem pedig egy processzt 8 szallal.

A topicindito multithread CPU benchmarkot keresett. Ebben az esetben olyat kellene ajanlani, ami nem terheli annyira a memoriat, de mondjuk a cache koherenciaprotokollt es a cpu-t igen. En valamilyen jol parhuzamosithato kombinatorikai benchmarkot probalnek. Talan a SPEC-nek (www.spec.org) van egy ket tesztje, ami idevag (SPEC OMP2001, SPEC OMPL2001)

Egyebkent meg igenis olyan cuccokat kellene keresni, amik pthreads-en alapulnak leven ezeknek semmilyen futasideju igenye nincs leszamitva magat a pthreads konyvtarat. Es ezek tenyleg IGAZI tobbszalu kodok. Ugyanez igaz az OpenMP-re is, csak ott a fordito fogja begeneralni a pthread kodot. 


checking if C++ compiler works... no
**********************************************************************
* It appears that your C++ compiler is unable to produce working
* executables.  A simple test application failed to properly
* execute.  Note that this is likely not a problem with Open MPI,
* but a problem with the local compiler installation.  More
* information (including exactly what command was given to the
* compiler and what error resulted when the command was executed) is
* available in the config.log file in this directory.
**********************************************************************
configure: error: Could not run a simple C++ program.  Aborting.

Joy & happiness...
Meg szerencse, hogy hozza vagyok szokva ehhez a szarakodashoz.

Semmi bajom a forditassal. ;-)
Ez csak egy kis reszlet, install-old alatt van meg boven. Ami elott _alulvonas van, az lefordult ;-) 


$ ls -1 /install
AIXfixes/
__curl-7.19.4/
__flex-2.5.35/
__gettext-0.17/
__glib-2.20.1/
__irssi-0.8.13/
__links-2.2/
__lsof_4.82/
__m4-1.4.13/
__pkg-config-0.23/
__screen-4.0.3/
__sudo-1.7.1/
__wget-1.11.4/
__zlib-1.2.3/
aix433_man_libs.tar.gz
bitlbee-1.2.3/
bitlbee-1.2.3.tar.gz
flex-2.5.35.tar.gz
install-old/
libs/
libsigc++-2.2.3/
libsigc++-2.2.3.tar.gz
libtorrent-0.12.4/
libtorrent-0.12.4.tar.gz
linuxtoolbox/
llvm-2.5/
llvm-2.5.tar.gz
lost+found/
m4-1.4.13.tar.gz
make-3.81/
make-3.81.tar.gz
nginx-0.6.36/
nginx-0.6.36.tar.gz
openssh-5.2p1/
openssh-5.2p1.tar.gz
postfix-2.6.1/
postfix-2.6.1.tar.gz
rperf_v7
rtorrent-0.8.4/
rtorrent-0.8.4.tar.gz
tmux-0.9/
tmux-0.9.tar.gz
traffic-vis-0.35/
traffic-vis-0.35.tar.gz

Ha erdekel, olyan kodot tudok adni, ami parhuzamos (zar nelkuli) hash-tablat toltoget adatokkal parhuzamosan annyi szalon, amennyit beallitasz neki. Egyetlen problema vele, hogy hasznal egy GCC built-in parancsot (Compare and swap utasitas). Ha kell, akkor szolj es elkuldom. Van belol olyan valtozat, ami zarakkal van implementalva, azzal anno teszteltem, hogy melyik OP mennyire kezli hatekonyan a zarakat.

( egeresz | 2010. 05. 07., p – 11:48 )

Egy SMP rendszer teljesitmenymerese a kovetkezo szelso meresekbol allhat:

- a kulonbozo magok mennyire fuggetlenek egymastol?
Ezt meri a spec.org specFP_rate, specINT_rate metrikaja, vagyis minden szalon elindit egy, a tobbitol fuggetlen szamolast, es azt meri, hogy a gep mennyire tudja ezeket egymas zavarasa nelkul futtatni (mennyi az eredi teljsitmeny). Nem olyan egyszeru olyan hardvert csinalni, ahol ez a teszt jol teljesit, a feladat igenis valos. az IBM POWER architektura hagyomanyosan a legjobb ebben a szegmensben.

- a kulonbozo magok mennyire kepesek egyuttdolgozni?
Ezt nagyon nehez altalanosan merni. Jobban fugg az alkalmazott (altalaban vacakul megirt) alkalmazas josagatol, mint a hardvertol. Azonban ilyenre pelda a spec.org OpenMP tesztje

Tulajdonkeppen amugy is csak a real world szituaciokat lenne ertelme tesztelni, hiszen itt nem HPC a felhasznalas.
Viszont erre korulmenyes lenne referenciat osszeallitani, mert egy tipikus web frontend/appserver/RDBMS elemekbol allo kornyezet tul sok komponenssel dolgozik.

Ezert most csak annyit akartam volna bizonyitani, hogy egy regi, 2 core-ral rendelkezo POWER4-hez kepest ez a monstrum valoban megmutatja a - papiron - brutalis teljesitmenykulonbseget. Mindezt valami egyszeru megoldassal.

( LGee | 2010. 05. 07., p – 11:56 )

Ramdisk elokeszitese: 


mkramdisk 800M
mkfs -V jfs2 -o log=INLINE /dev/ramdisk0
mkdir /tmp/ramdisk
mount -o log=INLINE /dev/ramdisk0 /tmp/ramdisk

dd tesztek: 


time dd if=/dev/zero of=/tmp/ramdisk/512Mfile bs=1M count=512

'kicsi' (POWER4, DDR):
real 0m3.94s
user 0m0.02s
sys 0m3.67s

'nagy' (POWER6, DDR3):
real 0m1.59s
user 0m0.01s
sys 0m1.27s

( LGee | 2010. 05. 07., p – 12:03 )

pigz:

AIX, pigz 2.1.6, ramdisk, 350MB forrasfile
cc optimalizalas: CFLAGS=-qdfp -q64 -qarch=pwr6 -qtune=pwr6 -O3, OBJECT_MODE=64 


# time pigz -9 -p$num_threads -k -v /tmp/ramdisk/hacmp53.tar

kicsi: num_threads=2; POWER4:

real 0m36.90s
user 1m9.20s
sys 0m2.58s

nagy: num_threads=64; POWER6:

real 0m5.38s
user 0m16.33s
sys 0m0.55s

Ez eddig eleg gyenge...

Ez eddig eleg gyenge...

Nem tudom, hogy mit varsz, mi az, ami nem gyenge.

A pigz (-gondolom- mint a tomoritok altalaban) inkabb cache intenzivek, vagyis a teljesitmenyuk a processzorba epitett cache meretetol es eleresi frekvenciajatol fugg, nem annyira a cpu szamolasi teljesitmenyetol. Ezek power chipek, a cache meretevel nem szokott lenni problema.

Ha linux lenne, azt mondanam, hogy fordits kernelt ramdiszkrol es jatsz a CONCURENCY_LEVEL kapcsoloval.

tehat akkor ez 32 cpu/64 mag power6 masina. Na, ebbol tul sokat nem gyartott az IBM, csak egyet, amit 'IBM Power 595' -nek hivnak.

Van 4.2 es 5 GHz-ben.

"a valami hardveres limit" azt hiszem az lesz, hogy 1 darab 64 bites szoban tarolja az oprendszer lelke a rendelkezesre allo cpu-k szamat.

2003-as power4 1.7GHz specINT2000 (egyszalu) teljesitmenye 1158
2006-os power5+ 2.2GHz specINT2000 (egyszalu) teljesitmenye 1765
ugyanennek a specINT2006 (egyszalu) teljesitmenye 13.2
2008-as power6 4.2GHz specINT2006 (egyszalu) teljesitmenye 16.2

ezekbol extrapolalava azt hozom ki, hogy a 2008-as power6 egy magja integer muveletre 1.87 -szerese a 2003-as power4 egy magjanak. (tehat 87% pluszt ad).
Ha komoly kulonbseget akarsz latni, akkor mindenkeppen a thread szamat kell erosen nyomni. ehez olyan alkalmazas kell, ami jol parhuzamosithato. A john-mpi eppen ilyen ;-) meg az lbzip2 is. Ez utobbi elegge portolhato joszag, itteni az alkotoja.

Jo lenne az a specINT2000 is nekem ;-)

lbzip2-t probalom, aztan mindjart feladok egy-ket feature requestet is a szerzonek ;-)

lassu gep: 


# time /home/build/lbzip2/lbzip2 -n 2 -k -v /tmp/ramdisk/hacmp53.tar
lbzip2: compressing "/tmp/ramdisk/hacmp53.tar" to "/tmp/ramdisk/hacmp53.tar.bz2"

real    1m33.95s
user    3m3.88s
sys     0m2.23s

gyors gep: 


$ time /tmp/lbzip2 -n 64 -k -v /tmp/ramdisk/hacmp53.tar
lbzip2: compressing "/tmp/ramdisk/hacmp53.tar" to "/tmp/ramdisk/hacmp53.tar.bz2"
lbzip2: "/tmp/ramdisk/hacmp53.tar": BZ2_bzCompressInit(): BZ_MEM_ERROR
lbzip2: "/tmp/ramdisk/hacmp53.tar": BZ2_bzCompressInit(): BZ_MEM_ERROR
lbzip2: "/tmp/ramdisk/hacmp53.tar": BZ2_bzCompressInit(): BZ_MEM_ERROR
lbzip2: "/tmp/ramdisk/hacmp53.tar": BZ2_bzCompressInit(): BZ_MEM_ERROR
lbzip2: "/tmp/ramdisk/hacmp53.tar": BZ2_bzCompressInit(): BZ_MEM_ERROR
lbzip2: "/tmp/ramdisk/hacmp53.tar": BZ2_bzCompressInit(): BZ_MEM_ERROR

Ez eddig fail...

> ugy olvasom, hogy a power6 az 2 thread/core, 2core/cpu

Ez nem ilyen egyszeru, a modulok tobbfele kiszerelesben leteznek. Az LPAR-ok letrehozasanal a fizikai core-okat tudod 0.1 egysegig osztani, a virtual core-ok szama kvazi tetszoleges, es nem kell linearis aranyban allnia a fizikai core-okkal.

Tehat pl a kovetkezo parameterek lehetnek beallitva egy LPAR-nak:

min_proc_units=0.1
desired_proc_units=0.2
max_proc_units=0.8
min_procs=4
desired_procs=8
max_procs=12

A POWER6 2-way SMT, a POWER7 pedig 4-way.

ah, tehat egy ibm szallito partnernek dolgozol, es meg kell gyozni az ugyfelet, hogy a cucc a regihez kepest uberbrutal :-)

eleg ehez csak a szamla also sorara neznie nem? :-)

ha nem megy a john-mpi, akkor probald a lbzip2 -vel, az talan konnyebb falat, es kulonben is szereti sok-sok l3 cachet, ami meg van ugyebar.

a) opció: hülye ügyfél - rajzolj nekik valami kamu alkalmazást, ami pont azt írja ki, amit látni szeretne;

b) opció: értelmes ügyfél - a meglevő alkalmazását szeretné gyorsítani, tehát azon kell(ene) demonstrálni, hogy mennyivel gyorsabb... hacsak nem diff. egyenletrendszereket old meg, vagy más hasonló numerikus számításokra használja, akkor 99%, hogy a diszk kevés az rdbms-e mögött, tehát nem feltétlenül a cpu környékén nézelődnék.

Hogy el ne felejtsem, ez a tomorites eredmenye: 


$ du -sm /tmp/ramdisk/h*
349.20  /tmp/ramdisk/hacmp53.tar
218.26  /tmp/ramdisk/hacmp53.tar.gz

Es lbzip2-vel: 


$ du -sm /tmp/ramdisk/h*
349.20  /tmp/ramdisk/hacmp53.tar
200.46  /tmp/ramdisk/hacmp53.tar.bz2

~100 db, atlagban 5-10MB meretu file van a tarballban.

( bambano | 2010. 05. 07., p – 13:39 )

a feltételeid egy részének megfelel, ha bc-vel e-t vagy pi-t számoltatsz sok jegyre.

miért kéne egyeznie?
szimbólikuasn ekvivalensek, (egy trigonometria azonosság alapján), numerikusan meg a bc miatt nyilván különbözik

("ki lehet számolni": azért használják az atan(1) átírását hogy a sorbafejtés ha nem 1-re történik, sokkal gyorsabb, még ha utána szorozgatni meg összedni is kell is; az hogy valaki nem tudja hogy a bc implementációjában milyenm művelet tán hány értékes jegy lesz, az más kérdés)

you must be kidding (bocs) ;-)

Megnezted mar, mi ez az rPerf? Egy ganyolt ksh93 script ('No restrictions, copy and use at will, this is just sample code'), ami ha tudja azonositani a modellt es a CPU orajelet, akkor egy tablazatbol kikeresi a megfelelo erteket: 


        # 520
        IBM,8203-E4A_4200_*) matchup 1 8.39 2 15.95 4 31.48 ;;

( LGee | 2010. 05. 14., p – 14:50 )

Ugy tunik, perlben egesz jol lehet benchmarkolni nagy sorozatszamu, tetszoleges matematikai muvelettel, raadasul van 'beepitett' benchmark, csak ez single threaded: 


#!/usr/bin/perl

 use Benchmark;

 timethis(100000, '
   for ($x=0; $x<=200; $x++)
   {
     sin($x/($x+2));
   }
 ');

Mindenesetre ez csaknem linearis osszefuggest ad az orajellel:

Perl 5.8.2; 1x 1.0GHz POWER4; AIX 6.1 TL3: 


timethis 100000: 33 wallclock secs (32.65 usr +  0.00 sys = 32.65 CPU) @ 3062.79/s (n=100000)

Perl 5.8.8; 1.75x 5.0GHz POWER6 (4x vCPU); AIX 5.3 TL11: 


timethis 100000:  8 wallclock secs ( 7.14 usr +  0.00 sys =  7.14 CPU) @ 14005.60/s (n=100000)

5200-08-CSP
Perl v5.8.0
Processor Type: PowerPC_POWER3
Number Of Processors: 2
Processor Clock Speed: 450 MHz
Memory Size: 4096 MB

timethis 100000: 45 wallclock secs (44.25 usr + 0.00 sys = 44.25 CPU) @ 2259.89/s (n=100000)

LOL! Ennél szarabb gépet nem találtam most hirtelen putty-közelben.
--
2e845cb4c3a5b5bd6508455b1739a8a2

Ugyanilyen órajelű pécén (nemceleron pentium 3 @ 450 MHz):

$ perl bench.pl
timethis 100000: 184 wallclock secs (72.98 usr + 0.05 sys = 73.03 CPU) @ 1369.28/s (n=100000)

:)

Érdekesség- és összehasonlításképpen almás cuccok:

Processor Name: PowerPC G4 (PowerPC 7450)
Processor type: ppc7450
Processor Speed: 867 MHz
Number Of CPUs: 1
Darwin Kernel Version 9.8.0
$ timethis 100000: 32 wallclock secs (31.22 usr + 0.11 sys = 31.33 CPU) @ 3191.83/s (n=100000)

Processor Name: PowerPC G5 (PowerPC 970)
Processor Speed: 1.8 GHz
Number Of CPUs: 2
Darwin Kernel Version 9.8.0
$ timethis 100000: 16 wallclock secs (15.67 usr + 0.09 sys = 15.76 CPU) @ 6345.18/s (n=100000)

A kamu szerint ez utóbbi ugyanaz a processzor, mint ami POWER5 néven például a BladeCenter JS20-ba is került.

--
2e845cb4c3a5b5bd6508455b1739a8a2

nyos@hex:~$ ./bench.pl
timethis 100000: 5 wallclock secs ( 4.43 usr + 0.00 sys = 4.43 CPU) @ 22573.36/s (n=100000)

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
stepping : 5
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : 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 syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 5345.82
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

(es ez meg 7x a HT miatt)
Amugy Ubuntu 9.10, egyik hetvegen majd jon a dist-upgrade.

--
I can't believe Steve Jobs's liver is replaceable but the battery in my iPhone is not. - sickipedia

Sajnos most nincs időm ezzel foglalkozni, de ha már perl, és ha már többszálba gabalyodás, akkor talán tudok adni valamit.

Egy tavalyi projekthez akartam egy olyan feldolgozót csinálni perlben, ami adott feladatokat szétoszt több párhuzamosan futó R processz között. Mint kiderült, az a konkrét R modul, amit használnom kellett, valamilyen rejtélyes ok miatt nem szeretett párhuzamosan futni egy vagy több ikertestvérével, így az egész erőfeszítés hiábavaló volt, de a probléma debuggolásakor keletkezett egyik példaprogramocskát talán használni tudod.

Annyit csinál, hogy indít n worker threadet, és egy queue-n keresztül kioszt nekik feladatokat.

Most csak annyit ellenőriztem, hogy lefut-e. A calc függvénybe értelmes tevékenység beírása, az időmérés, a felesleges printek kivétele és a kód minőségén való szörnyülködés a te dolgod lesz. 


#!/usr/bin/perl

use strict;
use warnings;
use Storable qw(nfreeze thaw);
use threads;
#use threads::shared;
use Thread::Queue;

local $| = 1;

my $in_q = Thread::Queue->new();
my $out_q = Thread::Queue->new();
my $thread_no = 2;
my $number_packages = 0;
my $number_results = 0;

for (1..$thread_no) {
        threads->create(\&work_thread, $_)->detach();
}

my @data = (1..10);
my $final = 0;
my $v; my $u;
my @slice;


for my $i (@data) {
        $in_q->enqueue($i); $number_packages++;
        #while (my $items = $out_q->pending() > 0) {
        #        $v = $out_q->dequeue();
        #        $number_results++;
	#			$final .= $v;
      #  }
}

for (0..$thread_no-1) {
        $in_q->enqueue("DONE");
}

print "Done assigning jobs, waiting...\n";
while (my $to_be_processed = $in_q->pending() > 0) {
	print "%"; sleep(1); print "#";

}
print "@";

while (my $items = $out_q->pending() > 0) {
        $v = $out_q->dequeue();  $number_results++;
        $final .= $v;
}

#print length($final);
print $final;
print "!!! $number_packages packages pushed, $number_results result received\n";
#sleep(10);
exit(0);


sub work_thread {
		my ($tid) = shift;
        my ($work, $result);
        my $num = 0;
        while (1) {
                $work  = $in_q->dequeue();
                # If end-of-queue marker reached then cleanup and exit.
                if($work eq "DONE"){
                		print "Thread $tid done $num jobs\n";
                        return 0;
                } elsif ($work) {
                        #$ar = thaw($work);
                        #$result = 0;
                        #for (@$ar) {
                        #       $result += $_;
                        #}
                        #$result = nfreeze($result);
                        $num++;
                        print "Thread $tid, number $work\n";
                        $result = calc($work);
                        #my $result = `/home/kikuchiyo/c/megvil6`;
                        $out_q->enqueue($result);
                }
        }
}

sub calc {
        my $frozen = shift;
       	print "rrr";
        my $result = `/home/kikuchiyo/c/megvil6`;
        print $result;
        return $result;
}

( Finder | 2010. 05. 15., szo – 20:57 )

Ezt most írtam kifejezetten sok procis gépek tesztelésére. Még bőven van mit alakítani rajta, de azért örülnék, ha páran kipróbálnák:
www.freeweb.hu/mac-bolt/PrimeMark.jar

használat: java -jar PrimeMark.jar szálak_száma
pl. java -jar PrimeMark.jar 2

Eredmények egy ThinkPad R400-ason (Core 2 Duo 2,1GHz, Ubuntu 10.04):
Előkészületek: 12ms
Számítás: 2296s

Mint látható, nem kevés ideig fut. Tulajdonképpen megszámolja, hogy hány darab 32b-es változóban elférő prím szám van. (Felhasználva azt, hogy minden összetett számnak van legalább egy, a szám gyökével megegyező vagy annál kisebb osztója.)

RAM-ot nem használ sokat, de a cache-t szereti.

Net, neha zene, 4-es KDE meg csillivillik mellett:
nyos@hex:~/benchmark$ java -server -jar PrimeMark.jar 4
...
Előkészületek: 12ms
Számítás: 649s
nyos@hex:~/benchmark$ java -server -jar PrimeMark.jar 8
...
Előkészületek: 13ms
Számítás: 532s
nyos@hex:~/benchmark$ java -server -jar PrimeMark.jar 12
...
Előkészületek: 8ms
Számítás: 509s

A proci egy i7-es (cpuinfo a fenti hsz-ben), szoval 4 magos, a hyperthreading miatt 8-nak latszik az OS fele. Amikor 8 szalon futott, nem foglalta le mindegyik (latszolagos) core-t, volt, hogy csak 6-700%-on jart. Ezert inditottam el 12 szalon is. Az mindenesetre latszik, hogy a bekapcsolt HT sokat szamit, de kozel sem teljeserteku az igy nyert 4 mag.
(A proci winen ennel kicsit tobbet tudna, Ubi alatt elvileg nem tamogatott a turbo boost.)

A topicnyito nem tudom mennyit er el ezzel, mert a RAM-ot nem teszteli. Bar az Intel cpu-k kozt a 9xx-as i7 az egyik legnagyobb savszelessegu, a POWER valoszinuleg meg igy is raverne. Szoval egy ilyen, RAM-ot alig hasznalo benchmark pont nem mutatja az architektura erejet.

update: 1 szalon (filmnezes kozben, szoval nagyobb egyeb terhelessel):
Előkészületek: 8ms
Számítás: 2197s

2 szalon:
Előkészületek: 8ms
Számítás: 1162s

szinten update:
Meglepo. Gondoltam kiprobalom, hogy "rengeteg" szal eseten a sok kornyezetvaltas mennyire lassitja le.
256 szal eseten:
Előkészületek: 8ms
Számítás: 487s
Tehat eddig ez volt a leggyorsabb (arra tippeltem, hogy 9-12 szalnal lesz az optimum). Igaz, hogy futas kozben a gep mar akadozott, a load ertelemszeruen tullott 100-on, es 2-2,5GB-ot megevett ez a java process.

upd:
1024 szalnal mar tenyleg sok a kornyezetvaltas, lassabb, mint 256-ra:
Előkészületek: 8ms
Számítás: 499s
Raadasul a GC hagyja, hogy felmenjen majdnem 4GB-ra a memoriahasznalat. Azert altalaban ez is 2-3GB korul mozgott.

--
I can't believe Steve Jobs's liver is replaceable but the battery in my iPhone is not. - sickipedia

Hello!

Köszönöm a visszajelzést! Ezek alapján fogok javítani rajta.

Nem semmi ez az i7. Én most egy Phenom II X6-tal szemezek, érdekelne, hogy az hogyan teljesít. Rakok majd még bele pár másik algoritmust is, csak első körben szerettem volna egy olyat ami sok magot képes 100%-ra kihajtani, mert a különféle proci teszteknél zavar, hogy tulajdonképpen nem is a processzort tesztelik, hanem az egész rendszert amit öszepakoltak alá.

Nos... feltöltöttem a valószínűleg jó darabig érvényes verziót.
Remélem lesz akinek hasznos lesz!

PrimeMark build 20100516.1
Használat:
java -jar PrimeMark.jar n [m]
n: feldolgozó szálak száma
m: feladatok száma magonként
Ha meg van adva akkor a számítás n*m részre lesz bontva.
Alapérték: 8 Érdemes növélni, ha a számítás végén túl sok
ideig maradnak munka nélkül feldolgozó szálak.


# java -jar PrimeMark.jar 14 16
...
  Preparation - El?készítés: 20ms
  Counting    - Megszámlálás: 633s

Processor Type: PowerPC_POWER7
Processor Implementation Mode: POWER 6
Processor Version: PV_6_Compat
Number Of Processors: 7
Processor Clock Speed: 3108 MHz
CPU Type: 64-bit

--
2e845cb4c3a5b5bd6508455b1739a8a2

( ssa2 v | 2010. 05. 16., v – 19:58 )

i7-860 gentoo x86_64

Előkészületek: 8ms
Számítás: 464s