A neten koszalgatva az ember bele-bele fut egy-ket olyan postba, hogy CFLAGS igy meg ugy, vagy icc igy meg ugy. Na. Mivel nehanyan tevhiedelmek kozt vannak ill. elfogultak egyik vagy masik iranyba, gondoltam, csinalok nehany home benchmarkot, hogy kideritsuk mi az igazsag. A teszt celja, hogy a ket fordito kozti elterest vizsgalja ill. az egyes flagek hasznalatara nyers szamitas eseten, hogy reagalnak az egyes compilerek.
Idom szukeben nem nagyon volt idom vacakolni a reszletetkkel, grafikonokkal, igy inkabb topic lesz belole mint hir, tehat a szakmaisagot most kicsit felszinesen kezeljuk. :)
Bocsi ezert erzekeny lelekkel rendelkezo kollegak! :wink:
A tesztgep egy HP Omnibook XE4400 gep.
[code:1:faf0e076bc]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.00GHz
stepping : 4
cpu MHz : 2000.116
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4003.63
# uname -r
2.6.14-gentoo-r2[/code:1:faf0e076bc]
A tobbi adat valojaban nem jatszik kozre, mivel a teszt programunk egy egyszeru primszam generator ami I/O muveleteket szelesen melloz, az effektiv memoria hasznalata max. 100 byte.
A program kizarolag osztasi es gyokvonasi muveleteket hasznal a szamitasoknal, valamint erteknovelest az egyes ciklusoknal. Osszesen ket for ciklus es ket elagazas szerepel benne kulonosebb sallang nelkul. Vizsgalati tartomanya 3 - 10 000 000.
A meresre a time programot hasznaljuk, vagyis az indulastol a program befejezteig eltelt idot fogja merni, ami azt jelenti, hogy a nagyobb szam rosszabb teljesitmenyt jelent.
Vagjunk a kozepebe
Az elsonel kiirom rendesen az osszes outputot, de a tobbinel mar roviditek es a lenyeget hagyom csak meg.
GCC-3.4.4
[code:1:faf0e076bc]# gcc primeseek_div.c -lm -o primeseek_div
# time ./primeseek_div
real 0m32.613s
user 0m32.370s
sys 0m0.040s
# gcc primeseek_div.c -march=i386 -lm -o primeseek_div
real 0m32.345s
user 0m32.220s
# gcc primeseek_div.c -march=i486 -lm -o primeseek_div
real 0m32.603s
user 0m32.420s
# gcc primeseek_div.c -march=i586 -lm -o primeseek_div
real 0m32.371s
user 0m32.290s
# gcc primeseek_div.c -march=i686 -lm -o primeseek_div
real 0m33.364s
user 0m33.270s
# gcc primeseek_div.c -march=pentium3 -lm -o primeseek_div
real 0m33.511s
user 0m33.330s
# gcc primeseek_div.c -march=pentium4 -lm -o primeseek_div
real 0m33.917s
user 0m33.600s
# icc primeseek_div.c -O3 -lm -o primeseek_div
real 0m18.858s
user 0m18.820s
# icc primeseek_div.c -march=i386 -O3 -lm -o primeseek_div
real 0m18.821s
user 0m18.790s
# icc primeseek_div.c -march=i486 -O3 -lm -o primeseek_div
real 0m19.050s
user 0m18.790s
# icc primeseek_div.c -march=i586 -O3 -lm -o primeseek_div
real 0m19.727s
user 0m19.010s
# icc primeseek_div.c -march=i686 -O3 -lm -o primeseek_div
real 0m20.748s
user 0m20.550s
# icc primeseek_div.c -march=pentium3 -O3 -lm -o primeseek_div
real 0m20.109s
user 0m20.050s
# icc primeseek_div.c -march=pentium4 -O3 -lm -o primeseek_div
real 0m20.032s
user 0m20.010s[/code:1:faf0e076bc]
Na, ahogy en elneztem szulettek itt-ott erdekes ellentmondasok. Ezt megtovabb fokozva, ha a egy masik algoritmust teszteltem volna megint meroben mas eredmenyek szulettek volna ellentmondasban meg ezekkel is.
Probaltam a -fomit-frame-pointer ,-ffast-math es egyeb nyalanksagokat, volt amelyik egy-ket szazalekot javitott, volt amelyik ugyanennyit rontott. Volt termeszetesen valtozatlan eredmeny is.
Meg csak annyit megjegyzeskent, hogy korabban keszitettem mencoder-rel teszteket, a -march beallitasoknak ott volt nemi jelentosege, de ott is szulettek ellentmondasos ertekek.
Probalkoztam a -Os kapcsoloval is a fenti tesztnel, nem mutatott jelentos kulonbseget a -O2 -tol.
[quote:c4af5ff7b4="rigidus"]A tobbi adat valojaban nem jatszok kozre, mivel a teszt programunk egy egyszeru primszam generator ami I/O muveleteket szelesen melloz, az effektiv memoria hasznalata max. 100 byte.
A program kizarolag osztasi es gyokvonasi muveleteket hasznal a szamitasoknal, valamint erteknovelest az egyes ciklusoknal. Osszesen ket for ciklus es ket elagazas szerepel benne kulonosebb sallang nelkul. Vizsgalati tartomanya 3 - 10 000 000.
még érdekesebb eredményekre juthatnál, hogy ha több esélyt adva az architektúráknak, bonyolultabb kódot használnál. itt lehetséges, hogy az idő nagy részét az `sqrt(3)' -ben töltöd (gprof mit mond?). ki kéne próbálni struktúrákkal, azok tömbjeivel és tömbparancsokkal is. mondjuk vmi sort-szerűvel, megspékelve lebegőponttal. hajrá :)
[quote:27c6df8363="kr304"][quote:27c6df8363="rigidus"]A tobbi adat valojaban nem jatszok kozre, mivel a teszt programunk egy egyszeru primszam generator ami I/O muveleteket szelesen melloz, az effektiv memoria hasznalata max. 100 byte.
A program kizarolag osztasi es gyokvonasi muveleteket hasznal a szamitasoknal, valamint erteknovelest az egyes ciklusoknal. Osszesen ket for ciklus es ket elagazas szerepel benne kulonosebb sallang nelkul. Vizsgalati tartomanya 3 - 10 000 000.
még érdekesebb eredményekre juthatnál, hogy ha több esélyt adva az architektúráknak, bonyolultabb kódot használnál. itt lehetséges, hogy az idő nagy részét az `sqrt(3)' -ben töltöd (gprof mit mond?). ki kéne próbálni struktúrákkal, azok tömbjeivel és tömbparancsokkal is. mondjuk vmi sort-szerűvel, megspékelve lebegőponttal. hajrá :)
:D Koszi a biztatast.
Nem a benchmark kedveert irtam a kodot hanem cel erdekeben: primszamok keresesere. Igazabol a teszt azert jutott eszembe, mert az eddigi kod memoriaigenye csak par bajt es igy elegge szembetunoen megmutatkozhat, hogy az algoritmus magja I/O muveletektol mentesen, hogyan reagal az egyes forditokra, flagekre.
Termeszetesen a kod tovabb lesz irva es joval tobb I/O muvelet lesz benne, valamint implementalva lesz MPI support is.
Na akkor viszont csinalok reszletesebb teszteket es bevonok mas OS-eket is. :D
BTW gprof ez mit csinal pontosan? Eppen nezem a manjat de valahogy nem vilagos.
[quote:06bf392488="rigidus"]Nem a benchmark kedveert irtam a kodot hanem cel erdekeben: primszamok keresesere.
Termeszetesen a kod tovabb lesz irva es joval tobb I/O muvelet lesz benne, valamint implementalva lesz MPI support is.
Akkor van még mit javítani rajta, kár lenne a klaszterért ;) [pl. sqrt minek stb]
[quote:06bf392488="rigidus"]
BTW gprof ez mit csinal pontosan? Eppen nezem a manjat de valahogy nem vilagos.
Statisztikát, hogy melyik függvényben mennyi időt tölt a processz, így tudod, melyik a szűk keresztmetszet.
[quote:f8e1319660="kr304"][quote:f8e1319660="rigidus"]Nem a benchmark kedveert irtam a kodot hanem cel erdekeben: primszamok keresesere.
Termeszetesen a kod tovabb lesz irva es joval tobb I/O muvelet lesz benne, valamint implementalva lesz MPI support is.
Akkor van még mit javítani rajta, kár lenne a klaszterért ;) [pl. sqrt minek stb]
[quote:f8e1319660="rigidus"]
BTW gprof ez mit csinal pontosan? Eppen nezem a manjat de valahogy nem vilagos.
Statisztikát, hogy melyik függvényben mennyi időt tölt a processz, így tudod, melyik a szűk keresztmetszet.
Allandoan a gprof parameterekent adtam meg a progit, de nem jott ossze. Aztan kozbe agyaltam, hogy hogy a banatba fogja ez a statisztikat kesziteni, ha le sem fut, valahogy nem volt logikus. Neten kutakodtam es rajottem, hogy mi a hianyzo lancszem :D "Once the program is compiled for profiling, you must run it in order to generate the information that gprof needs"
sqrt: gyokot vonok az osztandobol es az osztoval csak a gyok egesz ertekeig megyek. (utana mar ugy tok felesleges keresni :) )
Amugy pontosan (10 000 000 * 8 / 10 / 2)-szer von gyokot vagyis kereken 4 milla. :D
Ez egyebkent ideiglenes megoldas, egyenlore csak akartam kesziteni egy algoritmust amivel a sajatom szamitasanak a hitelesseget tesztelhetem. Igaz erre van egy eratoszthenesz szitam is, csak valahova ugy elastam az egyik hdd melyere. Pedig az veszett gyors es az lenne az igazi az ellenorzeshez. :)
[quote:b0a1f21ea0="kamm"]esetleg meg:
-msse2 -mfpmath=sse
vagy probald meg a zalgoritmust te kezzel megirni MMX/SSE utasitasokkal.
DIVPS/DIVSS, SQRTPS/SQRTSS instrukciok hasznosak lehetnek.
SSE support az benne van a -march=i686 felett automatikusan ha jol emlekszem. Mar probaltam kulon is, de kb 4-5% veszteseggel jott ki. Alakul, de azert meg van mit csiszolni. :wink:
[quote:192fdbeb63="rigidus"]sqrt: gyokot vonok az osztandobol es az osztoval csak a gyok egesz ertekeig megyek. (utana mar ugy tok felesleges keresni :) )
amellett, h az időt nagyságrenddel növeli, felesleges az sqrt(), nem írom le miért, mert általános iskolás matematika :) viszont így legalább lenne benne lebegőpontos aritmetika is, ha a libm könyvtárat is forgatnád ;)
[quote:192fdbeb63="rigidus"]Ez egyebkent ideiglenes megoldas
az más, csak azt hittem, erre használsz egy egész gridet ;)
(közben kipróbáltam a gprofot, és egy Solarison gond nélkül megy, a Debianon meg nem, nem értem, na mind1: gprof: gmon.out file is missing call-graph data)
[quote:ce636d1066="kr304"]felesleges az sqrt(), nem írom le miért, mert általános iskolás matematika :)felesleges az sqrt(), nem írom le miért, mert általános iskolás matematika :)
Ne aggodj, tudom mirol van szo, csak lutta vagyok. :D
A kesz algoritmus nem igy fog mukodni. Egy eddigiektol eltero modon fog mukodni, a talalt szamok pedig sql-be mennek.
[quote:ce636d1066="kr304"]gprof: gmon.out file is missing call-graph data)
Add hozza a -Q kapcsolot. en is ezzel szivtam egy negyed orat. :D
Inline fuggvenyeket nem szereti meg akkor sem, ha nem hagyom, hogy a fordito figyelembe vegye. Ugyh most kikapcsoltam mind a 4 inline fuggvenyt ill. az sqrt-t is beletettem egy ideiglenes fuggvenybe, hogy le tudja merni mennyit vacakol vele. Bar, azt gondolom, h sokat mivel korabban a gprof elott is mar meregettem, de igy talan kenyelmesebb. :)
Hozzászólások
Sziasztok,
A neten koszalgatva az ember bele-bele fut egy-ket olyan postba, hogy CFLAGS igy meg ugy, vagy icc igy meg ugy. Na. Mivel nehanyan tevhiedelmek kozt vannak ill. elfogultak egyik vagy masik iranyba, gondoltam, csinalok nehany home benchmarkot, hogy kideritsuk mi az igazsag. A teszt celja, hogy a ket fordito kozti elterest vizsgalja ill. az egyes flagek hasznalatara nyers szamitas eseten, hogy reagalnak az egyes compilerek.
Idom szukeben nem nagyon volt idom vacakolni a reszletetkkel, grafikonokkal, igy inkabb topic lesz belole mint hir, tehat a szakmaisagot most kicsit felszinesen kezeljuk. :)
Bocsi ezert erzekeny lelekkel rendelkezo kollegak! :wink:
A tesztgep egy HP Omnibook XE4400 gep.
[code:1:faf0e076bc]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.00GHz
stepping : 4
cpu MHz : 2000.116
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4003.63
# uname -r
2.6.14-gentoo-r2[/code:1:faf0e076bc]
A tobbi adat valojaban nem jatszik kozre, mivel a teszt programunk egy egyszeru primszam generator ami I/O muveleteket szelesen melloz, az effektiv memoria hasznalata max. 100 byte.
A program kizarolag osztasi es gyokvonasi muveleteket hasznal a szamitasoknal, valamint erteknovelest az egyes ciklusoknal. Osszesen ket for ciklus es ket elagazas szerepel benne kulonosebb sallang nelkul. Vizsgalati tartomanya 3 - 10 000 000.
A meresre a time programot hasznaljuk, vagyis az indulastol a program befejezteig eltelt idot fogja merni, ami azt jelenti, hogy a nagyobb szam rosszabb teljesitmenyt jelent.
Vagjunk a kozepebe
Az elsonel kiirom rendesen az osszes outputot, de a tobbinel mar roviditek es a lenyeget hagyom csak meg.
GCC-3.4.4
[code:1:faf0e076bc]# gcc primeseek_div.c -lm -o primeseek_div
# time ./primeseek_div
real 0m32.613s
user 0m32.370s
sys 0m0.040s
# gcc primeseek_div.c -march=i386 -lm -o primeseek_div
real 0m32.345s
user 0m32.220s
# gcc primeseek_div.c -march=i486 -lm -o primeseek_div
real 0m32.603s
user 0m32.420s
# gcc primeseek_div.c -march=i586 -lm -o primeseek_div
real 0m32.371s
user 0m32.290s
# gcc primeseek_div.c -march=i686 -lm -o primeseek_div
real 0m33.364s
user 0m33.270s
# gcc primeseek_div.c -march=pentium3 -lm -o primeseek_div
real 0m33.511s
user 0m33.330s
# gcc primeseek_div.c -march=pentium4 -lm -o primeseek_div
real 0m33.917s
user 0m33.600s
------------------------------------------------------
# gcc primeseek_div.c -O1 -lm -o primeseek_div
real 0m21.191s
user 0m21.150s
# gcc primeseek_div.c -march=i386 -O1 -lm -o primeseek_div
real 0m25.016s
user 0m24.870s
# gcc primeseek_div.c -march=i486 -O1 -lm -o primeseek_div
real 0m32.833s
user 0m32.720s
# gcc primeseek_div.c -march=i586 -O1 -lm -o primeseek_div
real 0m35.635s
user 0m35.600s
# gcc primeseek_div.c -march=i686 -O1 -lm -o primeseek_div
real 0m27.494s
user 0m26.730s
# gcc primeseek_div.c -march=pentium3 -O1 -lm -o primeseek_div
real 0m25.549s
user 0m25.340s
# gcc primeseek_div.c -march=pentium4 -O1 -lm -o primeseek_div
real 0m25.652s
user 0m25.360s
------------------------------------------------------
# gcc primeseek_div.c -O2 -lm -o primeseek_div
real 0m21.168s
user 0m21.130s
# gcc primeseek_div.c -march=i386 -O2 -lm -o primeseek_div
real 0m24.991s
user 0m24.710s
# gcc primeseek_div.c -march=i486 -O2 -lm -o primeseek_div
real 0m32.304s
user 0m32.250s
# gcc primeseek_div.c -march=i586 -O2 -lm -o primeseek_div
real 0m32.904s
user 0m32.540s
# gcc primeseek_div.c -march=i686 -O2 -lm -o primeseek_div
real 0m22.354s
user 0m22.150s
# gcc primeseek_div.c -march=pentium3 -O2 -lm -o primeseek_div
real 0m23.193s
user 0m22.320s
# gcc primeseek_div.c -march=pentium4 -O2 -lm -o primeseek_div
real 0m23.466s
user 0m22.360s
------------------------------------------------------
# gcc primeseek_div.c -O3 -lm -o primeseek_div
real 0m21.185s
user 0m21.160s
# gcc primeseek_div.c -march=i386 -O3 -lm -o primeseek_div
real 0m24.808s
user 0m24.660s
# gcc primeseek_div.c -march=i486 -O3 -lm -o primeseek_div
real 0m35.723s
user 0m35.680s
# gcc primeseek_div.c -march=i586 -O3 -lm -o primeseek_div
real 0m41.495s
user 0m41.310s
# gcc primeseek_div.c -march=i686 -O3 -lm -o primeseek_div
real 0m21.749s
user 0m21.730s
# gcc primeseek_div.c -march=pentium3 -O3 -lm -o primeseek_div
real 0m22.062s
user 0m21.190s
# gcc primeseek_div.c -march=pentium4 -O3 -lm -o primeseek_div
real 0m21.267s
user 0m21.210s[/code:1:faf0e076bc]
ICC-9.0
[code:1:faf0e076bc]# icc primeseek_div.c -lm -o primeseek_div
real 0m19.517s
user 0m18.860s
# icc primeseek_div.c -march=i386 -lm -o primeseek_div
real 0m19.019s
user 0m18.930s
# icc primeseek_div.c -march=i486 -lm -o primeseek_div
real 0m19.548s
user 0m18.710s
# icc primeseek_div.c -march=i586 -lm -o primeseek_div
real 0m19.001s
user 0m18.750s
# icc primeseek_div.c -march=i686 -lm -o primeseek_div
real 0m19.146s
user 0m18.870s
# icc primeseek_div.c -march=pentium3 -lm -o primeseek_div
real 0m20.967s
user 0m20.120s
# icc primeseek_div.c -march=pentium4 -lm -o primeseek_div
real 0m20.180s
user 0m20.040s
------------------------------------------------------
# icc primeseek_div.c -O1 -lm -o primeseek_div
real 0m19.372s
user 0m19.330s
# icc primeseek_div.c -march=i386 -O1 -lm -o primeseek_div
real 0m19.293s
user 0m19.250s
# icc primeseek_div.c -march=i486 -O1 -lm -o primeseek_div
real 0m19.272s
user 0m19.250s
# icc primeseek_div.c -march=i586 -O1 -lm -o primeseek_div
real 0m19.287s
user 0m19.240s
# icc primeseek_div.c -march=i686 -O1 -lm -o primeseek_div
real 0m19.471s
user 0m19.260s
# icc primeseek_div.c -march=pentium3 -O1 -lm -o primeseek_div
real 0m21.276s
user 0m20.020s
# icc primeseek_div.c -march=pentium4 -O1 -lm -o primeseek_div
real 0m20.185s
user 0m20.150s
------------------------------------------------------
# icc primeseek_div.c -march=i386 -O2 -lm -o primeseek_div
real 0m19.306s
user 0m18.870s
# icc primeseek_div.c -march=i486 -O2 -lm -o primeseek_div
real 0m18.956s
user 0m18.810s
# icc primeseek_div.c -march=i586 -O2 -lm -o primeseek_div
real 0m18.933s
user 0m18.850s
# icc primeseek_div.c -march=i686 -O2 -lm -o primeseek_div
real 0m18.898s
user 0m18.870s
# icc primeseek_div.c -march=pentium3 -O2 -lm -o primeseek_div
real 0m20.236s
user 0m20.080s
# icc primeseek_div.c -march=pentium4 -O2 -lm -o primeseek_div
real 0m20.242s
user 0m20.040s
------------------------------------------------------
# icc primeseek_div.c -O3 -lm -o primeseek_div
real 0m18.858s
user 0m18.820s
# icc primeseek_div.c -march=i386 -O3 -lm -o primeseek_div
real 0m18.821s
user 0m18.790s
# icc primeseek_div.c -march=i486 -O3 -lm -o primeseek_div
real 0m19.050s
user 0m18.790s
# icc primeseek_div.c -march=i586 -O3 -lm -o primeseek_div
real 0m19.727s
user 0m19.010s
# icc primeseek_div.c -march=i686 -O3 -lm -o primeseek_div
real 0m20.748s
user 0m20.550s
# icc primeseek_div.c -march=pentium3 -O3 -lm -o primeseek_div
real 0m20.109s
user 0m20.050s
# icc primeseek_div.c -march=pentium4 -O3 -lm -o primeseek_div
real 0m20.032s
user 0m20.010s[/code:1:faf0e076bc]
Na, ahogy en elneztem szulettek itt-ott erdekes ellentmondasok. Ezt megtovabb fokozva, ha a egy masik algoritmust teszteltem volna megint meroben mas eredmenyek szulettek volna ellentmondasban meg ezekkel is.
Probaltam a -fomit-frame-pointer ,-ffast-math es egyeb nyalanksagokat, volt amelyik egy-ket szazalekot javitott, volt amelyik ugyanennyit rontott. Volt termeszetesen valtozatlan eredmeny is.
Meg csak annyit megjegyzeskent, hogy korabban keszitettem mencoder-rel teszteket, a -march beallitasoknak ott volt nemi jelentosege, de ott is szulettek ellentmondasos ertekek.
Probalkoztam a -Os kapcsoloval is a fenti tesztnel, nem mutatott jelentos kulonbseget a -O2 -tol.
Szerk: lemaradt ket teszt, potoltam oket.
[quote:c4af5ff7b4="rigidus"]A tobbi adat valojaban nem jatszok kozre, mivel a teszt programunk egy egyszeru primszam generator ami I/O muveleteket szelesen melloz, az effektiv memoria hasznalata max. 100 byte.
A program kizarolag osztasi es gyokvonasi muveleteket hasznal a szamitasoknal, valamint erteknovelest az egyes ciklusoknal. Osszesen ket for ciklus es ket elagazas szerepel benne kulonosebb sallang nelkul. Vizsgalati tartomanya 3 - 10 000 000.
még érdekesebb eredményekre juthatnál, hogy ha több esélyt adva az architektúráknak, bonyolultabb kódot használnál. itt lehetséges, hogy az idő nagy részét az `sqrt(3)' -ben töltöd (gprof mit mond?). ki kéne próbálni struktúrákkal, azok tömbjeivel és tömbparancsokkal is. mondjuk vmi sort-szerűvel, megspékelve lebegőponttal. hajrá :)
[quote:27c6df8363="kr304"][quote:27c6df8363="rigidus"]A tobbi adat valojaban nem jatszok kozre, mivel a teszt programunk egy egyszeru primszam generator ami I/O muveleteket szelesen melloz, az effektiv memoria hasznalata max. 100 byte.
A program kizarolag osztasi es gyokvonasi muveleteket hasznal a szamitasoknal, valamint erteknovelest az egyes ciklusoknal. Osszesen ket for ciklus es ket elagazas szerepel benne kulonosebb sallang nelkul. Vizsgalati tartomanya 3 - 10 000 000.
még érdekesebb eredményekre juthatnál, hogy ha több esélyt adva az architektúráknak, bonyolultabb kódot használnál. itt lehetséges, hogy az idő nagy részét az `sqrt(3)' -ben töltöd (gprof mit mond?). ki kéne próbálni struktúrákkal, azok tömbjeivel és tömbparancsokkal is. mondjuk vmi sort-szerűvel, megspékelve lebegőponttal. hajrá :)
:D Koszi a biztatast.
Nem a benchmark kedveert irtam a kodot hanem cel erdekeben: primszamok keresesere. Igazabol a teszt azert jutott eszembe, mert az eddigi kod memoriaigenye csak par bajt es igy elegge szembetunoen megmutatkozhat, hogy az algoritmus magja I/O muveletektol mentesen, hogyan reagal az egyes forditokra, flagekre.
Termeszetesen a kod tovabb lesz irva es joval tobb I/O muvelet lesz benne, valamint implementalva lesz MPI support is.
Na akkor viszont csinalok reszletesebb teszteket es bevonok mas OS-eket is. :D
BTW gprof ez mit csinal pontosan? Eppen nezem a manjat de valahogy nem vilagos.
[quote:06bf392488="rigidus"]Nem a benchmark kedveert irtam a kodot hanem cel erdekeben: primszamok keresesere.
Termeszetesen a kod tovabb lesz irva es joval tobb I/O muvelet lesz benne, valamint implementalva lesz MPI support is.
Akkor van még mit javítani rajta, kár lenne a klaszterért ;) [pl. sqrt minek stb]
[quote:06bf392488="rigidus"]
BTW gprof ez mit csinal pontosan? Eppen nezem a manjat de valahogy nem vilagos.
Statisztikát, hogy melyik függvényben mennyi időt tölt a processz, így tudod, melyik a szűk keresztmetszet.
esetleg meg:
-msse2 -mfpmath=sse
vagy probald meg a zalgoritmust te kezzel megirni MMX/SSE utasitasokkal.
DIVPS/DIVSS, SQRTPS/SQRTSS instrukciok hasznosak lehetnek.
[quote:f8e1319660="kr304"][quote:f8e1319660="rigidus"]Nem a benchmark kedveert irtam a kodot hanem cel erdekeben: primszamok keresesere.
Termeszetesen a kod tovabb lesz irva es joval tobb I/O muvelet lesz benne, valamint implementalva lesz MPI support is.
Akkor van még mit javítani rajta, kár lenne a klaszterért ;) [pl. sqrt minek stb]
[quote:f8e1319660="rigidus"]
BTW gprof ez mit csinal pontosan? Eppen nezem a manjat de valahogy nem vilagos.
Statisztikát, hogy melyik függvényben mennyi időt tölt a processz, így tudod, melyik a szűk keresztmetszet.
Allandoan a gprof parameterekent adtam meg a progit, de nem jott ossze. Aztan kozbe agyaltam, hogy hogy a banatba fogja ez a statisztikat kesziteni, ha le sem fut, valahogy nem volt logikus. Neten kutakodtam es rajottem, hogy mi a hianyzo lancszem :D
"Once the program is compiled for profiling, you must run it in order to generate the information that gprof needs"
sqrt: gyokot vonok az osztandobol es az osztoval csak a gyok egesz ertekeig megyek. (utana mar ugy tok felesleges keresni :) )
Amugy pontosan (10 000 000 * 8 / 10 / 2)-szer von gyokot vagyis kereken 4 milla. :D
Ez egyebkent ideiglenes megoldas, egyenlore csak akartam kesziteni egy algoritmust amivel a sajatom szamitasanak a hitelesseget tesztelhetem. Igaz erre van egy eratoszthenesz szitam is, csak valahova ugy elastam az egyik hdd melyere. Pedig az veszett gyors es az lenne az igazi az ellenorzeshez. :)
[quote:b0a1f21ea0="kamm"]esetleg meg:
-msse2 -mfpmath=sse
vagy probald meg a zalgoritmust te kezzel megirni MMX/SSE utasitasokkal.
DIVPS/DIVSS, SQRTPS/SQRTSS instrukciok hasznosak lehetnek.
SSE support az benne van a -march=i686 felett automatikusan ha jol emlekszem. Mar probaltam kulon is, de kb 4-5% veszteseggel jott ki. Alakul, de azert meg van mit csiszolni. :wink:
[quote:192fdbeb63="rigidus"]sqrt: gyokot vonok az osztandobol es az osztoval csak a gyok egesz ertekeig megyek. (utana mar ugy tok felesleges keresni :) )
amellett, h az időt nagyságrenddel növeli, felesleges az sqrt(), nem írom le miért, mert általános iskolás matematika :) viszont így legalább lenne benne lebegőpontos aritmetika is, ha a libm könyvtárat is forgatnád ;)
[quote:192fdbeb63="rigidus"]Ez egyebkent ideiglenes megoldas
az más, csak azt hittem, erre használsz egy egész gridet ;)
(közben kipróbáltam a gprofot, és egy Solarison gond nélkül megy, a Debianon meg nem, nem értem, na mind1: gprof: gmon.out file is missing call-graph data)
[quote:ce636d1066="kr304"]felesleges az sqrt(), nem írom le miért, mert általános iskolás matematika :)felesleges az sqrt(), nem írom le miért, mert általános iskolás matematika :)
Ne aggodj, tudom mirol van szo, csak lutta vagyok. :D
A kesz algoritmus nem igy fog mukodni. Egy eddigiektol eltero modon fog mukodni, a talalt szamok pedig sql-be mennek.
[quote:ce636d1066="kr304"]gprof: gmon.out file is missing call-graph data)
Add hozza a -Q kapcsolot. en is ezzel szivtam egy negyed orat. :D
[quote:200353f861="rigidus"][quote:200353f861="kr304"]gprof: gmon.out file is missing call-graph data)
Add hozza a -Q kapcsolot. en is ezzel szivtam egy negyed orat. :D
Hú kösz, így ment, de kíváncsi voltam a call-graph-ra. aztán rájöttem, hogy a hellowörldben lehet h nincs is, és másra tényleg működik :)
Inline fuggvenyeket nem szereti meg akkor sem, ha nem hagyom, hogy a fordito figyelembe vegye. Ugyh most kikapcsoltam mind a 4 inline fuggvenyt ill. az sqrt-t is beletettem egy ideiglenes fuggvenybe, hogy le tudja merni mennyit vacakol vele. Bar, azt gondolom, h sokat mivel korabban a gprof elott is mar meregettem, de igy talan kenyelmesebb. :)