[akosf]

Idézet: Freddy - Dátum: 2006. febr. 4., szombat - 12:21

Az optimalizalt 6800-7000 masodperc, az optimalizalatlan pedig 15000 korul volt. A results-nal meg is tudod nezni.
Windows alatt gyorsabb lenne?

Egy 1666MHz-es Athlon XP 2000+ Windows alatt a Crunch3r féle P3 SSE optimalizált klienssel olyan 5500-6500 sec/wu sebességgel ketyeg. Tehát gyorsabb lenne.

[Bucy]

Idézet: akosf - Dátum: 2006. febr. 4., szombat - 11:35

Gondolom te is tudod hogy a Cruch3r féle még sse optimalizációt is tartalmaz. Ha elárulod hogy milyen a mértékegységben adjam meg az eltérést akkor megpróbálom aszerint lemérni és megadni.

Engem az érdekelne csak, hogy a mérést végzõ részhez nyúltak-e, mondjuk durva példa: eredmény*1.6. A másik megoldás, hogy csak a számolást optimalizálták az rendelkezésre álló utasítások jobb kihasználásával.
Persze lehet hogy tök hülyeséget írok, mert nem ismerem a kódot hogy mûködik.

[Freddy]

akosf: ezen a linuxos gepen kimondottan athlonxp-re optimalizalt SSE kliens fut. Ezek szerint gyorsabb lenne rajta a p3-ra optimalizalt

[akosf]

Idézet: Bucy - Dátum: 2006. febr. 4., szombat - 13:21

Engem az érdekelne csak, hogy a mérést végzõ részhez nyúltak-e, mondjuk durva példa: eredmény*1.6. A másik megoldás, hogy csak a számolást optimalizálták az rendelkezésre álló utasítások jobb kihasználásával.

Kezdelek érteni, az eremény*1.6 bemondásod sokat segített ebben.
Az igazság az hogy a benchmark mérés legtöbb része nagyon "primitív" pl. néhány utasítást ismételget több ezerszer. Ezernyi módja van annak hogy jóval nagyobb eredeményt kapjál, nem kell ahhoz a szorzás.

Egyszerû példa:
Mondjuk egy 1024 elemû sinus/cosinus táblázat számítása. Mondjuk alapvetõen minden érték számításához kell egy összeadó (4 órajel) és egy sinus/cosinus számító utasítás (150 órajel).
Ugyanez a táblázat a sin(x+y)=sin(x)cos(y)+sin(y)cos(x); cos(x+y)=cos(x)cos(y)-sin(x)sin(y) képletek felhasználásával bonyolultabb módon is legenerálható. Minden értékhez kell 4 szorzás (16 órajel, de átalpolható) és 2 összeadás/kivonás (4 órajel, de átlapolható).

Látszik a különbség a két eljárás között. Az eredmény ugyanaz, de míg az elsõ kb. 158.000 órajel alatt hajtódik végre, addig a második kevesebb mint 10.000. Vagyis 16-szor gyorsabban.

Ebben nincs semmi "csalás", csak gyorsabb. Ráadásul ennél sokkal "primitívebb" dolgok is szerepelnek a benchmark tesztben.

Szerk.: Hogy van-e benne "szorzás" azt nem tudom, de ha érdekel elõáshatok egy mail címet...

Szerkesztette: akosf 2006. 02. 04. 12:49 -kor

[akosf]

Idézet: Freddy - Dátum: 2006. febr. 4., szombat - 13:32

akosf: ezen a linuxos gepen kimondottan athlonxp-re optimalizalt SSE kliens fut. Ezek szerint gyorsabb lenne rajta a p3-ra optimalizalt

Ha a forráskód ugyanaz, akkor az hogy ahtlonxp vagy p3 optimalizált a kód, nem sokat számít. Sokkal fontosabb hogy melyik forráskód a "fejlettebb" illetve hogy milyen fordítóval lett fordíva. Valószínûleg azért lassabb a linuxos kód mert akik azt a fordítót készítették kevesebbet törõdtek a sebességgel.

[Bucy]

Idézet: akosf - Dátum: 2006. febr. 4., szombat - 12:37

Ebben nincs semmi "csalás", csak gyorsabb. Ráadásul ennél sokkal "primitívebb" dolgok is szerepelnek a benchmark tesztben.

Nos innentõl adva van a feladat a berkeley-s fiúknak, hogy olyan benchmarkot írjanak amit nem lehet tovább optimalizálni. Mondjuk fogják a mostani legjobbat és berakják a következõ kiadásba.

[sibike]

Idézet: Bucy - Dátum: 2006. febr. 4., szombat - 12:57

Nos innentõl adva van a feladat a berkeley-s fiúknak, hogy olyan benchmarkot írjanak amit nem lehet tovább optimalizálni. Mondjuk fogják a mostani legjobbat és berakják a következõ kiadásba.

Talán jobb megoldás lenne, ha a project kliense végezné a mérést egy teszt wukival, mivel a gépek teljesitménye projectenként eltérõ (más tipusú számitások).

[Bucy]

Idézet: sibike - Dátum: 2006. febr. 4., szombat - 13:23

Talán jobb megoldás lenne, ha a project kliense végezné a mérést egy teszt wukival, mivel a gépek teljesitménye projectenként eltérõ (más tipusú számitások).

Akkor nem lenne értelme az összesített pontoknak.

[akosf]

Olyan kód nincs amit nem lehet tovább optimalizálni, vagy végtelen ideig tartana a fejlesztése. Csak olyan van amit már nagyon nehéz jobbítani, de az még mindig átverhetõ. Egy járható út az ha nem lenne a kód nyílt forráskódú és valamiféle önellenõrzéssel rendelkezne. Folyamatosan ellenõrizné a programkódot a memóriában, valamint az adatokat is. Úgy mint annak idején a seti classic esetén. Ott kb. percenként ellenõrizte magát is és az adatterületet is a program, és be is jegyezte az ellenõrzõ összeget az eredményfájlba. Ez azt jelentette hogy a következõ percben már az elõzõ ellenörzõ összeget is mint adatot belekalkulálta a következõbe. Sajnos az ott alkalmazott MD5-ös ciklikus önellenõrzõs sem elég az elvetemültek ellen, jómagam is feltörtem azt... de úgy rémlik rajtam kívül senkinek sem volt olyan optimalizált kódja ami közel 30%-kal gyorsabban futott.

Az is igaz hogy ha idõnként letöltõdne egy-egy referencia wu amivel központilag mérnék a gép sebességét, akkor csak az adott projekten belül lehetne összehasonlítani a gépeket.
De! Mi van ha lenne egy dedikált referencia gép amin minden projekthez megállapítanak egy-egy szorzó értéket. Ebben az esetben ez a gép biztosítaná az összevethetõséget a projektek közt. Itt az egyetlen kiskapu az lenne ha a "mókolt" kliens mindig nagyobb feldolgozási idõt jelentene, hiszen evvel nagyobb claimed credit is járna, és vele együtt a már általam felemlített credit többlet.

Mi lenne a megoldás? Felejtsük el az wu feldolgozási idõket is! Se benchmark érték, se cpu idõ. Na jó, de akkor hogyan lesz más projektekkel is összevethetõ pontszám? Egyszerû...
Felhasználjuk a fentebb említett referencia géprõl származó szorzó értéket (k), valamint megnézzük hogy "hány éves" a host (T) és az idõ alatt mennyi érvényes wu-t produkált (N). Ezekbõl egy egységesített, hostra jellemzõ teljesítmény értéket lehetne kapni. R=k*N/T

[Madárpók]

Letöltötem az SSE2 optimalizált kienst Akosf oldaláról és nagyon meglepõdtem. A normál kliens 4 óráig tökölt egy wukival,az optimalizált 1 óra alatt kivégezte.Konfigom:

Intel Pentium 4 2400 Mhz x86,MMX,SSE,SSE2 utasításkészletekkel
Abit BD7II
Intel Brookdale i845E lapkakészlet
512 MB PC2700 DDR SDRAM
NVIDIA GeForce FX5200 128 MB
LG Flatron F700B 17"
C-Media CMI8738/C3DX
Maxtor 6Y060L0 60GB 7200RPM Ultra-ATA/133
LG GCE-8520B CD-RW 52x/24x/52x CD-RW
Toshiba DVD-ROM SD-M1712 16x/48x DVD-ROM
Integrált Realtek RTL8139 családú PCI gyors Ethernet NIC
Agere Win FAX Modem
Canon Pixma IP1500
Windows XP Professional SP2-vel és az összes frissítéssel
DirectX 9.c
Windows Media Player 10

Szerkesztette: Madárpók 2006. 02. 04. 15:35 -kor

[sibike]

Idézet: akosf - Dátum: 2006. febr. 4., szombat - 15:16

Mi lenne a megoldás? Felejtsük el az wu feldolgozási idõket is! Se benchmark érték, se cpu idõ. Na jó, de akkor hogyan lesz más projektekkel is összevethetõ pontszám? Egyszerû...

És ha nem egyforma 'hosszúak' projecten belül a wukik, akkor mit csinálsz?

[akosf]

Idézet: sibike - Dátum: 2006. febr. 5., vasárnap - 12:33

És ha nem egyforma 'hosszúak' projecten belül a wukik, akkor mit csinálsz?

Azt valóban nem írtam le hogy a referenciagépen folyamatosan futna a az aktuális központi kliens.

Szerk.: Lehet hogy másra gondoltál. Elmagyaráznád?

Szerk.2: Azt hiszem felfogtam a kérdést. A módszer amit írtam nem alkalmas arra hogy egy wu alapján megmondja egy gép teljesítményét. Az is igaz, hogy másra lett kitalálva.

Szerkesztette: akosf 2006. 02. 05. 13:22 -kor

[sibike]

Idézet: akosf - Dátum: 2006. febr. 5., vasárnap - 13:13

Szerk.: Lehet hogy másra gondoltál. Elmagyaráznád?

Arra gondoltam, hogy projecten belül wukik  számitási ideje nem egyforma, tehát egy adott gép egy wukival végez 1,5h alatt, egy másikkal 3h alatt. A te számitási rendszeredben a 2 wu ugyanannyit ér, pedig az egyikkel 2szer annyit molyolt a a gép. Remélem most már világos a mit felvetettem.

Nem tudom, hogy van-e most ilyen project, amiben teljesen véletlenszerû egy wu futási ideje, de nem kellene kizárni azt a lehetõséget sem, hogy legyen ilyen.

[akosf]

Idézet: sibike - Dátum: 2006. febr. 5., vasárnap - 16:06

Arra gondoltam, hogy projecten belül wukik  számitási ideje nem egyforma, tehát egy adott gép egy wukival végez 1,5h alatt, egy másikkal 3h alatt. A te számitási rendszeredben a 2 wu ugyanannyit ér, pedig az egyikkel 2szer annyit molyolt a a gép. Remélem most már világos a mit felvetettem.

Nem jól látod a dolgot.

Ebben a számítási rendszerben átlagot számolunk és nem azt hogy egyik wuki ennyi pont, másik wuki annyi pont.

[sibike]

Idézet: akosf - Dátum: 2006. febr. 5., vasárnap - 15:59

Ebben a számítási rendszerben átlagot számolunk és nem azt hogy egyik wuki ennyi pont, másik wuki annyi pont.

R=k*N/T összefüggés alapján te az eltelt idõ alatt számolt wukikat nézed, de nem törödsz, a wuki hosszával, tehát aki rövidebb wukikat kap annak magasabb lesz az R, aki hosszabakat annak alacsonyabb, és "ez igy nem jó"

[akosf]

Idézet: sibike - Dátum: 2006. febr. 5., vasárnap - 17:11

R=k*N/T összefüggés alapján te az eltelt idõ alatt számolt wukikat nézed, de nem törödsz, a wuki hosszával, tehát aki rövidebb wukikat kap annak magasabb lesz az R, aki hosszabakat annak alacsonyabb, és "ez igy nem jó"

Tételezzük fel hogy a wukik fele hosszú, a másik fele rövid. Mennyi az esélye már 10 wuki után hogy mind rövid vagy mind hosszú volt? 0,0097%... 20 wuki után? 0,000095%...
Ha felrajzolsz egy eloszlási görbét meglátod hogy nagyon jól az átlag közelében fognak csoportosulni az értékek. Sõt, minél több wukit dolgozol fel, annál jobban. Szóval mégis csak jó...

Szerkesztette: akosf 2006. 02. 05. 16:53 -kor

[sibike]

   
Meg vagyok gyõzve.

Már csak azt találd ki, hogy a jelenlegi rendszerben lévõ krediteket hogyan lehet átszámolni az új rendszerbe.

És akkor indulhatunk a boinc-dev fórum/lisárara

[akosf]

Idézet: sibike - Dátum: 2006. febr. 5., vasárnap - 17:57

Már csak azt találd ki, hogy a jelenlegi rendszerben lévõ krediteket hogyan lehet átszámolni az új rendszerbe.

És akkor indulhatunk a boinc-dev fórum/lisárara

Szerintem sokkal inkább olyasmit kellene kitalálni mint amit te is felvetettél. Azaz magával a klienssel kellene valamiféle mérést végezni. De gõzöm sincs hogyan. A baj az hogy ha valami a gépeden fut akkor ott lehet csalni, és ha sok gépen fut, akkor elõbb-utóbb biztosan akad valaki aki meg is próbálja.

A boinc-os üzenõlisták meg nem tudnak tûzbe hozni. Pl. múltkor jeleztem a sztaki listán hogy elég könnyû átverni a kliensprogramot, így könnyen lehet bezsebelni a krediteket, közben meg tönkreteszed a tudományos munkát. Azóta is láttam olyan eredményeket amelyek meglehetõsen csalafinták. Persze nem gyógyítottak még semmit a kódon. A PrimeGrid-es csapatnak is jeleztem hogy a ciklusmagban (a fordító hibájából?) az összes osztás felesleges szerepel duplán és kb. 30-40%-kal visszafogja a kliens teljesítményét (így feleslegesen fûtik a bolygót).

[Oliver & Jaszka]

Idézet: Bucy - Dátum: 2006. jan. 18., szerda - 14:08

Errõl jut eszembe, nem nagyon szaporodunk a Rosetta csapatban.

Már 3-an vagyunk!     

Rosetta csapat

[Bucy]

Idézet: Oliver & Jaszka - Dátum: 2006. febr. 6., hétfõ - 12:13

Már 3-an vagyunk!     

Rosetta csapat

A régiek közül senki nem jött át, nem is jelentkezett, nem tudom kik lehetnek azok és hogy keveredtek a csapatba. Szerintem itt nem olvasnak, tán még a hwsw-re se járnak, stat-okat se nagyon böngészhetnek.