PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Optimierte MilkyWay@home Applikation



Seiten : [1] 2 3 4 5 6 7 8 9 10

Twodee
04.12.2008, 15:53
Edit: Ich füge hier mal die Links für die jeweils aktuellen MW-Anwendungen ein.

Normale Anwendung für x87/SSE/2/3/4.1/SSSE3 (http://www.file-upload.net/download-1408307/Milkyway_0.16.zip.html)

ATI GPU-App (http://www.file-upload.net/download-1432871/Milkyway_0.17_ATI_SSE3_x64.zip.html)
Die GPU-App läuft momentan nur unter Win64 auf ATI Radeon HD38x0 und HD48x0 Karten mit den Catalyst 8.12 oder 9.1.


*update*

TiKu
04.12.2008, 15:57
5. meine Version setzt die Microsoft .NET Framework Version 2.0 voraus.Huh? Wozu verwendest du das denn?

gruenmuckel
04.12.2008, 16:15
Ich habe mal wieder eine optimierte Version der 0.6 x32 App gebastelt:

1. Fehlerbereinigt, d.h. keine Speicherleaks mehr
2. hier und da optimiert. Faktor 3,1 gegenüber der (optimierten *chatt*) Standard 06-App bezogen auf einem Q6600@2.95GHz
3. Kein Support für x64 sowie SSE(x)
4. Alles was schneller als ein Core mit 2.36Ghz ist, wird Creditmäßig wieder limitiert. [maximal 10.4K pro Tag für einen Quad ist möglich]
5. meine Version setzt die Microsoft .NET Framework Version 2.0 voraus.

Soll ich sie P3D zur Verfügung stellen?
Also ich hätte sie schon gerne.

indiana_74
04.12.2008, 16:16
Ich habe mal wieder eine optimierte Version der 0.6 x32 App gebastelt:

1. Fehlerbereinigt, d.h. keine Speicherleaks mehr
2. hier und da optimiert. Faktor 3,1 gegenüber der (optimierten *chatt*) Standard 06-App bezogen auf einem Q6600@2.95GHz
3. Kein Support für x64 sowie SSE(x)
4. Alles was schneller als ein Core mit 2.36Ghz ist, wird Creditmäßig wieder limitiert. [maximal 10.4K pro Tag für einen Quad ist möglich]
5. meine Version setzt die Microsoft .NET Framework Version 2.0 voraus.

Soll ich sie P3D zur Verfügung stellen?


nichts dagegen

Fränki´s Welle
04.12.2008, 16:19
Wie lange wird man mit dieser Version arbeiten können? Jetzt ist die Version 07 draußen.*noahnung*

JKuehl
04.12.2008, 16:20
immer raus damit. Das wird jetzt so lange zelebriert bis das Projekt halbwegs realistische Optimierungen eingebaut hat ;-)

ps: hast du auch ein für Linux gebaut? Wenn nicht frag mal Gipsel der dürfte das ja hinbekommen - hab ihm bei der alten Version dabei ja geholfen, sonst an mich dann bau ich die ;-)

pps: endlich scheint das Internet wieder zu gehen - fast 3 Tage ohne Netz nur ab und an mal sporadisch und dann auch 98% aller DNS-Anfragen ins Leere....8-( Fast sind mir die Bunker leergelaufen hab aber grade aufgefüllt ;-)

DerRob
04.12.2008, 16:20
3. Kein Support für x64 sowie SSE(x)
laufen tuts aber schon auf einem x64-system, oder? ???

Gipsel
04.12.2008, 16:22
Huh? Wozu verwendest du das denn?
Wahrscheinlich meldet sich die App bei Twodees Stats-Seite an. Dann kann er die für jeden einzeln auch wieder deaktivieren. Trusted Computing läßt grüßen *suspect* *lol*

Außerdem kann doch wahrscheinlich auch eine C# JIT-kompilierte Version performancemäßig mithalten :]

Edit: Ich füge hier mal die Links für die jeweils aktuellen MW-Anwendungen ein.

Normale Anwendung für x87/SSE/2/3/4.1/4.2/SSSE3, Version 0.19 (http://www.file-upload.net/download-1460468/Milkyway_0.19.zip.html)
Neue Features: CPU-Erkennung und Ausgabe der Crunchzeiten (CPU-Zeit und Realzeit) unter Task-Details.
Performance identisch zu früheren Versionen.

ATI GPU-App Version 0.19d (http://www.file-upload.net/download-1491628/Milkyway_0.19d_ATI.zip.html)
Letzte Version der ATI-App mit neuem (noch experimentellem) Scheduling-System, welches Multi-GPU-Unterstützung sowie geringere CPU-Last ermöglicht. Sonst gleich zu 0.19b. Bitte die readme.txt lesen!

ATI GPU-App Version 0.19b (http://www.file-upload.net/download-1485837/Milkyway_0.19b_ATI.zip.html)
Neue Version der ATI-App mit den zusätzlichen Features der 0.19 CPU-Version sowie eingebauter GPU-Erkennung (ebenfalls unter Task details auf der MW-Seite einsehbar). Läuft unter Win32 (CPU mit SSE2 erforderlich) und Win64. Erfordert eine HD3800er oder HD4800er Karte mit Cat8.12 oder 9.1. Mit Cat 9.2 müssen die atical*.dll im Windows\system32 Ordner dupliziert und in amdcal*.dll umbenannt werden, dann sollte es auch gehen. Es müssen also dann mit dem Cat9.2 also insgesamt 6 dieser .dll Dateien vorhanden sein (drei amdcal*.dll und drei atical*,dll). Unter Vista darf BOINC nicht im Protected Mode installiert sein (Serviceinstallation).

Twodee
04.12.2008, 16:42
laufen tuts aber schon auf einem x64-system, oder? ???

jepp, ich setze die da auf einem Q9300 und WinXp 64 ein. Das ding läuft.

OT:
Q9300@3.2Ghz WinXp64 +32bit App braucht ~800 Sekunden, der Q6600@3.2Ghz WinXp32 benötigt dagegen ~1000 Sekunden. proMhz-Vorteil für den Q9300: 20% :o (kann nich sein oder?)
.
EDIT :
.

Wahrscheinlich meldet sich die App bei Twodees Stats-Seite an. Dann kann er die für jeden einzeln auch wieder deaktivieren. Trusted Computing läßt grüßen *suspect* *lol*

Außerdem kann doch wahrscheinlich auch eine C# JIT-kompilierte Version performancemäßig mithalten :]


hehe, jau und gleichzeig spioniert diese App euren PC aus, hab da einen Deal mit dem BKA ;D

Der Grund is, das ab dem VS2005 das .NET mit eingebunden wird, evtl kann ich es auch ausgliedern, brauchte ich aber bis jetzt nie....
.
EDIT :
.
Link zur App:

http://stats.planet3dnow.biz/Apps/MW/MW-App.zip

TiKu
04.12.2008, 16:46
Der Grund is, das ab dem VS2005 das .NET mit eingebunden wird, evtl kann ich es auch ausgliedern, brauchte ich aber bis jetzt nie....Man wird doch nicht gezwungen C++/CLI zu nutzen. Ich habe mit VS2005 stinknormale C/C++-Anwendungen geschrieben und tu das auch mit VS2008.

gruenmuckel
04.12.2008, 16:48
Danke. Hab übrigends heute um 13:34 Uhr die 0.7 app bekommen.


Aber nicht schlecht, Twoodee, von 55min runter auf ~20.
Gut, bei den 5,5 Minuten von damals sind wir noch nicht, aber das wird irgendwann schon.

Twodee
04.12.2008, 16:52
Man wird doch nicht gezwungen C++/CLI zu nutzen. Ich habe mit VS2005 stinknormale C/C++-Anwendungen geschrieben und tu das auch mit VS2008.
mal sehen ob ich es entfernen kann.
.
EDIT :
.

Danke. Hab übrigends heute um 13:34 Uhr die 0.7 app bekommen.


Aber nicht schlecht, Twoodee, von 55min runter auf ~20.
Gut, bei den 5,5 Minuten von damals sind wir noch nicht, aber das wird irgendwann schon.

du musst bedenken das die WUs größer im gegensatz zu früher sind.

außerdem nicht 20 sondern 18 ;)

die 07er App wird wohl ein bugfix sein, schaue ich mir mal an und "aktualisiere" dann entsprechend.

indiana_74
04.12.2008, 16:53
Sollten die neuen MW-WUs nicht deutlich länger laufen?

Hab jetzt die ersten am Wickel und die müssten hochgerechnet nach etwa 16 Minuten fertig sein.

In der 0.7 Version sollen laut deren Page weitere Optimierungen drin sein.

TiKu
04.12.2008, 16:55
mal sehen ob ich es entfernen kann.Projekteigenschaften -> General -> Common Language Runtime support auf "No Common Language Runtime support" stellen

Fränki´s Welle
04.12.2008, 17:04
Habe BOINC beendet die neue Version in das entsprechende Verzeichnis gepackt. Dann BOINC neu gestartet und dabei hat die neue Version die zu 45 % berechnete WU geschrottet.

Gipsel
04.12.2008, 17:05
Sicher, daß Deine App kein SSE2 voraussetzt?
Ein AthlonXP (http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=23954) von mir verträgt die App nämlich nicht (WinXP32 SP3). Und da ist das .NET Framework 2.0 (SP1) installiert. Daran kann es also nicht liegen.

Fränki´s Welle
04.12.2008, 17:08
Neue WU runtergeladen und auch gleich geschrottet. Aber glaube ich weis schon warum. Der olle Rechner hat kein Microsoft .NET Framework Version 2.0 drauf. Gleich mal nachinstallieren.

Twodee
04.12.2008, 17:09
Sicher, daß Deine App kein SSE2 voraussetzt?
Ein AthlonXP (http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=23954) von mir verträgt die App nämlich nicht (WinXP32 SP3). Und da ist das .NET Framework 2.0 (SP1) installiert. Daran kann es also nicht liegen.
jo, auf einem PIII läuft sie.

@tiKu, diese Option ist aber bereits deaktiviert. Er benötigt eien MSVCRT80.DLL und MSCPV80.DLL, allerdings nimmt er nicht jede Version :(

TiKu
04.12.2008, 17:09
Ich habe mir die App grad mit dem Dependency Walker angeschaut, die braucht gar kein .net. ;) Die von dir genannten DLLs sind die ganz normalen C Runtimes. Wenn du für die statisches Linken aktivierst, brauchst du die DLLs nicht.

Fränki´s Welle
04.12.2008, 17:10
Sicher, daß Deine App kein SSE2 voraussetzt?
Ein AthlonXP (http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=23954) von mir verträgt die App nämlich nicht (WinXP32 SP3). Und da ist das .NET Framework 2.0 (SP1) installiert. Daran kann es also nicht liegen.

Nun dann brauche ich es nicht weiter zu probieren.

Twodee
04.12.2008, 17:10
Ich habe mir die App grad mit dem Dependency Walker angeschaut, die braucht gar kein .net. ;) Die von dir genannten DLLs sind die ganz normalen C Runtimes. Wenn du für die statisches Linken aktivierst, brauchst du die DLLs nicht.
man lernt nie aus :-*

Gipsel
04.12.2008, 17:12
Ich habe mir die App grad mit dem Dependency Walker angeschaut, die braucht gar kein .net. ;) Die von dir genannten DLLs sind die ganz normalen C Runtimes. Wenn du für die statisches Linken aktivierst, brauchst du die DLLs nicht.
Ich denke, das wird auch das Problem bei mir sein.

TiKu
04.12.2008, 17:13
Hier gibts die DLLs: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=de

Fränki´s Welle
04.12.2008, 17:23
Hier gibts die DLLs: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=de

Das hat bei mir auch nicht geholfen. Die WUs werden gar nicht berechnet. Der Rechner rechnet Spin und lädt eine neue WU von MW runter und setzt diese ohne Berechnung auf 100 %.Der Rechner ist ein alter XP 1000 ohne SSE.

Twodee
04.12.2008, 17:29
es gibt gleich eine "lauffähige" verison, welche auch ohne c-runtime mist funktioniert. das problem was das das manifest eingebettet war.

Fränki´s Welle
04.12.2008, 17:31
Danke für die Mühe.*great*

Twodee
04.12.2008, 17:33
Korrigierte Version:

http://stats.planet3dnow.biz/Apps/MW/MW-App.zip

bzw.

http://stats.planet3dnow.biz/Apps/MW/milkyway_0.6_windows_intelx86.exe
und
http://stats.planet3dnow.biz/Apps/MW/app_info.xml

gruenmuckel
04.12.2008, 17:38
Korrigierte Version:

http://stats.planet3dnow.biz/Apps/MW/MW-App.zip

bzw.

http://stats.planet3dnow.biz/Apps/MW/milkyway_0.6_windows_intelx86.exe
und
http://stats.planet3dnow.biz/Apps/MW/app_info.xml
Ich habe da Merkwürzigkeiten.

In dem Archiv ist die app "geändert am" von 15:15 Uhr.
Die einzeln downloadbare App ist von 17 Uhr irgendwas.
*noahnung*

HAb also die vermeintlich neuere genommen und sie gedownloadet. Allerdings bekomme ich damit in Boinc Ständig Fehlermeldungen das "MS-DOS 16-Bit Teilsystem" betreffend.*noahnung*

Twodee
04.12.2008, 17:45
Die zip-Datei war noch nicht auf dem neusten Stand. Sollte es jetzt aber sein.

Gipsel
04.12.2008, 17:50
Ich habe da Merkwürzigkeiten.

In dem Archiv ist die app "geändert am" von 15:15 Uhr.
Die einzeln downloadbare App ist von 17 Uhr irgendwas.
*noahnung*

HAb also die vermeintlich neuere genommen und sie gedownloadet. Allerdings bekomme ich damit in Boinc Ständig Fehlermeldungen das "MS-DOS 16-Bit Teilsystem" betreffend.*noahnung*
Bei mir sieht es so aus:

04.12.2008 17:46:30|Milkyway@home|Restarting task nm_stripe82_r2_11295_1228408219_0 using milkyway version 6
04.12.2008 17:46:31|Milkyway@home|Task nm_stripe82_r2_11295_1228408219_0 exited with zero status but no 'finished' file
04.12.2008 17:46:31|Milkyway@home|If this happens repeatedly you may need to reset the project.

Geht also auch nicht (habe genau wie Grünmuckel nur die .exe heruntergeladen).
.
EDIT :
.

Die zip-Datei war noch nicht auf dem neusten Stand. Sollte es jetzt aber sein.
Das zip-File ist jetzt kaputt (läßt sich nicht öffnen) *noahnung*

TiKu
04.12.2008, 17:51
@Twodee: Da stimmt was nicht. Die exe aus der ZIP ist noch immer von 15:xx Uhr. Die einzelne exe ist von 17:xx Uhr, deutlich größer, wird von Dependency Walker aber als 16-Bit-Anwendung erkannt.

DerRob
04.12.2008, 17:56
hmm, irgendwas stimmt aber trotzdem nicht mit der zip-datei. ich kann sie weder mit 7zip noch mit dem speedcommander öffnen...
die einzelnen downloads klappen aber, allerdings kann ich das momentan nicht testen:

04.12.2008 17:45:31|Milkyway@home|Sending scheduler request: Requested by user. Requesting 359424 seconds of work, reporting 0 completed tasks
04.12.2008 17:45:36|Milkyway@home|Scheduler request succeeded: got 0 new tasks
04.12.2008 17:45:36|Milkyway@home|Message from server: No work sent
04.12.2008 17:45:36|Milkyway@home|Message from server: (reached daily quota of 4 results)

???

heavy-Ions@boinc
04.12.2008, 18:05
wenn du zwischendurch mal 5min zeit hast (ich weiss, wird nicht der falls sein ;) )
würdest du dann auch eine linux-appl basteln? ;)

KIDH
04.12.2008, 18:13
Der Rechner ist ein alter XP 1000 ohne SSE.

Ich hab das bei dir schon mehrfach gelesen...es gibt keinen Athlon XP 1000 und erst recht keinen ohne SSE. Du wirst einen stinknormalen Thunderbird haben.

Fränki´s Welle
04.12.2008, 18:30
Ich hab das bei dir schon mehrfach gelesen...es gibt keinen Athlon XP 1000 und erst recht keinen ohne SSE. Du wirst einen stinknormalen Thunderbird haben.

Da hast du bestimmt recht. Aber XP schreibt sich schneller als Thunderbird. Und alt sind beide.;) Aber das musst du nicht mehr lange ertragen da der Thunderbird in ein anderes System wandert. Und der neue Besitzer schreibt dann bestimmt die korrekte CPU - Version in seine Texte.

TiKu
04.12.2008, 18:36
Lass das "XP" einfach weg - spart 2 Zeichen und du hast die korrekte Bezeichnung der CPU. ;)

manni.deutsch
04.12.2008, 19:58
molin moin

ich kann zwar die zip datei downloaden

aber beim entpacken sagt er immer das das archiv beschädigt ist..

*noahnung**noahnung**noahnung*


entweder übertragungsfehler oder was ??

kann mir jemand eine datei senden ?

manni.deutsch@freenet.de

Sabroe SMC
04.12.2008, 20:04
molin moin

ich kann zwar die zip datei downloaden

aber beim entpacken sagt er immer das das archiv beschädigt ist..

*noahnung**noahnung**noahnung*


entweder übertragungsfehler oder was ??

kann mir jemand eine datei senden ?

manni.deutsch@freenet.de

Geht mir genauso *noahnung*

Twodee
04.12.2008, 20:40
hmpf. sorry ich musste vorhin weg, war noch im büro und jetzt ist feierabend.

also das zip ist put, ok. dann benutzt die exe-datei und die app-info datei. aber vorher müßt ihr euer MW-projekt zurücksetzen und die restlichen alten dateien im mw-ordner löschen. anschließend lasst ihr das mw projekt aktualisieren, wenn er dann wieder anfängt zu rechnen stoppt ihr boinc und kopiert meine version (app+appinfo datei) in den projektordner und startet boinc wieder.
.
EDIT :
.
http://stats.planet3dnow.biz/Apps/MW/milkyway_0.6_windows_intelx86.exe
und
http://stats.planet3dnow.biz/Apps/MW/app_info.xml

JKuehl
04.12.2008, 20:43
kommen aber seit stunden keine wus rein..

04.12.2008 20:42:57|Milkyway@home|Sending scheduler request: Requested by user. Requesting 362442 seconds of work, reporting 0 completed tasks
04.12.2008 20:43:02|Milkyway@home|Scheduler request completed: got 0 new tasks

J-R
04.12.2008, 21:23
momentan übertrifft sich MW ja mit ständig neuen versionen.
jetzt wird die v0.7 verteilt, soll 10% schneller sein als die v0.6.

Twodee
04.12.2008, 22:09
momentan übertrifft sich MW ja mit ständig neuen versionen.
jetzt wird die v0.7 verteilt, soll 10% schneller sein als die v0.6.
*great*

snicK
04.12.2008, 22:54
bei mir lädt milkyway gar nichts mehr herunter. Der Ordner ist komplett leer*noahnung*

Twodee
04.12.2008, 23:04
ich habe jetzt auch einen weiteren rechner für mw aktiviert und ihn mit der 07er app (projektstandard) laufen lassen wollen, geht aber nicht da ich keine wu bekomme *noahnung*

HGW
04.12.2008, 23:21
liegt es daran?

milkyway_assimilator milkyway Not Running

und

Results ready to send 0

snicK
05.12.2008, 16:19
bei mir dauern die Wu´s jetzt 1h:o mit der v0.7 merk da nix, dass die 10% laut MW schneller sein sollen.

KGBerlin
05.12.2008, 18:32
bei mir dauern die Wu´s jetzt 1h:o mit der v0.7 merk da nix, dass die 10% laut MW schneller sein sollen.

Bei mir vorraussichtlich 22 Minuten. Ich hab unserem Statsgott seine eins Verzeichniß gekloppt und das ist das Ergebniss :P
Allerdings > "06.12.2008 18:31:39|Milkyway@home|Message from server: Project is temporarily shut down for maintenance"

PS: Niedlich ist ja das im Boincgadget unter dem Milkywayfortschrittsbalken "Milkyway@Home Optimized" hin und her läuft *lol*

snicK
05.12.2008, 19:18
ich hab das verzeichnis auch nochmal neu reinkopiert, jetzt bekomm ich nur berechnungsfehler *noahnung*
ich glaub ich setz mw nochmal zurück und probier es einfach nochmal.

Fränki´s Welle
05.12.2008, 19:20
User of the day

http://milkyway.cs.rpi.edu/milkyway/user_profile/images/3002_sm.jpg (http://milkyway.cs.rpi.edu/milkyway/view_profile.php?userid=3002) http://milkyway.cs.rpi.edu/milkyway/img/head_20.png (http://milkyway.cs.rpi.edu/milkyway/view_profile.php?userid=3002) Crunch3r Rules! (http://milkyway.cs.rpi.edu/milkyway/show_user.php?userid=3002)
http://www.setiusa.net/images/su_ban_tr4_flag.jpg (http://www.setiusa.net/)

Sachen gibt´s.*lol*
Da haben wir zu wenig für unseren Kandidaten abgestimmt.

snicK
05.12.2008, 19:49
gibt es schon eine optimierte app für die v0.7 da ich nur die v0.6

Cherry
05.12.2008, 19:52
Bei mir vorraussichtlich 22 Minuten. Ich hab unserem Statsgott seine eins Verzeichniß gekloppt und das ist das Ergebniss :P
Wie machst du das? Ich krieg Fehler vom 16-Bit-Subsystem...

Cherry

KGBerlin
05.12.2008, 19:56
Wie machst du das? Ich krieg Fehler vom 16-Bit-Subsystem...

Cherry

Boinc beendet, die App von Twodee ins Verzeichniss kopiert und Boinc neu gestartet *noahnung* Jetzt ist die 06 von Twodee drin und irgendeine 07 aber es läuft.
Hab die Managerversion 6.2.19.

gruenmuckel
05.12.2008, 19:56
Wie machst du das? Ich krieg Fehler vom 16-Bit-Subsystem...

Cherry
Hab ich auch. Die Version im Zip ist kaputt. Weiter oben im Thread (20 Posts zurück oder so) sind die app und die appinfo.xml einzeln verlinkt. die funktionieren.

Allerdings nur die 0.6


Ob man die 0.6 in 0.7 umbenennen kann? *chatt*

manni.deutsch
05.12.2008, 20:01
Allerdings nur die 0.6


Ob man die 0.6 in 0.7 umbenennen kann?

moin moin

und schon getestet

mfg manni

snicK
05.12.2008, 20:03
Boinc beendet, die App von Twodee ins Verzeichniss kopiert und Boinc neu gestartet *noahnung* Jetzt ist die 06 von Twodee drin und irgendeine 07 aber es läuft.
Hab die Managerversion 6.2.19.

Das hab ich genauso gemacht, nur bei mir gibt es Berechnungsfehler sofort.

KGBerlin
05.12.2008, 20:17
Hab nun auch ~45Minuten für eine WU *suspect*
Naja immerhin keine Fehler. Ich "lösch" mal die 07 und schaue was passiert...

Edit: Nach dem löschen der 07.exe sind 4 mit Berechnungsfehler abgebrochen aber die neuen laufen wohl sauber durch, werden wohl aber auch um die 40 Minuten brauchen. und hat sich die 07 gleich wieder gezogen. Also gehe ich mal von aus das Boinc nun mit der 07 rechnet.

Nochmal Edit:
Hab jetzt mal die 06 als 07 umbenannt ^^
Es scheint schneller zu laufen, genaueres gibts in 20 Minuten ;)

Edit: Die 06 in 07 umbenennen bringt auch nichts. 50% bei *23 Minuten.
Welch Debakel ^^

Cherry
05.12.2008, 20:24
Hab ich auch. Die Version im Zip ist kaputt. Weiter oben im Thread (20 Posts zurück oder so) sind die app und die appinfo.xml einzeln verlinkt. die funktionieren.
Genau die habe ich verwendet. Ergebnis siehe unten.

Cherry

Twodee
05.12.2008, 21:00
Also die 06er App von mir läuft problemlos auf WinXp32 Sp3, WinXp64 Sp2, Win2003-32 Sp2.

Ich kompiliere morgen die 07-App und stelle sie mit allen (nötigen) Zusatzdateien zur Verfügung.
Grüße

Cherry
06.12.2008, 13:52
Also die 06er App von mir läuft problemlos auf WinXp32 Sp3, WinXp64 Sp2, Win2003-32 Sp2.
Oder auch nicht... A64 X2 (leicht übertaktet), XP-SP2: siehe Fehlermeldung von weiter vorne.
C2D (Dell Vostro 200), E8500@Standard, XP-SP3: im Boinc selber: "exited with zero status but no finished file", gerechnet wird nix...


Ich kompiliere morgen die 07-App und stelle sie mit allen (nötigen) Zusatzdateien zur Verfügung.
Ich warte sehnsüchtig :-)

Versteh das bitte nicht als meckern, ich bin sehr dankbar für deine Mühe (obwohl ich mir das auch gerne mal selber anschauen würde, wenn ich wüßte, wie ich aus den Quellen + Visualstudio was ausführbares machen kann), aber es ist halt schon bißchen frustend, daß es hier auf beiden Kisten nicht läuft.

Cherry

Twodee
06.12.2008, 17:47
@Cherry: laut "Mein System" hast du aber WinXp mit Sp2, ich hab Sp3 drauf und es läuft.

manni.deutsch
06.12.2008, 17:51
Also die 06er App von mir läuft problemlos auf WinXp32 Sp3, WinXp64 Sp2, Win2003-32 Sp2.

Ich kompiliere morgen die 07-App und stelle sie mit allen (nötigen) Zusatzdateien zur Verfügung.
Grüße
hällöchen .....
ich warte auch sehnsüchtig ...
....

gruß manni

Twodee
06.12.2008, 17:55
hällöchen .....
ich warte auch sehnsüchtig ...
....

gruß manni
joa wird noch ne weile dauern, den ganzen kram hab ich im büro (und da bin ich derzeit nicht).

Cherry
06.12.2008, 17:56
@Cherry: laut "Mein System" hast du aber WinXp mit Sp2, ich hab Sp3 drauf und es läuft.
Ich habs wie geschrieben auf 2 Systemen getestet: meiner privaten Kiste (der X2 mit XP-SP2) und meiner Dell-Kiste von der Firma (C2D, XP-SP3).
Es läuft auf beiden nicht.

Cherry

Gipsel
07.12.2008, 04:27
Muß mich leider in den "Club der Meckerer" einreihen. An der Situation von vor ein paar Tagen hat sich nichts geändert. Es läuft einfach nicht bei mir (XP SP3).

Und bevor Du Dich fragst, warum ich mir nicht selber was bastel, ich habe gerade einen Core i7 in den Fingern und benche den mal mit ein paar Projekten (http://www.planet3dnow.de/vbulletin/showthread.php?p=3801328#post3801328) 8)
Keine Sorge, MW kommt auch noch dran (stock client).

Dabei ist mir aufgefallen, daß im CI auf Deiner Statsseite keine Unterscheidung zwischen Core i7 mit und ohne Hyperthreading gemacht wird. Kannst Du die CPU-Liste noch um einen Eintrag für den Core i7 +HT erweitern (oder meinetwegen auch -HT ;))?

Außerdem hast Du da MW-Zeiten für Deine Variante eingetragen. Meinst Du, das ist sinnvoll? Schließlich ist die nicht wirklich verbreitet (wird sie auch nicht, wenn sie bei der Hälfte nicht läuft :-X), spiegelt also sozusagen nicht die "wirkliche" Creditsituation wider.

KGBerlin
07.12.2008, 10:30
Jetzt macht unseren Statsgott nicht fertig.
Der Mann hat Wochenende und das hat er sich sicherlich auch verdient :]

Sch**ss auf MW, die paar Tage machen den Salat auch nicht frischer.
Also lasst Twodee mal nen freien Tag *glaubses* ;D

Twodee
07.12.2008, 10:36
Am Anfang hatte ich mal erwähnt das man ein ..NET SP 3 dafür braucht, das gillt nach wie vor. Das dumme VS2005 verwendet davon Dateien, obwohl ich beim kompilieren entsprechende Einstellungen gesetzt habe, die das verhindern sollten.

Zum stock-client 07: mit einem 45nm Quad und 3.2Ghz komme ich unter 1500 sekunden, also fast am Creditlimit bzw nicht weit davon entfernt.
.
EDIT :
.

Jetzt macht unseren Statsgott nicht fertig.
Der Mann hat Wochenende und das hat er sich sicherlich auch verdient :]

Sch**ss auf MW, die paar Tage machen den Salat auch nicht frischer.
Also lasst Twodee mal nen freien Tag *glaubses* ;D

ich würde ja gerne die app rausbringen, aber seit 14Stunden ist unser DSL-Router offline (daher auch mein output bei 0) und ohne dem komme ich nciht per vpn ins netz.

TiKu
07.12.2008, 10:39
Am Anfang hatte ich mal erwähnt das man ein ..NET SP 3 dafür braucht, das gillt nach wie vor.Und ich bezweifle nach wie vor, dass man .NET braucht, denn Dependency Walker meldet keine einzige Abhängigkeit zu einer Datei aus dem .NET Framework.

Das dumme VS2005 verwendet davon Dateien, obwohl ich beim kompilieren entsprechende Einstellungen gesetzt habe, die das verhindern sollten.Welche sollen das sein?

Twodee
07.12.2008, 10:40
zweifeln darfst du so viel du willst :P ändert aber ncihts daran.

TiKu
07.12.2008, 10:46
Das würde bedeuten, dass meine C/C++-Programme seit Jahren .NET vorraussetzen, was sie definitiv nicht tun. Solange die Option "Common Language Runtime support" auf "No" steht, braucht das Programm kein .NET.

MGeee
07.12.2008, 10:59
Habe mich mit MW bisher nicht beschäftigt aber geseben, dass es dort unglaubich unfair viel Punkte gibt. MW ist für mich deswegen kein Projekt, bei dem ein #1 Platz Prestige hätte, weder für einzelne User noch für das P3D. MW ist etwas, um seinen gesamten Punktestand über alle Projekte massiv zu pushen (boinc combined).
Ich weiß zwar nicht warum es bei MW soviel Credits gibt, aber besteht da prinzipiell nicht die Gefahr das Die Boinc-Betreiber in Berkeley da irgendwann man bestimmen, dass sämtliche MW-Punkte ungültig sind?
Bei QMC wurde ja auch irgendwann mal von Berkeley bemängelt, dass die Punktevergabe unfair ist und es musste nachustiert werden. Bei MW ist die Punktevergabe ja jenseits von gut und böse und das könnte noch krassere Schritte aus Berkley bedeuten.
Schließlich zieht sowas ja alle Punkte-Geier an. Wundert mich, dass die ESL dort nicht voll zugeschlagen hat *noahnung* .

Fakt ist, dass seit MW der boinc-combined keinerlei Aussagekraft mehr hat !!

Twodee
07.12.2008, 11:03
Das würde bedeuten, dass meine C/C++-Programme seit Jahren .NET vorraussetzen, was sie definitiv nicht tun. Solange die Option "Common Language Runtime support" auf "No" steht, braucht das Programm kein .NET.


als ich die datei das erstemal online gestellt hatte, war schon "Common Language Runtime support" nicht aktiviert, allerdings wurde da ein manifest eingebettet welches eine reference auf die mscvr bzw msvcp dll (version 8.0.50608.0) hat. diese beiden müßten aber mit dem .NET SP3 ausgeliefert werden (ja ich weiß die haben nix mit dem .NET zu tun) und nach Installation funktionierte es. Reproduzierbar auf mehreren Systemen!

Die 2. Version (welche auf dem ftp-server liegt), ist von den manifest-zeugs befreit und auch um gute 160KB größer. Diese funktiniert bei mir problemlos, warum sie nicht bei euch geht kann ich noch nicht sagen. (evtl ist die exe-datei wie das zipfile auf dem ftp-server beschädigt, kümmern kann ich mich erst darum wenn ich in der firma bin)

Twodee
07.12.2008, 11:06
das ist käse, bei MW gibt es derzeit faire credits. max. 6K pro Tag für einen extremen oced quad. und für optimierer sind max. 10K drin. wenn du wegen den credits jammern möchtest dann tu das bitte auch bei gpugrid, abc und seti. danke.

ps.: mir ist es egal ob DU es für wichtig hälst oder nicht. jammere doch lieber über die simap leute :P


ps.: "Habe mich mit MW bisher nicht beschäftigt aber geseben" ja da solltest du einiges nachholen um solche kommentare zu schreiben zu dürfen ;)

TiKu
07.12.2008, 11:06
als ich die datei das erstemal online gestellt hatte, war schon "Common Language Runtime support" nicht aktiviert, allerdings wurde da ein manifest eingebettet welches eine reference auf die mscvr bzw msvcp dll (version 8.0.50608.0) hat. diese beiden müßten aber mit dem .NET SP3 ausgeliefert werden (ja ich weiß die haben nix mit dem .NET zu tun) und nach Installation funktionierte es. Reproduzierbar auf mehreren Systemen!Eben! Die Dateien haben nichts mit .NET zu tun. Ich habe 1-2 Seiten vorher schonmal auf den Download der Microsoft Visual C++ 2005 Runtime Redistributables verlinkt, welche die beiden Dateien enthalten müssten.

Twodee
07.12.2008, 11:08
Eben! Die Dateien haben nichts mit .NET zu tun. Ich habe 1-2 Seiten vorher schonmal auf den Download der Microsoft Visual C++ 2005 Runtime Redistributables verlinkt, welche die beiden Dateien enthalten müssten.

Das funktioniert aber nicht, da die Versionen nicht übereinstimmen.

TiKu
07.12.2008, 11:17
Okay, dann gehen vll. die hier: http://www.microsoft.com/downloads/info.aspx?na=22&p=45&SrcDisplayLang=de&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d200b2fd9-ae1a-4a14-984d-389c36f85647%26DisplayLang%3dde

Twodee
07.12.2008, 11:17
Okay, dann gehen vll. die hier: http://www.microsoft.com/downloads/info.aspx?na=22&p=45&SrcDisplayLang=de&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d200b2fd9-ae1a-4a14-984d-389c36f85647%26DisplayLang%3dde

probiere es aus ;) - allerdings mit der ersten version, falls du diese noch hast.

MGeee
07.12.2008, 11:18
das ist käse, bei MW gibt es derzeit faire credits. max. 6K pro Tag für einen extremen oced quad. und für optimierer sind max. 10K drin. wenn du wegen den credits jammern möchtest dann tu das bitte auch bei gpugrid, abc und seti. danke.

ps.: mir ist es egal ob DU es für wichtig hälst oder nicht. jammere doch lieber über die simap leute :P


ps.: "Habe mich mit MW bisher nicht beschäftigt aber geseben" ja da solltest du einiges nachholen um solche kommentare zu schreiben zu dürfen ;)

Hierzu möchte gerne aus dem SetiGermany zitieren (ich weiß, dass es einen ähnlich kontrovers diskutierten Thread hier im P3D gibt):
Quelle: Berechnungen für Milkyway@home bitte umgehend stoppen! (http://board.setigermany.de/showthread.php?t=2481).
Wie ich sehe, hast Du die letzten wenigen Wochen bei MW 4,7 Mio. gemacht. Tagesoutput war bis vor kurzem noch >100k bei Dir (hatte nachgeschaut, weil ich Deinen Output hier bei den beiden KAV-Projekten vermisst habe).



wie es die meisten wahrscheinlich schon mitbekommen haben, ist das Projekt Milkyway@home derzeit etwas "derangiert".

Dies stellt sich dahingehend dar, als für das Projekt ein optimierte Anwendung verfügbar ist, die die Berechnung der einzelnen Workunits IMMENS beschleunigt. Diese optimierte Anwendung wird aber vom Projekt noch nicht als Standard versandt.

Weiterhin ergibt sich aus dem Credit-System des Projekts die Möglichkeit, auch mit - für BOINC-Verhältnissse - uralter Hardware mehrere Tausend Credits pro Tag "errechnen" zu können.

Dadurch gerät das komplette Credit-System aller BOINC-Projekte total durcheinander, und Statistiken werden konfus bis obsolet.


SETI.Germany empfhielt daher seinen Mitgliedern, die Berechnung für Milkyway@home ab sofort zu stoppen, bis die Projektbetreiber - wie auch von anderen Teams gefordert - diese Änderungen übernommen haben.

Diese Empfehlung habe ich auch so ähnlich in Englisch auf der Projektseite veröffentlicht.


Mal sehen, ob die Projekt-Betreiber nun reagieren, es wäre dringend nötig.


Wie dem auch sei:
Anhand der aktuell PPD bei MW sehe ich, dass endlich reagiert wurde.
Nun hoffe ich jedoch noch, dass die bisher erwirtschafteten Credits bei MW noch nach unten hin nach dem aktuellen Creditschlüssel angepasst werden. Das wäre nur fair und gerecht, auch wenn das für viele bedeutet, dass sie mehrere Mio. Credits abgezogen bekommen. Aber demjenigen, der nur das wissenschaftliche Projekt unterstützen wollte, wird das egal sein. Treffen wird es dann diejenigen, die MW nur wg. des fehlgeleiteten (und mittlerweile korregierten?) Creditsystems gerechnet haben.

Kater Sylvester
07.12.2008, 11:19
Hi MGeee,

ich will es mal etwas weniger drastisch als Twodee ausdrücken.
Kann es sein, dass Du da was nicht mitbekommen hast? ;)
Les Dir mal diesen thread durch:

http://www.planet3dnow.de/vbulletin/showthread.php?t=348575

Dann weist Du, worum es geht und kannst Dir Deine eigene Meinung neu bilden.
Aber nehm Dir dann heute nichts anderes mehr vor. Der thread ist ziemlich lang. ;D

Ich wünsche allen unseren crunchern einen schönen 2. Advent. *rose*

TiKu
07.12.2008, 11:20
Bei mir lief die App von Anfang an, weil ich von Anfang an die nötigen Libs installiert hatte.

Twodee
07.12.2008, 11:24
Tja das problem ist, das man die die Credits nicht anpassen kann! Sie wurden ja zu rechtens erwirtschaftet, nur mit dem unterschied das einige mit der gleichen hardware "schneller" also "mehr" arbeit erledigt haben, als andere. wie willst du das im nachhinein separieren? man könnte jetzt alle userer um einen gewissen faktor nach unten stutzen aber dann würden sehr viele, welche normal gerechnet haben mit der bremser-app, sehr laut schreien ;)

von den 4,7 habe ich ca, 3Mio mit meiner optimierten App gemacht, den rest mit der offiziellen linux-app.

ach ja lass bitte die kommentare von SG raus, die interessieren keinen, wenn ich gejammere lesen will dann gehe ich in deren board lesen ;)


ps.: fehlgeleitetes creditsystem? du mußt dich echt mal einlesen!
ps2: solange der sourcecode frei-verfügbar ist, kann jeder "legal" seine optimierte app bauen und einsetzen.

Twodee
07.12.2008, 11:26
Bei mir lief die App von Anfang an, weil ich von Anfang an die nötigen Libs installiert hatte.
was mich nicht wundert ;)

MGeee
07.12.2008, 11:29
Hi Kater,

ich bewerte nicht, dass steht mir nicht zu.
Wenn es so rüber kommt, ist das keine Absicht.
Ich habe lediglich die Fakten dargestellt:
- Creditoutput pro Tag
- Gesamtpunktestand
usw.usw.

@Twodee
Ich frage mich gerade, wieviel Credits am Tag und boinc-combined ich erreicht hätte, wenn meine Systeme mit dem optimierten MW-client gecruncht hätten... bei Spin hatte ich ca. 17k bei Poem sind es ca. 27k bei MW wären es wohl 107k gewesen (nur eine Vermutung).

Twodee
07.12.2008, 11:34
Hi Kater,

ich bewerte nicht, dass steht mir nicht zu.
Wenn es so rüber kommt, ist das keine Absicht.
Ich habe lediglich die Fakten dargestellt:
- Creditoutput pro Tag
- Gesamtpunktestand
usw.usw.

@Twodee
Ich frage mich gerade, wieviel Credits am Tag und boinc-combined ich erreicht hätte, wenn meine Systeme mit dem optimierten MW-client gecruncht hätten... bei Spin hatte ich ca. 17k bei Poem sind es ca. 27k bei MW wären es wohl 107k gewesen (nur eine Vermutung).
womöglich. allerdings habe ich in mw nie meine gesamte hardware laufen lassen. nur max. 5quads (intel-oced über 3ghz, die amds haben da keine chance) unter linux mit 10K pro Quad, macht 50K am tag, die restlichen rechner hatte ich immer auf rcn und spinhenge.
als meine optimierte app fertig war hatte ich ca. 7 quads und 3 duals zu 25% bis 50% auf MW laufen und zwichen 100 und 200K am Tag gemacht (gemittelt). wenn ich alles auf 100% auf MW gehabt hätte, wäre ich da, wo MilkOpps jetzt ist, falls dir dieser name etwas sagt ;)

MGeee
07.12.2008, 11:46
womöglich. allerdings habe ich in mw nie meine gesamte hardware laufen lassen. nur max. 5quads (intel-oced über 3ghz, die amds haben da keine chance) unter linux mit 10K pro Quad, macht 50K am tag, die restlichen rechner hatte ich immer auf rcn und spinhenge.
als meine optimierte app fertig war hatte ich ca. 7 quads und 3 duals zu 25% bis 50% auf MW laufen und zwichen 100 und 200K am Tag gemacht (gemittelt). wenn ich alles auf 100% auf MW gehabt hätte, wäre ich da, wo MilkOpps jetzt ist, falls dir dieser name etwas sagt ;)

Ich sags mal so, bei Folding@Home findet das ja auch schon seit mehreren Jahren so statt.
Früher gab es nur einen normalen Client. Dann kam irgendwann mal der SMP-Client und man konnte ca. 8x soviel PPD rasuholen, als mit zwei oder viel Standard-Clients.
Parallel dazu gab es dann auch noch den PS3-Client (ca. 700 PPD) und seit ein paar Monaten gibt es einen NVidia-Client, mit dem man 5000 PPD und mehr mit nur einer Graka erreichen kann.
Das Prinzip ist wohl dasselbe, wie bei MW:
Deutlich höherer Output, weil einfach mehr berechnet wird (bei F@H weil z.B. Grakas schneller sind und bei MW weil die Software optimiert arbeitet).

Das war auch der Grund, warum ich irgendwann im letzten Sommer fast alle CPUs bei F@H abgezogen habe. Dort sind CPUs zum crunchen relativ "wertlos" geworden.

Wenn der MW-Output dauerhaft so geblieben wäre, hätte das wohl nur eins bedeutet:
Mit der Zeit hätten immer mehr Leute zu MW geswitcht und andere Projekte würden massiv leiden.

Prinzipiell ist das aber eine Grundsatzdiskussion (ich weiß, ich bin hier im Thread damit OT). Aber wäre es nicht besser, wenn alle Boinc-Projekte mit identischer Creditvergabe rechnen würden? Dazu müsste man ja nur die zugrundeliegende Rechenleistung beim Boinc-Start einmal festlegen (und zwar mit Boinc selber und nicht mit der Projekt-App). Stattdessen bringt jedes Projekt sein eigenes Benchmark-App mit und man erreicht bei unterschiedlichen Projekten einen teils sehr unterschiedliche Creditoutput (z.B. Spin vs. QMC vs. MW).

Twodee
07.12.2008, 12:00
Ich sags mal so, bei Folding@Home findet das ja auch schon seit mehreren Jahren so statt.
Früher gab es nur einen normalen Client. Dann kam irgendwann mal der SMP-Client und man konnte ca. 8x soviel PPD rasuholen, als mit zwei oder viel Standard-Clients.
Parallel dazu gab es dann auch noch den PS3-Client (ca. 700 PPD) und seit ein paar Monaten gibt es einen NVidia-Client, mit dem man 5000 PPD und mehr mit nur einer Graka erreichen kann.
Das Prinzip ist wohl dasselbe, wie bei MW:
Deutlich höherer Output, weil einfach mehr berechnet wird (bei F@H weil z.B. Grakas schneller sind und bei MW weil die Software optimiert arbeitet).

Das war auch der Grund, warum ich irgendwann im letzten Sommer fast alle CPUs bei F@H abgezogen habe. Dort sind CPUs zum crunchen relativ "wertlos" geworden.

Andere Baustelle, allerdings ist das nicht das gleiche, da es dort nie den sourcecode für jedermann gab und man somit duch eigene Optimierungen sich einen Vorteil hatte ziehen können. btw. warum hast du dir nicht wie die anderen einfach grakas besorgt und damit gleichgezogen?



Wenn der MW-Output dauerhaft so geblieben wäre, hätte das wohl nur eins bedeutet:
Mit der Zeit hätten immer mehr Leute zu MW geswitcht und andere Projekte würden massiv leiden.

Prinzipiell ist das aber eine Grundsatzdiskussion (ich weiß, ich bin hier im Thread damit OT). Aber wäre es nicht besser, wenn alle Boinc-Projekte mit identischer Creditvergabe rechnen würden? Dazu müsste man ja nur die zugrundeliegende Rechenleistung beim Boinc-Start einmal festlegen (und zwar mit Boinc selber und nicht mit der Projekt-App).
meinst du den Boinc-Bench? Dieser ist aber absulut ungeeigent um die tatsächliche Rechenleistung eines Systems zu ermitteln.



Stattdessen bringt jedes Projekt sein eigenes Benchmark-App mit und man erreicht bei unterschiedlichen Projekten einen teils sehr unterschiedliche Creditoutput (z.B. Spin vs. QMC vs. MW). Wie meinst du das? Meistens orientiert man sich doch an Seti, d.h. was ein genormtes System bei Seti an Credits macht, macht es eben in QMC auch. Das Problem ist aber das eben dieses System in anderen Projekten mit anderen Berechnungen schneller oder langsamer als anders konfigurierte Systeme arbeitet, wodurch es aben zu diesen breiten Credit-Unterschieden kommt.

Gipsel
07.12.2008, 14:32
Hi Kater,

ich bewerte nicht, dass steht mir nicht zu.
Wenn es so rüber kommt, ist das keine Absicht.
Ich habe lediglich die Fakten dargestellt:
- Creditoutput pro Tag
- Gesamtpunktestand
usw.usw.

@Twodee
Ich frage mich gerade, wieviel Credits am Tag und boinc-combined ich erreicht hätte, wenn meine Systeme mit dem optimierten MW-client gecruncht hätten... bei Spin hatte ich ca. 17k bei Poem sind es ca. 27k bei MW wären es wohl 107k gewesen (nur eine Vermutung).
Wenn Du Twodee kritisierst, mußt Du das mindestens genauso auch auf mich beziehen.

Aber ich gebe Dir mal einen kurzen Abriß des Geschehens:
Aus genau den Gründen, die Du anführst haben wir mit unseren optimierten Versionen nicht voll auf unsere Accounts gerechnet. Was glaubst Du, wo die 24 Millionen credits in 30 Tagen für diesen teamlosen "Milksop at try" hergekommen sind? Wir wollten den Betreiber unter Druck setzen ohne uns oder auch dem P3D-Team einen riesigen Vorteil zu verschaffen. Diese 24 Millionen hätten genauso gut auch auf Twodees und meinem Account (und damit bei P3D) landen können.
Und das war noch lange nicht das Maximum. Die erste Woche waren das 6 Quads und 6 Duals, später dann nur noch 6 Duals (3 davon AthlonMPs@1.33GHz *buck*). Ein einziger X2@3.1GHz hat mit meiner Version etwa 245k/Tag gemacht, die MPs etwa 90k. Ein 45nm Quad@3GHz wäre so bei etwa 500k gelandet. Wenn Du Dir anschaust, was Twodee und mir an Rechnern insgesamt zur Verfügung steht, hätte jeder von uns locker mehrere Millionen pro Tag machen können. Da wäre Atlas bei Einstein nicht hinterhergekommen.

Parallel zu dieser Demonstration haben wir die wesentlichen Optimierungsmöglichkeiten veröffentlicht (der reine Fakt der Ineffizienz war dem Betreiber schon Monate bekannt). Nach einem Monat haben wir dann aufgehört für Milksop zu rechnen und mit Einverständnis des Betreibers Binaries der optimierten Version für Win und Linux veröffentlicht. Diese waren exakt auf dem Stand, mit dem wir zuletzt gerechnet haben. Aus Kompatibilitätsgründen wurden sie allerdings ohne SSE/2/3 und auch mit älteren Compilern erzeugt. Damit konnte jeder ein vom Betreiber eingerichtetes Limit erreichen, das die granted credits auf 0.03 pro Sekunde beschränkt (war anfangs bei 0.06). Dies haben alle Rechner ab PentiumPro 150MHz erreicht und verdeutlicht nochmal den Geschwindigkeitsvorteil der Verbesserungen.

Jetzt hat der Betreiber endlich reagiert und die von uns vorgeschlagenen Änderungen in die offizielle Version eingebaut. Daraufhin hat auch SG die Empfehlung, nicht mehr MW zu rechnen, wieder aufgehoben.

PS: MW ist im Moment übrigens eines der wenigen Projekte, wo AMDs schneller sind als Intels (wenn man keinen Core i7 auffährt) :w_grins:

HGW
07.12.2008, 14:33
auf meinem Dual XP funkioniert die opti app nicht
MW ordner geleert
neue wu's geladen
MW angehalten
Twodee's opti geladen
MW wieder gestartet
die opti app (98KB) wird nicht genommen
MW rechnet mit seiner runtergeladenen app (244KB)
:w_verwirrt:

Twodee
07.12.2008, 14:39
Wenn Du Twodee kritisierst, mußt Du das mindestens genauso auch auf mich beziehen.

Aber ich gebe Dir mal einen kurzen Abriß des Geschehens:
Aus genau den Gründen, die Du anführst haben wir mit unseren optimierten Versionen nicht voll auf unsere Accounts gerechnet. Was glaubst Du, wo die 24 Millionen credits in 30 Tagen für diesen teamlosen "Milksop at try" hergekommen sind? Wir wollten den Betreiber unter Druck setzen ohne uns oder auch dem P3D-Team einen riesigen Vorteil zu verschaffen. Diese 24 Millionen hätten genauso gut auch auf Twodees und meinem Account (und damit bei P3D) landen können.
Und das war noch lange nicht das Maximum. Die erste Woche waren das 6 Quads und 6 Duals, später dann nur noch 6 Duals (3 davon AthlonMPs@1.33GHz *buck*). Ein einziger X2@3.1GHz hat mit meiner Version etwa 245k/Tag gemacht, die MPs etwa 90k. Ein 45nm Quad@3GHz wäre so bei etwa 500k gelandet. Wenn Du Dir anschaust, was Twodee und mir an Rechnern insgesamt zur Verfügung steht, hätte jeder von uns locker mehrere Millionen pro Tag machen können. Da wäre Atlas bei Einstein nicht hinterhergekommen.

Parallel zu dieser Demonstration haben wir die wesentlichen Optimierungsmöglichkeiten veröffentlicht (der reine Fakt der Ineffizienz war dem Betreiber schon Monate bekannt). Nach einem Monat haben wir dann aufgehört für Milksop zu rechnen und mit Einverständnis des Betreibers Binaries der optimierten Version für Win und Linux veröffentlicht. Diese waren exakt auf dem Stand, mit dem wir zuletzt gerechnet haben. Aus Kompatibilitätsgründen wurden sie allerdings ohne SSE/2/3 und auch mit älteren Compilern erzeugt. Damit konnte jeder ein vom Betreiber eingerichtetes Limit erreichen, das die granted credits auf 0.03 pro Sekunde beschränkt (war anfangs bei 0.06). Dies haben alle Rechner ab PentiumPro 150MHz erreicht und verdeutlicht nochmal den Geschwindigkeitsvorteil der Verbesserungen.

Jetzt hat der Betreiber endlich reagiert und die von uns vorgeschlagenen Änderungen in die offizielle Version eingebaut. Daraufhin hat auch SG die Empfehlung, nicht mehr MW zu rechnen, wieder aufgehoben.

PS: MW ist im Moment übrigens eines der wenigen Projekte, wo AMDs schneller sind als Intels (wenn man keinen Core i7 auffährt) :w_grins:

ich stimme dir in alles zu bis auf den letzten punkt. die x4s haben in mw gegen einen 45nm Core2 unter vista64 bit mit der standard-app keine chance. [core2(45nm)@3.2Ghz[winxp64]: unter 1500 sekunden mit der standard 07er app, bei 39 credits]

Gipsel
07.12.2008, 15:06
ich stimme dir in alles zu bis auf den letzten punkt. die x4s haben in mw gegen einen 45nm Core2 unter vista64 bit mit der standard-app keine chance. [core2(45nm)@3.2Ghz[winxp64]: unter 1500 sekunden mit der standard 07er app, bei 39 credits]
Was haben die denn da schon wieder gemacht? Unter Win32 haben die Core2 (auch 45nm) nämlich keine Chance. Auch gewinnen die AMDs durch die 64Bit App praktisch überhaupt nichts. Und die ersten 3 Einträge im C-Index sind doch mit Deiner App gelaufen, die kann man ja nicht rechnen. Also warum werden die 45nm Core2 unter 64Bit soviel schneller, die AMDs aber nicht :w_verwirrt:

Btw., kannst Du im C-Index noch einen Core i7 ohne HT zur CPU-Auswahl hinzufügen?

Twodee
07.12.2008, 15:11
Was haben die denn da schon wieder gemacht? Unter Win32 haben die Core2 (auch 45nm) nämlich keine Chance. Auch gewinnen die AMDs durch die 64Bit App praktisch überhaupt nichts. Und die ersten 3 Einträge im C-Index sind doch mit Deiner App gelaufen, die kann man ja nicht rechnen. Also warum werden die 45nm Core2 unter 64Bit soviel schneller, die AMDs aber nicht :w_verwirrt:

Btw., kannst Du im C-Index noch einen Core i7 ohne HT zur CPU-Auswahl hinzufügen?

ich hab @home (da bin ich gerade nicht) den test mit der standard-07-app unter xp64 gemacht, und er brauchte unter 25 minuten, habe ich aber aus zeitmangel nicht eingetragen und jetzt sind die werte auf der projekteseite weg :( - heute abend wenn ich back@home bin kümmere ich mich drum (auch um die cpu-liste auf der ci-seite).

JagDoc
07.12.2008, 17:00
Mein Atom330 mit HT , standart-07er-app XP64 verblüfft mich etwas:

nm_stripe86 , 5,360.88sec , 41,09Credits
nm_stripe82 , 10,057.08sec , 39.85Credits

Warum ist der Zeitunterschied so extrem?

Im Vergleich zum Q9450 Linux64:

nm_stripe86 , 2,127.20sec , 41.09Credits
nm_stripe82 , 2,070.55sec , 39.85Credits

Da dauern die stripe86 sogar etwas länger.

cu JagDoc

Gipsel
07.12.2008, 17:21
Mein Atom330 mit HT , standart-07er-app XP64 verblüfft mich etwas:

nm_stripe86 , 5,360.88sec , 41,09Credits
nm_stripe82 , 10,057.08sec , 39.85Credits

Warum ist der Zeitunterschied so extrem?

Im Vergleich zum Q9450 Linux64:

nm_stripe86 , 2,127.20sec , 41.09Credits
nm_stripe82 , 2,070.55sec , 39.85Credits

Da dauern die stripe86 sogar etwas länger.

cu JagDoc
Wahrscheinlich hast Du eine der "verunglückten" stripe86 WUs bekommen. Die machen nur die Hälfte von dem, was eigentlich geplant war. Umgekehrt gibt es das auch, einige WUs laufen so lange wie die normalen ~40 credit WUs, es gibt aber nur etwa 20 dafür.

Caipi
07.12.2008, 17:31
Mein Atom330 mit HT , standart-07er-app XP64 verblüfft mich etwas:

nm_stripe86 , 5,360.88sec , 41,09Credits
nm_stripe82 , 10,057.08sec , 39.85Credits

Warum ist der Zeitunterschied so extrem?

Im Vergleich zum Q9450 Linux64:

nm_stripe86 , 2,127.20sec , 41.09Credits
nm_stripe82 , 2,070.55sec , 39.85Credits

Da dauern die stripe86 sogar etwas länger.

cu JagDoc

Moin
auf einem meiner X2 brauchen die 86 (r1 - r8 oder so) nur 1410 sec anstatt ca 2600 bei voller Punktzahl
aber komischerweise auch nur auf diesem einem Rechner ???

Twodee
08.12.2008, 12:24
Ich habe die 07er Version fertig.

ein 3.2Ghz Quad benötigt nur noch 700 Sekunden. (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57583602)

Es gibt eine normale, sse und sse2 version: http://www.file-upload.net/download-1303712/MW.rar.html

Ich hoffe das sie diesmal geht, bei mir laufen alle 3 Versionen.

gruenmuckel
08.12.2008, 12:37
Ich habe die 07er Version fertig.

ein 3.2Ghz Quad benötigt nur noch 700 Sekunden. (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57583602)

Es gibt eine normale, sse und sse2 version: http://stats.planet3dnow.biz/Apps/MW.rar

Ich hoffe das sie diesmal geht, bei mir laufen alle 3 Versionen.
Dnake, das Archiv scheint aber kaputt zu sein. Hat bei mir 357kb, Winrar meldet aber einen zerstörten Dateikopf und im Archiv finde ich nur den Unterordner "normal"

Lade es dochmal bei www.file-upload.net hoch und poste den Link

Twodee
08.12.2008, 12:40
danke. verstehe ich nicht wieso die dinger kaputtgehen

http://www.file-upload.net/download-1303712/MW.rar.html

Cherry
08.12.2008, 13:00
danke. verstehe ich nicht wieso die dinger kaputtgehen

http://www.file-upload.net/download-1303712/MW.rar.html
Das schaut gut aus :-) ca. 1000 s mit X2@2.76 GHz.

Danke,
Cherry

Twodee
08.12.2008, 13:08
Das schaut gut aus :-) ca. 1000 s mit X2@2.76 GHz.

Danke,
Cherry
ab 1300 sekunden schlägt das creditlimit zu.

1000 sekunden, nicht schlecht für einen x2!

Ole
08.12.2008, 13:11
Ich bekommen dauernd ein No Work sent...:w_traurig:

Twodee
08.12.2008, 13:12
Falls es jemanden interessieren sollte:

Der Unterschied zwischen der Betreiber-App 06 und Betreiber-App 07 sind gute 10% Speed, dafür wird das Ergebnis ab der 15. Stelle nach dem Komma ungenauer [was vorher nicht der Fall war].

Cherry
08.12.2008, 13:13
am besten: Milkyway anhalten, dann resetten, und dann Boinc komplett ausmachen -> die neue App ins Milkyway verzeichnis kopieren, und Boinc wieder starten. dann sollte es auch mit den WUs klappen. Sind jedenfalls noch welche da. Zur Not mal alle anderen Projekte anhalten, und dann nochmal versuchen, WUs zu ziehen.

Cherry, als allerletzte Lösung gibts dann noch BoincDV, aber den hab ich bisher nicht gebraucht.

Twodee
08.12.2008, 13:14
Ich bekommen dauernd ein No Work sent...:w_traurig:

detache mal deinen pc vom projekt und füge es wieder hinzu, lade sämtliche dateien des projektes herunter, wenn er fertig ist stoppst du boinc und spielst den client von mir ein. sollte danach laufen.

JKuehl
08.12.2008, 13:24
läuft sowohl auf dem Q6600 also auch auch auf dem Pentium-M-1.6 Ghz Notebook.

Habs aber auf dem Quad wieder runtergeworfen, weil dort POEM läuft.

Ole
08.12.2008, 13:29
Jau, mit beenden des gesamten BOINC hats geklappt. Zurückgesetzt hatte ich das Projekt schon.

Cherry
08.12.2008, 13:45
1000 sekunden, nicht schlecht für einen x2!
um genau zu sein:

1030/1025/995 für die ersten 3 kompletten WUs, waren alles "nm_stripe86_r6"

Cherry

DerRob
08.12.2008, 14:09
hat jemand eine idee, warum ich auf meinem bürorechner seit einigen tagen dauernd folgende meldung bekomme?

08.12.2008 14:05:25|Milkyway@home|Sending scheduler request: Requested by user. Requesting 56057 seconds of work, reporting 0 completed tasks
08.12.2008 14:05:30|Milkyway@home|Scheduler request succeeded: got 0 new tasks
08.12.2008 14:05:30|Milkyway@home|Message from server: No work sent
08.12.2008 14:05:30|Milkyway@home|Message from server: (reached daily quota of 4 results)

hab MW schon zurückgesetzt, und inzwischen auch schon komplett ab- und wieder angemeldet. kann doch nicht sein, daß der quadcore nicht mehr als 4 WUs pro tag knuspern "darf"... ???

Twodee
08.12.2008, 14:36
hat jemand eine idee, warum ich auf meinem bürorechner seit einigen tagen dauernd folgende meldung bekomme?

08.12.2008 14:05:25|Milkyway@home|Sending scheduler request: Requested by user. Requesting 56057 seconds of work, reporting 0 completed tasks
08.12.2008 14:05:30|Milkyway@home|Scheduler request succeeded: got 0 new tasks
08.12.2008 14:05:30|Milkyway@home|Message from server: No work sent
08.12.2008 14:05:30|Milkyway@home|Message from server: (reached daily quota of 4 results)

hab MW schon zurückgesetzt, und inzwischen auch schon komplett ab- und wieder angemeldet. kann doch nicht sein, daß der quadcore nicht mehr als 4 WUs pro tag knuspern "darf"... ???
setze mal deinen workbuffer auf 10 Tage, hast du auch noch andere projekte auf der maschine am start?

Ole
08.12.2008, 14:40
ca 890 Sekunden mit Phenom X4 2.8GHz und der SSE2 App.

Twodee
08.12.2008, 14:42
ca 890 Sekunden mit Phenom X4 2.8GHz und der SSE2 App.
nice ;)

hochgerechnet auf 3.2Ghz ergeben das ca. 780 Sekunden.

Opteron
08.12.2008, 14:48
Der Unterschied zwischen der Betreiber-App 06 und Betreiber-App 07 sind gute 10% Speed, dafür wird das Ergebnis ab der 15. Stelle nach dem Komma ungenauer [was vorher nicht der Fall war].
Ähh .. war das bisherige Mantra nicht, dass Genauigkeit das Allerwichtigste wäre :w_verwirrt:

JKuehl
08.12.2008, 14:51
ca 2000 Sekunden für einen Pentium M 1.6 GHZ mit SSE2
http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57588732

dafür gabs 41.09 Credits macht am Tag 1737 Credits.

MIB2004
08.12.2008, 14:53
Gibt es auch schon eine optimierte App. auf Basis des neuen Codes V. 07 für Linux64 bit, oder kann die vielleicht jemand kompilieren? Bin leider nicht dazu in der Lage :-(

J-R
08.12.2008, 14:53
wie sinnvoll ist den die nutzung von SSE bzw. SSE2.

die 3 prozessoren die ich nutze (Northwood HT, Phenom, X2) unterstützen ja beides.

Twodee
08.12.2008, 14:56
Ähh .. war das bisherige Mantra nicht, dass Genauigkeit das Allerwichtigste wäre :w_verwirrt:

ja das war es.
.
EDIT :
.

wie sinnvoll ist den die nutzung von SSE bzw. SSE2.

die 3 prozessoren die ich nutze (Northwood HT, Phenom, X2) unterstützen ja beides.
falls es geschwindigkeitsunterschiede geben sollte, dann ist SSE2 vorzuziehen (gegenüber der normalen app), die SSE-Variante habe ich nur für die PIII und A-XP Benutzer kompiliert.
.
EDIT :
.

Gibt es auch schon eine optimierte App. auf Basis des neuen Codes V. 07 für Linux64 bit, oder kann die vielleicht jemand kompilieren? Bin leider nicht dazu in der Lage :-(
für linux habe ich leider nix im angebot :(

[die windows-app basiert auf der 07er App]

Cherry
08.12.2008, 14:58
ca 890 Sekunden mit Phenom X4 2.8GHz und der SSE2 App.
Soll ich mal erzählen, das der E8500 (@stock), der hier auch noch steht, 7 Stück "stripe_86" in jeweils 380 Sekunden durchgehauen hat? So ganz normal ist das aber nicht, oder? Anderen WUs liegen bei ca. 720 sec.


Cherry

Twodee
08.12.2008, 15:00
Soll ich mal erzählen, das der E8500 (@stock), der hier auch noch steht, 7 Stück "stripe_86" in jeweils 380 Sekunden durchgehauen hat? So ganz normal ist das aber nicht, oder? Anderen WUs liegen bei ca. 720 sec.


Cherry

es gibt große und kleine WUs, die kleinen haut mein Q6600 in 500 Sekunden durch, bekommt aber dafür weniger punkte als mit der großen Wu.

MIB2004
08.12.2008, 15:03
für linux habe ich leider nix im angebot :(

[die windows-app basiert auf der 07er App]

Ok, Danke, vielleicht macht jemand noch eine :w_zipfel:

Deine Windows App. mit SSE2 läuft bei mir bis jetzt klaglos auf dem N270 Netbook ;D

indiana_74
08.12.2008, 16:01
Hab mal meinen Apple G5 mit Mac OS X 10.5 in den C-Index eingetragen.

Die Werte stammen von der offiziellen 07. App. und demnach schafft er etwa 1.7k mit seinen beiden Kernen. Das ist auf jeden Fall mehr als noch vor dem Beginn der Optimierungen.

Ich hätte da gern eine Altivec Version :w_zipfel:

Gipsel
08.12.2008, 16:36
Die neue Version (SSE2) läuft auf XP64 auf dem Core i7 @ 3.6GHz. Laufzeiten kommen gleich.

Edit:
stripe86 ohne HT: ~625s

stripe86 mit HT: ~775s (8 WUs gleichzeitig!)
stripe79 mit HT: ~755s

Würde es volle credits geben, hätte man damit ~35k/Tag, jetzt "nur" etwa 20k.

Twodee
08.12.2008, 16:51
Die neue Version (SSE2) läuft auf XP64 auf dem Core i7 @ 3.6GHz. Laufzeiten kommen gleich.

Edit:
stripe86 ohne HT: ~625s
mhm dann ist er proMhz gesehen gleich auf mit einem Core2 45nm - ohne HT.

[MTB]JackTheRipper
08.12.2008, 16:57
Ich bin mal auf die Wert mit HT gespannt.

Dann wieder ein paar VMs, und das ist wieder ein kleines Creditmonster.

Gipsel
08.12.2008, 17:01
mhm dann ist er proMhz gesehen gleich auf mit einem Core2 45nm - ohne HT.
Das ist mir auch aufgefallen. Schon bei der SETI-Diskussion habe ich ja eingeworfen, daß das etwa das Niveau der 45nm Core2 ist. Bei anderen Projekten (http://www.planet3dnow.de/vbulletin/showthread.php?p=3801328#post3801328) scheint das ähnlich zu sein. Allerdings bringt HT ziemlich viel. Insbesondere bei MW. Wodran das nun wieder liegen mag :]

Twodee
08.12.2008, 17:18
Das ist mir auch aufgefallen. Schon bei der SETI-Diskussion habe ich ja eingeworfen, daß das etwa das Niveau der 45nm Core2 ist. Bei anderen Projekten (http://www.planet3dnow.de/vbulletin/showthread.php?p=3801328#post3801328) scheint das ähnlich zu sein. Allerdings bringt HT ziemlich viel. Insbesondere bei MW. Wodran das nun wieder liegen mag :]
ach, wenn ht 65% bringen soll, wie du woanders geschrieben hattest, dann lohnt es sich voll, is ja wie ein geschenkter high-oced dualcore for free :D

KGBerlin
08.12.2008, 17:19
Sag mal einer muss man die Datei noch umbenennen oder hab ich was überlesen ?
Bei mir heisst die astronomy.exe aber sollte die nicht Milkyway...exe heißen ?

Bei mir passiert das hier:
09.12.2008 17:16:34|Milkyway@home|Sending scheduler request: To fetch work. Requesting 78450 seconds of work, reporting 3 completed tasks
09.12.2008 17:16:39|Milkyway@home|Scheduler request succeeded: got 3 new tasks
09.12.2008 17:16:41|Milkyway@home|Started download of nm_stripe82_r5_search_parameters_52178_1228752456
09.12.2008 17:16:41|Milkyway@home|Started download of nm_stripe79_r7_search_parameters_52142_1228752456
09.12.2008 17:16:43|Milkyway@home|Finished download of nm_stripe82_r5_search_parameters_52178_1228752456
09.12.2008 17:16:43|Milkyway@home|Finished download of nm_stripe79_r7_search_parameters_52142_1228752456
09.12.2008 17:16:43|Milkyway@home|Started download of nm_stripe79_r7_search_parameters_52144_1228752456
09.12.2008 17:16:44|Milkyway@home|Finished download of nm_stripe79_r7_search_parameters_52144_1228752456
09.12.2008 17:17:42|Milkyway@home|Sending scheduler request: To fetch work. Requesting 90720 seconds of work, reporting 3 completed tasks
09.12.2008 17:17:47|Milkyway@home|Scheduler request succeeded: got 3 new tasks
09.12.2008 17:17:49|Milkyway@home|Started download of nm_stripe82_r6_search_parameters_52226_1228752458
09.12.2008 17:17:49|Milkyway@home|Started download of nm_stripe82_r6_search_parameters_52255_1228752459
09.12.2008 17:17:52|Milkyway@home|Finished download of nm_stripe82_r6_search_parameters_52226_1228752458
09.12.2008 17:17:52|Milkyway@home|Finished download of nm_stripe82_r6_search_parameters_52255_1228752459
09.12.2008 17:17:52|Milkyway@home|Started download of nm_stripe82_r6_search_parameters_52228_1228752458
09.12.2008 17:17:54|Milkyway@home|Finished download of nm_stripe82_r6_search_parameters_52228_1228752458
09.12.2008 17:18:51|Milkyway@home|Sending scheduler request: To fetch work. Requesting 90720 seconds of work, reporting 3 completed tasks
09.12.2008 17:18:56|Milkyway@home|Scheduler request succeeded: got 3 new tasks
09.12.2008 17:18:58|Milkyway@home|Started download of nm_stripe82_r7_search_parameters_52325_1228752461
09.12.2008 17:18:58|Milkyway@home|Started download of nm_stripe82_r7_search_parameters_52329_1228752461
09.12.2008 17:18:59|Milkyway@home|Finished download of nm_stripe82_r7_search_parameters_52325_1228752461
09.12.2008 17:18:59|Milkyway@home|Finished download of nm_stripe82_r7_search_parameters_52329_1228752461
09.12.2008 17:18:59|Milkyway@home|Started download of nm_stripe82_r7_search_parameters_52326_1228752461
09.12.2008 17:19:00|Milkyway@home|Finished download of nm_stripe82_r7_search_parameters_52326_1228752461
09.12.2008 17:20:02|Milkyway@home|Sending scheduler request: To fetch work. Requesting 90720 seconds of work, reporting 3 completed tasks
09.12.2008 17:20:07|Milkyway@home|Scheduler request succeeded: got 3 new tasks
09.12.2008 17:20:09|Milkyway@home|Started download of nm_stripe86_r6_search_parameters_52390_1228752462
09.12.2008 17:20:09|Milkyway@home|Started download of nm_stripe86_r6_search_parameters_52409_1228752463
09.12.2008 17:20:10|Milkyway@home|Finished download of nm_stripe86_r6_search_parameters_52390_1228752462
09.12.2008 17:20:10|Milkyway@home|Finished download of nm_stripe86_r6_search_parameters_52409_1228752463
09.12.2008 17:20:10|Milkyway@home|Started download of nm_stripe86_r6_search_parameters_52405_1228752463
09.12.2008 17:20:11|Milkyway@home|Finished download of nm_stripe86_r6_search_parameters_52405_1228752463

und in der Aufgabenliste steht hinter der datei: Herrunterladen fehlgeschlagen.

Gipsel
08.12.2008, 17:39
ach, wenn ht 65% bringen soll, wie du woanders geschrieben hattest, dann lohnt es sich voll, is ja wie ein geschenkter high-oced dualcore for free :D
Die 65% sind der Extremfall bei MW. Üblicherweise sollte das niedriger liegen. Beispiele:

Spin: 35%
Einstein: ~35-40%
QMC: ~50%

Wenn man sich das so ansieht, scheint Spin doch gar nicht so schlecht programmiert zu sein. Zumindest treten keine übermäßig großen Blasen in der Pipeline auf, die dann mit HT etwas gefüllt werden können.

Aber wie man an den Zahlen sieht, lohnen tut es sich auf jeden Fall.
.
EDIT :
.

JackTheRipper;3802875']Ich bin mal auf die Wert mit HT gespannt.

Dann wieder ein paar VMs, und das ist wieder ein kleines Creditmonster.
Irgendwer (Crunch3r :]) macht schon sowas Ähnliches. Die WUs (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57604609) (edit: 269s, verschwindet doch gleich wieder) werden da ziemlich fix berechnet. Und ob die 64 CPUs in dem System stimmen, zweifle ich doch mal glatt an. Da sind also noch massig Reserven.

Davidan
08.12.2008, 17:42
Hier mal meine Vergleichswerte StandardApp 0.7 : Optimierte App 0.7

T9500: vorher ca. 3300s/WU
jetzt ca. 1045s/WU

E6400: vorher ca. 4080s/WU
jetzt ca. 1320s/WU

Die Werte für den Q6600 poste ich wenn ich daheim bin und die App ausgetausch hab.

Aber das ist immer noch eine Beschleunigung um den Faktor 3 für meine Kisten.

heavy-Ions@boinc
08.12.2008, 18:04
Irgendwer (Crunch3r :]) macht schon sowas Ähnliches. Die WUs (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57604609) werden da ziemlich fix berechnet. Und ob die 64 CPUs in dem System stimmen, zweifle ich doch mal glatt an. Da sind also noch massig Reserven.
Du hast nicht zufällig ein makefile für mich für die linux kompilierung?
configure, make und make install kann ich nämlich noch in die konsole tippen, alles andere ist noch "neu" für mich ;)

edit.
ach quatsch, brauch ich ja noch gar nicht solange ich nicht die "optimierten" quellen habe.

koschi
08.12.2008, 18:17
Irgendwer (Crunch3r :]) macht schon sowas Ähnliches. Die WUs (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57604609) werden da ziemlich fix berechnet. Und ob die 64 CPUs in dem System stimmen, zweifle ich doch mal glatt an. Da sind also noch massig Reserven.

Da hat sich einer nen BOINC-Client selbst kompiliert und schon hat man 64 CPUs...
Ansonsten kauft keine Firma ne Büchse mit 64CPUs und nur 16GB RAM. Statt einem Viertel der CPUs ist da eher 4x soviel angesagt...

snicK
08.12.2008, 18:19
mein Q6600 auf 2,4GHz braucht 1.173sec für eine Wu und bekommt 35pkt.

gruenmuckel
08.12.2008, 18:22
Athlon 64 4000+ @ 2640 mhz braucht ~970 Sekunden und bekommt 29 Credits.
SSE2-App

Hmm, mein C2D E6300@2800mhz braucht 1170 Sekunden und bekommt 35,5 Credits.
Bin grad nicht sicher ob ich die SSE2-App schon drauf habe oder nicht. Was meint ihr?

Gipsel
08.12.2008, 18:24
mein Q6600 auf 2,4GHz braucht 1.173sec für eine Wu und bekommt 35pkt.
Ein Phenom X4 @ 2.57GHz benötigt etwa 900s exakt 885s und bekommt dementsprechend weniger credits. Das Limit läßt mal wieder grüßen.

@Twodee: Siehst Du was ich damit meinte, daß AMDs hier schneller sind? Keine Ahnung, warum das mit der 64Bit stock-App anders war *noahnung* Bei Deiner Version sind die 45nm Core2 aber eine ganze Ecke schneller als die 65nm Teile. Eine Ahnung, woran das liegt?

HGW
08.12.2008, 18:27
Q6600 3,0 GHz

886,78 sec.....26,60c
891,05 sec.....26,73c
893,84 sec.....26,82c

KGBerlin
08.12.2008, 18:48
Schön das es bei euch geht. Mir zerballert er jede WU noch vor dem Download und nun hab ich die Daily Quota von 220 überschritten *rofl*

Gipsel
08.12.2008, 19:01
Schön das es bei euch geht. Mir zerballert er jede WU noch vor dem Download und nun hab ich die Daily Quota von 220 überschritten *rofl*
Dann versuche mal morgen BOINC wirklich komplett zu beenden, d.h. den Manager aus (auch im Tray beenden) und den BOINC-Service über Start -> Systemsteuerung -> Verwaltung -> Dienste beenden (falls Service- oder protected Installation). Dann die .exe und app_info.xml in das Milkyway-Verzeichnis kopieren (nichts umbenennen oder löschen!). Danach BOINC wieder starten. Der Manager sollte dann im Meldungsfenster irgendwas von "anonymous platform" erzählen und die alte .exe automatisch löschen.

Außerdem benutzt Du doch hoffentlich nicht die SSE2-Version auf einem AthlonXP oder so. Aber manchmal ist man ja irgendwie betriebsblind ;)
.
EDIT :
.
Ich bin ja mal gespannt, wann die anderen Teams das mitkriegen *suspect*
Twodees Version ist ja im Prinzip für jedermann verfügbar. Man muß nur den richtigen Link hier im Thread finden.

snicK
08.12.2008, 19:03
Hab dann auch mal ein Wert für einen Core2 Duo CPU T5250 @ 1.50GHz: 1.807sec dafür gibt es 39.85pkt.

TAL9000
08.12.2008, 19:45
Ich bin ja mal gespannt, wann die anderen Teams das mitkriegen *suspect*
Twodees Version ist ja im Prinzip für jedermann verfügbar. Man muß nur den richtigen Link hier im Thread finden.
Wenn ich den Output der anderen richtig interpretiere war Crunch3r schneller beim Coden und die anderen beobachten entsprechend uns bzw. haben ihre eigenen Leute dran.

TAL9000

[MTB]JackTheRipper
08.12.2008, 21:02
So ein modifizierter BOINC Client mit CPU Anzahl *= 16 hat aber auch was ;)

indiana_74
08.12.2008, 21:37
JackTheRipper;3803145']So ein modifizierter BOINC Client mit CPU Anzahl *= 16 hat aber auch was ;)

Das ist kein Problem, wir hatten das im GPUGrid Thread mal, da gibt es in der normalen Boinc Version eine Möglichkeit das einzustellen.
.
EDIT :
.
Man erstellt einfach ein Datei Namens cc_config.xml im Boinc Verzeichnis.

Inhalt



<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
<max_file_xfers_per_project>8</max_file_xfers_per_project>
<max_file_xfers>16</max_file_xfers>
<ncpus>6</ncpus>
</options>
</cc_config>

Der Parameter "ncpus" gibt die Anzahl der Cores an :w_grins:
.
EDIT :
.
hmmm, stelle gerade fest das es mit dem 6.4.4 Client nicht geht, vielleicht haben die den Parameter wieder raus genommen :(

Davidan
08.12.2008, 22:20
Hier noch mal wie versprochen die Werte für meinen Q6600:

Vorher: ca 3540s/WU
Jetzt: ca. 1130s/WU

Also auch über 3x schneller wie vorher.

Danke Twodee :)

gruenmuckel
08.12.2008, 22:47
Duron 900 6330 Sekunden, 40 Credits, Twodees non-SSE-App
Athlon XP @1150mhz (FSB100) 3900 Sekunden, 40 Credits, Twodees SSE-APP

JagDoc
08.12.2008, 22:59
Atom330 HT; XP64, SSE2-Vers.

nm_stripe86, 2,675.33sec, 41,09Credit

nm_stripe82, 5,010.92sec, 39.85Credit

cu JagDoc

J-R
08.12.2008, 23:09
hmm,
Northwood HT@3.06Ghz - 999sec - 30cr.
Phenom@2.05Ghz - 1130sec - 34cr.
X2@2.3@2,33Ghz - 1130sec - 34cr.

alle liefen mit der SSE2 version.

das der Northwood so schnell war irritiert mich ein wenig.
bisher war noch nie eine wu schneller fertig als auf den beiden anderen rechnern, trotz der mehr Ghz und zumal er ja kein echter mehrkerner ist.
das muss ich mal ein wenig beobachten und mit den verschiedenen versionen testen.

edit:
da muss was faul gewesen sein.
in den results ist die rede von 41cr grantet, die ich aber nicht bekommen habe.
leider quält sich der rechner noch mit ein paar simap rum und Poem und SL laufen ja auch noch mit.
noch so was komisches, das ist der einzige rechner der sich ausreichend mit SL wu eindeckt.

KGBerlin
09.12.2008, 11:14
nm_stripe86_r8_9_1228808847_0_0 > 489sek
nm_stripe82_r8_75_1228808493_0_0 > 760sek
nm_stripe82_r8_79_1228808501_0_0 > 767sek
nm_stripe82_r8_80_1228808502_0_0 > 776sek

Auf einem X4 9550 @ Stock mit der SSE2 ;)

Nero24.
09.12.2008, 11:22
danke. verstehe ich nicht wieso die dinger kaputtgehen Lädst Du's vielleicht aus Versehen als ASCII hoch statt als Binary? Passiert ja gerne mal aus Versehen bei FTP-Transfers ;)

Twodee
09.12.2008, 11:24
nm_stripe86_r8_9_1228808847_0_0 > 489sek
nm_stripe82_r8_75_1228808493_0_0 > 760sek
nm_stripe82_r8_79_1228808501_0_0 > 767sek
nm_stripe82_r8_80_1228808502_0_0 > 776sek

Auf einem X4 9550 @ Stock mit der SSE2 ;)
nicht schlecht ;)
.
EDIT :
.

Lädst Du's vielleicht aus Versehen als ASCII hoch statt als Binary? Passiert ja gerne mal aus Versehen bei FTP-Transfers ;)
mhm, die einstellungen stehen auf auto. ich tippe aber auch auf den ftp-client, hatte vorher einen anderen (testversion) und dieser lief.

DerRob
09.12.2008, 15:04
setze mal deinen workbuffer auf 10 Tage, hast du auch noch andere projekte auf der maschine am start?
hab momentan noch WCG als backup laufen, aber auch deaktivieren bringt nix. den workbuffer hoch setzen funktioniert auch nicht, die meldung "Requesting XYZ seconds of work" geht dann zwar hoch, aber neue WUs gibts trotzdem nicht.
ich hab ihn jetzt einfach mal laufen lassen, und heute morgen hat er sich erstmal die standard-applikation und gleich ein paar WUs gezogen. momentan hat er zwar noch ein paar WUs auf "lager", aber inzwischen bekomme ich schon wieder eine ähnliche meldung:

09.12.2008 14:55:37|Milkyway@home|Sending scheduler request: To fetch work. Requesting 24258 seconds of work, reporting 0 completed tasks
09.12.2008 14:55:42|Milkyway@home|Scheduler request succeeded: got 0 new tasks
09.12.2008 14:55:42|Milkyway@home|Message from server: No work sent
09.12.2008 14:55:42|Milkyway@home|Message from server: (reached per-CPU limit of 8 tasks)

immerhin ist das limit jetzt schon bei 32 WUs, statt der 4 WUs gestern... :]

edit: jetzt hat er sich zwischenzeitlich mal wieder eine WU abgeholt. und jetzt weiß ich auch, was da passiert. scheinbar ist mein 2-tage-bunker schon zu groß, ich bekomme nämlich nicht mehr als 8 WUs pro core gleichzeitig, erst wenn ich eine WU abliefere, gibts wieder eine neue.

Big Blue
09.12.2008, 15:57
ich bekomme nämlich nicht mehr als 8 WUs pro core gleichzeitig

Das ist die Aktuelle Grenze vom Projekt.
Mehr geben die nicht raus

Twodee
09.12.2008, 18:55
Ich habe jetzt ein paar Standardfunktionen (sin/cos/exp) durch SSE2-Routinen ersetzt und komme mit einem 3.2Ghz 45nm von 722 auf gut 500 Sekunden für die R6-WUs

Gipsel
09.12.2008, 19:16
Ich habe jetzt ein paar Standardfunktionen (sin/cos/exp) durch SSE2-Routinen ersetzt und komme mit einem 3.2Ghz 45nm von 722 auf gut 500 Sekunden für die R6-WUs
Vielleicht finde ich heute Abend mal Zeit mir das anzuschauen. Mal sehen, wo ich ohne solche Spielereien lande ;D

PS:
Eigentlich sollte nur exp was bringen. sin/cos werden ja nicht mehr so häufig aufgerufen, oder?

indiana_74
09.12.2008, 19:17
Ich habe jetzt ein paar Standardfunktionen (sin/cos/exp) durch SSE2-Routinen ersetzt und komme mit einem 3.2Ghz 45nm von 722 auf gut 500 Sekunden für die R6-WUs

Download? Link? :w_zipfel:

TiKu
09.12.2008, 19:20
Wieviel langsamer ist denn die derzeit aktuelle offizielle App ggü. der optimierten?

Twodee
09.12.2008, 19:56
Vielleicht finde ich heute Abend mal Zeit mir das anzuschauen. Mal sehen, wo ich ohne solche Spielereien lande ;D

PS:
Eigentlich sollte nur exp was bringen. sin/cos werden ja nicht mehr so häufig aufgerufen, oder?

am meisten bringt es was bei exp, sin und cos ist gut 2,5 mal schneller als exp.
ich verwende immer noch den ms-compiler, und es sind nur SSE(1) routinen [keine SSE(2)]
.
EDIT :
.

Wieviel langsamer ist denn die derzeit aktuelle offizielle App ggü. der optimierten?

07 standard app ~ 30 Minuten, meine derzeitige ~8 Minuten [unter winxp 64]
.
EDIT :
.

Download? Link? :w_zipfel:

gibts noch nicht. bin noch am testen
.
EDIT :
.
@Gipsel: die SSE(x) befehle gibts z.B. hier: http://msdn.microsoft.com/en-us/library/4atda1f2(VS.80).aspx

Gipsel
09.12.2008, 21:46
@Gipsel: die SSE(x) befehle gibts z.B. hier: http://msdn.microsoft.com/en-us/library/4atda1f2(VS.80).aspx
Mit den SSE-Intrinsics kann man sich austoben, wenn man alles andere abgegrast hat. Außerdem ist der Code dann nicht mehr so richtig portabel. Das ist dann ja langsam richtiges Optimieren *buck* Da halte ich mich raus ;)
Just my 0.02€
.
EDIT :
.

Ich habe jetzt ein paar Standardfunktionen (sin/cos/exp) durch SSE2-Routinen ersetzt und komme mit einem 3.2Ghz 45nm von 722 auf gut 500 Sekunden für die R6-WUs
So, habe gerade meine allererste Version kompiliert. Habe erstmal nur 4 Zeilen geändert ;D
Und was soll ich sagen, ist irgendwie schneller als Deine erste Version :P
Zumindest auf dem Core i7@3.6GHz benötigt der jetzt statt 750 - 775 Sekunden (je nach WU Serie) nur etwa 695s (mit HT, also 8WUs gleichzeitig). Und das größte ist: die CPU-Temp beträgt statt 82°C nur noch 78°C. Ist also auch noch eine Stromspar-App *buck*
Okay, ist unfair, ich habe den Intel-Compiler benutzt, aber dafür nur /O2 ;)
Mal sehen, ob /O3 überhaupt was bringt (habe ich bisher nie genutzt).

Edit:
Auf einem PhenomX4@2.57GHz benötigt eine WU jetzt so 715s. Auf dem Core i7 sieht es fast so aus, als wäre /O3 langsamer als /O2 (755s, genau wie Deine). Wie geht denn das? Muß ich mal auf dem Phenom nochmal überprüfen.

Edit2:
Hmm, auf dem Phenom bringt /O3 etwa 10% Gewinn, auf dem Core i7 aber 10% Verlust. Brauche wohl doch noch den neuen ICC11, der kennt ja schon den Nehalem. Offensichtlich verhält der sich bei einigen Optimierungen anders.
Aber Ist doch mal lustig. Da schafft es Intel doch glatt, mit ihrem Compiler besser auf einen AMD zu optimieren als auf die brandneue eigene CPU *buck*

Edit3:
Hattest Du nicht mal was von Speicherlecks erzählt? Irgendwie scheint mir das so, als wäre das in der offiziellen Version 0.07 nicht behoben worden :[
Hast Du da selber Hand angelegt?
Ist wohl das "set_probability_constants" in calculate_likelyhoods. Habe mich schon gewundert, wofür er mit einem Mal für eine Sekunde deutlich über 100MB oder so belegt. So wird mir das natürlich klar, für jeden Stern 240Bytes allozieren und danach nicht wieder freigeben, echt clever!

KGBerlin
09.12.2008, 22:14
Kleine Frage nebenbei:

Wie bekomm ich den Boincmanager so eingestellt das der PC den QnC nicht verlässt ?
Wenn ich bei "Nutze höchstens XXX % des Prozessors" was anderes als 100 z.B. 10 eintippe bleibt er zwar auf 1000Mhz rechnet aber auch nicht sondern springt alle paar Sekunden auf seine 1900Mhz macht eine Sekunde Rechenzeit und geht wieder in den C&Q.
Der soll aber nur im CnQ rechnen und das durchgehend oder geht das nicht ? :]

Twodee
09.12.2008, 22:25
Mit den SSE-Intrinsics kann man sich austoben, wenn man alles andere abgegrast hat. Außerdem ist der Code dann nicht mehr so richtig portabel. Das ist dann ja langsam richtiges Optimieren *buck* Da halte ich mich raus ;)
Just my 0.02€
.
EDIT :
.

So, habe gerade meine allererste Version kompiliert. Habe erstmal nur 4 Zeilen geändert ;D
Und was soll ich sagen, ist irgendwie schneller als Deine erste Version :P
Zumindest auf dem Core i7@3.6GHz benötigt der jetzt statt 750 - 775 Sekunden (je nach WU Serie) nur etwa 695s (mit HT, also 8WUs gleichzeitig). Und das größte ist: die CPU-Temp beträgt statt 82°C nur noch 78°C. Ist also auch noch eine Stromspar-App *buck*
Okay, ist unfair, ich habe den Intel-Compiler benutzt, aber dafür nur /O2 ;)
Mal sehen, ob /O3 überhaupt was bringt (habe ich bisher nie genutzt).

;) und wieviel bleibt davon übrig wenn du ohne Intel-Compiler arbeitest?



Edit:
Auf einem PhenomX4@2.57GHz benötigt eine WU jetzt so 715s. Auf dem Core i7 sieht es fast so aus, als wäre /O3 langsamer als /O2 (755s, genau wie Deine). Wie geht denn das? Muß ich mal auf dem Phenom nochmal überprüfen.

Ich hab auch die Erfahrung gemacht wenn ich z.b SSE2 code für SQRT verwende wird die App an einige gewissen Stellen langsamer als ohne :o


Edit2:
Hattest Du nicht mal was von Speicherlecks erzählt? Irgendwie scheint mir das so, als wäre das in der offiziellen Version 0.07 nicht behoben worden :[
Hast Du da selber Hand angelegt?
hab ich nicht überprüft ob die das in der 07er korriert haben, falls nicht dann dürftest du i nder debugversion ein 1MB großeses stderror-file bekommen ;)
Viel Spaß beim fixen, der möchtegern-programmiere hat da einen übelsten fehler im array welches auf ein zeiger-array zeigt *chatt*

btw.: derzeit ohne intelcompiler bei ~484 Sekunden, bei 3.2GHz.

Gipsel
09.12.2008, 22:45
;) und wieviel bleibt davon übrig wenn du ohne Intel-Compiler arbeitest?
Auf den AMDs nimmt sich das nicht viel. Die Intels leiden etwas (aber auch nicht wirklich stark).
Ich habe ja nicht umsonst erwähnt, daß bei meiner Version die CPU-Temps deutlich niedriger sind als bei Deiner (auch niedriger als bei der offiziellen). Ich mache einfach weniger in der gleichen Zeit ;)


hab ich nicht überprüft ob die das in der 07er korriert haben, falls nicht dann dürftest du i nder debugversion ein 1MB großeses stderror-file bekommen ;)
Viel Spaß beim fixen, der möchtegern-programmiere hat da einen übelsten fehler im array welches auf ein zeiger-array zeigt *chatt*

Yup, etwa 1.1MB. Aber aufgefallen ist mir das im Taskmanager. Ganz am Ende der WU belegt er dann mit einem Mal ziemlich viel.
Das mit dem Fixen lasse ich erstmal. Ich habe in meinen Kisten genügend Speicher drin :P
Aber das mit den Arrays sah mir beim ersten drüberschauen sowieso etwas unübersichtlich aus. Also bei der 1.22er habe ich weniger mitgenommen (das waren auch nur zwei eindimensionale Arrays) und das wäre wahrscheinlich trotzdem schneller (die 0.07 speichert auch unsinnige Werte zwischen, mit denen dann noch gerechnet wird).


btw.: derzeit ohne intelcompiler bei ~484 Sekunden, bei 3.2GHz.Weiter so! Laut Profiling machen bei mir exp- Aufrufe knapp 50% der Laufzeit aus. Wenn das über 60% sind, fange ich auch mit SSE-Intrinsics an ;)

Habe leider bloß wirklich keine Zeit. Deswegen bleibt es bei mir erstmal auf dem Stand Deiner ersten Version.

Twodee
10.12.2008, 08:57
Seit gestern-(Abend) scheint es eine neue WU-Serie zu geben: FR und ER. Wie lange dauern die bei euch so?

Caipi
10.12.2008, 09:04
Moin
auf meinem 6600 @ 3200 ~810 - 830 sec

auf meinem X2 @ 2500 ~1020 - 1050 sec

TAL9000
10.12.2008, 10:58
Kleine Frage nebenbei:

Wie bekomm ich den Boincmanager so eingestellt das der PC den QnC nicht verlässt ?
Wenn ich bei "Nutze höchstens XXX % des Prozessors" was anderes als 100 z.B. 10 eintippe bleibt er zwar auf 1000Mhz rechnet aber auch nicht sondern springt alle paar Sekunden auf seine 1900Mhz macht eine Sekunde Rechenzeit und geht wieder in den C&Q.
Der soll aber nur im CnQ rechnen und das durchgehend oder geht das nicht ? :] Wie wäre es mit nen extra Thread dafür, ggf. im Prozessor Forum (?). Würde mich nämlich auch interessieren, aber für SpeedStep bei einen N270 Atom. Oder dieses Proggi verwenden... wenn mir nur der Name einfallen würde... da gab es einen Thread dazu: XXX, das bessere CnQ. Bin an der Arbeit, da ist mein Hirn auf Suspend... ;D

TAL9000

J-R
10.12.2008, 11:18
das war dieser thread http://www.planet3dnow.de/vbulletin/showthread.php?t=336713&highlight=crystal

aber ich lehne mich mal aus dem fenster und sage CnQ minimal + Boinc, das funktioniert nicht.

man kann über diese tools (CrystalCpuId, RMClock) nur ein maximum vorgeben, das dann aber auch für das normale arbeiten gilt. es gibt da zwar die möglichkeit verschiedene profile anzulegen, diese muß man dann aber manuell immer passend zur aktuellen aktivität des users auswählen.

@KGBerlin, beim crunchen verläßt die cpu den CnQ modus nicht, aber boinc benutzt immer den überschuß zwischen "Aktuell für Software benötigt <-> Maximum der CPU"
da sind wir ja bei dem thema das boinc aus einer zeit stammt als die rechner immer mit voller leistung liefen ohne das diese wirklich benötigt wurde und von CnQ bzw. SpeedStep nichts in sicht war.
damals war es sinnvoll die sowieso verbrauchte energie irgendwie in was produktives umzusetzen.
heute wäre es ökonomisch und ökologisch nicht zu crunchen, um die energie einsparung im Idle zu haben, aber wer will das schon.

Twodee
10.12.2008, 12:31
WU-Zeitenvergleich: ER2-WUs

Core2Quad (45nm) 3.2Ghz ~ 590 Sekunden [neue SSE handoptimierte App]

Core2Quad (45nm) 3.6Ghz ~ 640 Sekunden [alte optimierte App]

d.h. der um 400Mhz langsamere Quad ist um 50 Sekunden schneller pro WU ;D

Sabroe SMC
10.12.2008, 12:41
WU-Zeitenvergleich: ER2-WUs

Core2Quad (45nm) 3.2Ghz ~ 590 Sekunden [neue SSE handoptimierte App]

Core2Quad (45nm) 3.6Ghz ~ 640 Sekunden [alte optimierte App]

d.h. der um 400Mhz langsamere Quad ist um 50 Sekunden schneller pro WU ;D
Scheint ja gut zu funktionieren;D

Könntest Du einen Link hinterlassen?

DerRob
10.12.2008, 14:58
ähm, ist das normal, läuft twodees optimierte (sse2-) app nicht richtig, oder hab ich evtl. ein paar faule WUs erwischt?

http://s11.directupload.net/images/081210/6m55d5kg.png (http://www.directupload.net)

naja, mal sehen, wie viele credits die bringen...

achja, der rechner ist ein q6600 @default mit vista x32

KGBerlin
10.12.2008, 15:26
das war dieser thread [url]....

@KGBerlin, beim crunchen verläßt die cpu den CnQ modus nicht, aber boinc benutzt immer den überschuß z....
heute wäre es ökonomisch und ökologisch nicht zu crunchen, um die energie einsparung im Idle zu haben, aber wer will das schon.

Merci ;)
Dann läuft er halt auf 100%. soviel frist dr BE ja nun auch nicht. Obwohl ich ihn bisher mit seinen Aufgaben, TV und Video noch nie aus dem CnQ wecken konnte ^^
So genug OT *suspect*

Der BE - 2300 nimmt bei XP 32bit und der optimierten SSE2 zwischen 1380 und 1,597 sek.
Zwischendurch auch mal 2 mit 639sek ( nm_stripe79_er2_562_1228898558 ) und 743sek ( nm_stripe86_fr1_4923_1228905376_1 ) da weiß ich aber nicht warum. Andere WU ?

Edit:
Scheinen die WU zu sein nach denen Twodee fragte ;D

DerRob
10.12.2008, 15:38
Edit:
Scheinen die WU zu sein nach denen Twodee fragte ;D
das sind aber nur die 2 WUs gewesen, die so lange gebraucht haben, alle anderen er2 und fr2 werden in ~18 minuten durchgerechnet...

inzwischen sind die beiden WUs auch durch (57753346 (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57753346) und 57753286 (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=57753286)), und haben statt ~1100 sec etwa 9600 sec gebraucht. in den credits hat sich das aber nicht sonderlich bemerkbar gemacht, gab nur 39,85 credits statt der ~34 credits bei den anderen WUs. :-[

KGBerlin
10.12.2008, 17:52
Öhm, ich meinte mit meinem Edit meine WU aus meinem Posting ^^
Aber schön wenn es bei dir nun läuft ;D

Gipsel
11.12.2008, 17:04
Für alle unter Euch, die noch einen alten Rechner vom Schlage eines AthlonXP oder P3 rumstehen haben, gibt es hier (http://139.30.40.11/Milkyway_SSE.zip) eine App, die nur SSE voraussetzt. Für SSE2-fähige Rechner solltet ihr weiterhin Twodees App benutzen.

Für die neueren CPUs (mit SSE2) nimmt sich das nicht viel, aber der Intel-Compiler scheint auf die älteren CPUs besser zu optimieren als das von Twodee benutzte MSVS. Zumindest ist die Version bei mir auf einem AXP ~30% schneller als seine. Zu einem P3 kann ich noch nichts sagen, werde es aber auch noch testen und dann hier ergänzen.

Achtung: Ich habe aus Zeitgründen die Speicherleaks in der offiziellen App nicht behoben. Dies führt dazu, daß am Ende der WUs kurzzeitig (1-2 Sekunden lang) etwa 170MB belegt werden. Bei sehr knapp ausgestatten Rechnern könnte das ein Problem geben. Aber wenn die offizielle App läuft, sollte diese das auch tun.

Twodee
11.12.2008, 17:26
Von mir gibts auch etwas neues, allerdings nur für SS2 Rechner.

Hier findet ihr eine SS2-hand-optimierte Version des MW-Clients.

http://www.2shared.com/file/4437840/f43e8ff7/MW-SSE2.html


[45nm Quad@3.2Ghz ER und FR WUs unter 600 Sekunden]

[MTB]JackTheRipper
11.12.2008, 17:31
Wie wär's wenn ihr die neuesten Versionen ins Wiki stellt?

Twodee
11.12.2008, 17:33
JackTheRipper;3806291']Wie wär's wenn ihr die neuesten Versionen ins Wiki stellt?
Wir haben ein Wiki *buck*

TiKu
11.12.2008, 17:34
*glaubses* http://dc.planet3dnow.de/wiki/

J-R
11.12.2008, 23:46
Von mir gibts auch etwas neues, allerdings nur für SS2 Rechner.

Hier findet ihr eine SS2-hand-optimierte Version des MW-Clients.

http://www.2shared.com/file/4437840/f43e8ff7/MW-SSE2.html


[45nm Quad@3.2Ghz ER und FR WUs unter 600 Sekunden]

hab deine version mal eine zeitlang auf allen rechnern laufen lassen.

x2 und und phenom sind (grob geschätzt) 50-100sec schneller geworden.
der NorthwoodHT wurde aber bis zu 200sec langsamer.
wie gesagt grob geschätzt, aber doch irgendwie erkennbar. natürlich hab ich jetzt die wu nicht direkt verglichen, aber alle 3 rechner werden im etwa gleichen verhältnis mit den unterschiedlichen wu versorgt.
liegt vielleicht am compiler, da die schneller gewordenen AMD und der langsamere ein Intel ist.

im moment hab ich daher jetzt 2*Twodee und 1*Gipsel laufen.

Gipsel
12.12.2008, 01:06
hab deine version mal eine zeitlang auf allen rechnern laufen lassen.

x2 und und phenom sind (grob geschätzt) 50-100sec schneller geworden.
der NorthwoodHT wurde aber bis zu 200sec langsamer.
wie gesagt grob geschätzt, aber doch irgendwie erkennbar. natürlich hab ich jetzt die wu nicht direkt verglichen, aber alle 3 rechner werden im etwa gleichen verhältnis mit den unterschiedlichen wu versorgt.
liegt vielleicht am compiler, da die schneller gewordenen AMD und der langsamere ein Intel ist.

im moment hab ich daher jetzt 2*Twodee und 1*Gipsel laufen.
Wie soll ich denn das verstehen? Ist auf dem Northwood etwa meine SSE-Version schneller als Twodees SSE2-Version? Das kann ich kaum glauben.
Wahrscheinlich läßt Du auf dem Northwood Twodees erste SSE2-Version laufen, oder?
.
EDIT :
.
@Twodee:
Hast Du die News über die fehlerhaft rechnenden Applikationen bei MW gesehen? Ich hoffe mal, das betrifft keinen von uns. Habe deswegen extra nochmal eben gerade meine Version die mitgelieferten Test-WUs rechnen lassen.

Edit:
Entwarnung. Es betrifft wohl Crunch3r und Logan von SUSA.

PS:
Außerdem scheint Travis die Frage zu bewegen, ob mit den Zeitmessungen alles seine Ordnung hat *suspect*

J-R
12.12.2008, 08:30
da es ja keine versions nummern gibt kann ich das nur übers datum festmachen.

@Gipsel SSE2 vom 08.12.08 - 11:45
@Twodeee SSE2 vom 09.12.08 - 20:27

wenn es neuere versionen gibt ist das an mir vorbeigegangen.

Gipsel
12.12.2008, 09:22
da es ja keine versions nummern gibt kann ich das nur übers datum festmachen.

@Gipsel SSE2 vom 08.12.08 - 11:45
@Twodeee SSE2 vom 09.12.08 - 20:27

wenn es neuere versionen gibt ist das an mir vorbeigegangen.
Okay, von mir gibt es gar keine SSE2-Version. Werden also beides die von Twodee sein.

Nero24.
12.12.2008, 09:43
AMD Athlon XP 2400+
Twodee SSE = 2200 s
Gipsel SSE =1500 s :D
http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=36653

AMD Phenom X4 9600
Twodee SSE2 "alt" = 1050 s
Twodee SSE2 "neu" = 950 s :)
http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=28876

gruenmuckel
12.12.2008, 09:48
Momentan gibts keine WUs, oder?

J-R
12.12.2008, 09:51
Okay, von mir gibt es gar keine SSE2-Version. Werden also beides die von Twodee sein.

jetzt wo du es sagst...............
bin bei diesem versions und optionswirrwar wohl ganz durcheinander gekommen.
schande über mich.

auf jeden fall hab ich nochmals diese neue SSE2 version auf den intel geworfen und es scheint wirklich so das der die nicht mag.
schon die erste wu brauchte 100sec länger als die vorher langsamste und sie wurde zu 50% noch von der älteren app gerechnet.
mal noch ein paar komplett durchrechnen lassen, zur bestätigung.

@gruenmuckel, das es keine arbeit gibt liegt wohl an den besagten fehlerhaften apps.
offensichtlich wurde jetzt erstmal gestoppt bis geklärt ist wie man das umgeht bzw bereinigt.
da ist die begrenzung auf 8wu/core ganz sinnvoll, man kann ein projekt schnell stoppen und muss nicht tagelang auf die abbarbeitung der bunker warten.

Twodee
12.12.2008, 10:03
Also die erste SSE bzw SSE2 Version enthielten so gut wie keine SSE Optimierungen, da der MS-Compiler den Code nicht in dieser Form optimiert. Daher ist Gipsels "echte" SSE Version auch schneller als meine "unechte" SSE version ;) - Das gleiche müßte aber auch für die erste SSE2 Version gelten.

Die aktuelle SSE2-Version ist aber nachträglich von mir mit SSE1/SS2 routinen ausgestattet worden, diese läuft auf den X2, Intel 64nm Quads und besonders auf den Intel 45nm Quads schneller ab. Warum sie dem P4 nicht schmecken weiß ich nicht.

J-R
12.12.2008, 10:24
könnte es an einer intensiveren nutzung des caches liegen. ?
schließlich müssen sich die "2Kerne" das wenige vorhandene teilen.

der P4 ist in einen laptop eingebaut.
ich hab zwar die kühlung um einiges verbessert, wodurch er nicht mehr zum Throttln neigt, aber bei simap hab ich beobachtet das er es bei recht moderater temp immer noch ab und an tut.
hab das mit erhöhter cache nutzung und damit verbundenem temp peak, der aber zu kurz ist um ihn durch eine entsprechende software auszulesen in verbindung gebracht.

Twodee
12.12.2008, 10:48
könnte es an einer intensiveren nutzung des caches liegen. ?
schließlich müssen sich die "2Kerne" das wenige vorhandene teilen.

der P4 ist in einen laptop eingebaut.
ich hab zwar die kühlung um einiges verbessert, wodurch er nicht mehr zum Throttln neigt, aber bei simap hab ich beobachtet das er es bei recht moderater temp immer noch ab und an tut.
hab das mit erhöhter cache nutzung und damit verbundenem temp peak, der aber zu kurz ist um ihn durch eine entsprechende software auszulesen in verbindung gebracht.

also die "echte" SSE2 App nutzt die CPU besser aus, wodurch bei meinen Quads die Temp um 1-2 Grad ansteigt.

J-R
12.12.2008, 13:40
hab jetzt noch mal ein paar erkenntnisse für den P4.

alte SSE2 App: 1603 - 1922 sec.
neue SSE App: 2034 - 2433 sec.

also sogar deutlich mehr als die vormals "geschätzten" 200 sec.

die temperatur als ursache schließe ich auch mal aus.
die höchste temp von 62° erreiche ich mit 2* Spin.
die niedrigste liegt bei 58° mit 2* POEM.
bei MW (allein oder im mix) gab es nie mehr als 60°.


bleibt als ursache wohl wirklich nur der zu kleine cache und die tatsache das die handoptimierte SSE2 version ihn so intensiv nutzt, das er seinen eigentlichen zweck verfehlt.

oder hat jemand noch eine andere idee.

gibt es niemanden der auch einen P4 mit HT nutzt, der das irgendwie bestätigen kann.

Twodee
12.12.2008, 13:55
hast du noch WUs?

ich hab wieder eine schnellere Version fertig, die mehr vektorisiert ist.

Mein alter 65nm Quad mit 3Ghz schafft die er2 WUs in 346 Sekunden. Andere Rechner kann ich leider aus WU-Mangel nicht testen.

J-R
12.12.2008, 13:56
noch 4 stück + 2 angefangene

Twodee
12.12.2008, 13:57
http://www.file-upload.net/download-1311757/astronomy_sse2_app.exe.html

sollte mit der schneller sein. was auch der fall sein könnte ist das dein cache nicht mehr ausreicht.. die beiden letzten versionen arbeiten wieder mit größeren arrays.

Gipsel
12.12.2008, 14:06
hast du noch WUs?

ich hab wieder eine schnellere Version fertig, die mehr vektorisiert ist.

Mein alter 65nm Quad mit 3Ghz schafft die er2 WUs in 346 Sekunden. Andere Rechner kann ich leider aus WU-Mangel nicht testen.
Hoho!
Dann muß ich wohl mal bei Gelegenheit doch ein paar mehr Zeilen ändern um da einigermaßen mithalten zu können.

Dann hat sich ja wohl auch mein Vorhaben erledigt mal eine P4-Version zu kompilieren (/QxN). Die hätte J-R ja vielleicht weiterhelfen können. Aber bei dem Tempo Deiner Version dürfte sich das erübrigen.

Twodee
12.12.2008, 14:15
Hoho!
Dann muß ich wohl mal bei Gelegenheit doch ein paar mehr Zeilen ändern um da einigermaßen mithalten zu können.

Dann hat sich ja wohl auch mein Vorhaben erledigt mal eine P4-Version zu kompilieren (/QxN). Die hätte J-R ja vielleicht weiterhelfen können. Aber bei dem Tempo Deiner Version dürfte sich das erübrigen.

wie gesagt es sind nur er2 WUs, die sind von haus aus kürzer. eine r8 Wu konnte ich auch noch rechnen und da waren es 664 Sekunden. Erwartungsgemäß müßten diese WUs auf einem 45nm Quad um etwa 10% schneller abgerechnet werden, hochgerechnet auf 3.6GHz müßten für die 500er Sekundengrenze ausreichen.

Gipsel
12.12.2008, 14:21
sollte mit der schneller sein. was auch der fall sein könnte ist das dein cache nicht mehr ausreicht.. die beiden letzten versionen arbeiten wieder mit größeren arrays.
Größer als was?
Ich spiele eigentlich mit dem Gedanken, die arrays aus der offiziellen 0.07 rauszureißen und meine Version von der 1.22 zu transplantieren. Ist kleiner und dürfte trotzdem schneller sein.
Die Caches sollten auch nicht so eine große Rolle spielen. Für die 1.22 habe ich doch mal überschlagen, daß man größenordnungsmäßig nur 100MB/s oder so (bin zu faul, die genauen Zahlen rauszusuchen) an Bandbreite benötigt. Da man aber praktisch nur sequentiell darauf zugreift und nicht zufällig, kann man das auch locker aus dem Hauptspeicher streamen, ohne gleich irrsinnig viel Performance zu verlieren. Ab den CPUs mit wenigstens rudimentärem Hardware-Prefetch sollte das ohne große Performanceverluste klappen (maximal 10% würde ich schätzen).

Daß der P4 mit der besser optimierten Version an Performance verliert würde ich mal fast auf das HT schieben und nicht auf die Caches. Es gibt einfach weniger Blasen in der Pipeline, die mit dem zweiten Thread gefüllt werden können. Ohne HT würde ich fast drauf wetten, daß die neuere SSE2-Version auch schneller auf einem P4 ist, Deine nochmals verbesserte dritte Version sowieso.

Ole
12.12.2008, 14:56
"Incorrect Applications
December 11, 2008
It's come to my attention (looking at the results that are coming in), that a few of our users are using applications that are incorrect. If you're going to compile/modify our code please check it against the test files we've provided to make sure that it's correct. The searches we're running right now are highly sensitive to bad results, so this is pretty important. Either way I'm watching the users that are giving back bad results, and when our validator gets updated in the next couple days these bad results will not be awarded any credit. I'm hoping this isn't malicious action on the part of these users, and rather just a failure to double check their compiled apps. "

Das habt ihr gesehen, oder? Seid ihr da betroffen?

Gipsel
12.12.2008, 15:07
Das habt ihr gesehen, oder? Seid ihr da betroffen?
Ja und nein. Siehe hier:


@Twodee:
Hast Du die News über die fehlerhaft rechnenden Applikationen bei MW gesehen? Ich hoffe mal, das betrifft keinen von uns. Habe deswegen extra nochmal eben gerade meine Version die mitgelieferten Test-WUs rechnen lassen.

Edit:
Entwarnung. Es betrifft wohl Crunch3r und Logan von SUSA.
=====================================================

wie gesagt es sind nur er2 WUs, die sind von haus aus kürzer. eine r8 Wu konnte ich auch noch rechnen und da waren es 664 Sekunden. Erwartungsgemäß müßten diese WUs auf einem 45nm Quad um etwa 10% schneller abgerechnet werden, hochgerechnet auf 3.6GHz müßten für die 500er Sekundengrenze ausreichen.
Na okay, dann könnte der Intel-Compiler mit den Eigenarten der P4s vielleicht doch besser umgehen.
Also J-R, versuch es mal hiermit (http://www.file-upload.net/download-1311863/Milkyway_P4.zip.html). Ist ein SSE2-binary für P4s (läuft auf AMDs nicht). Vielleicht bringt es ja was.

J-R
12.12.2008, 16:25
@Gipsel, ich hab mal 2 wu zum testen deiner version gerettet.
musste aber kurz weg und komme erst jetzt dazu.
es scheint aber das die letzte version von Twodee nur ein wenig besserung gebracht hat, mal noch ein wenig warten bis die gerade aktiven fertig sind.


edit:
fertig, keine wu mehr.
ergebnis - unentschieden.
die letzten wu wurden von beiden app in etwa gleich schnell gerechnet.
@Gipsel P4Edition - 2* 2130 sec
@Twodee Spezial die letzten 3 wu: 2075, 2132 und 2181 sec.

am schnellsten ist immer noch die SSE2 version vom 08.12.08 von Twodee, da deren bestmarke bei 1603 sec lag.
leider kann man jetzt nix mehr testen und wer weiß wann es wieder arbeit gibt, somit sind die ergebnisse natürlich mit vorsicht zu geniessen.
ich denke so lange MW nix an den wu ändert, macht es auch wenig sinn da jetzt weiter am code für einen P4 zu schrauben, es scheint einfach zu wenige zu geben oder den leuten fällt es nicht auf.



Ohne HT würde ich fast drauf wetten, daß die neuere SSE2-Version auch schneller auf einem P4 ist, Deine nochmals verbesserte dritte Version sowieso.
vielleicht werden wir das bald sehen.
will ja an meinem laptop noch etwas an der vcore drehen damit die temps und somit der lärm reduziert wird, aber leider geht das nicht via soft, bios oder dip.
gibt da nur die möglichkeit eines Pin-Mod und der geht beim undervolten wohl nicht mehr rückgängig zu machen.
sollte das der prozessor, wenn ich mich dazu durchgerungen habe, nicht überleben hab ich nur noch einen 2,53Ghz ohne HT da.

snicK
13.12.2008, 14:12
Hier mal daten von meinem Q6600 @2,4GHz, mit der SSE2 App

alte app 1,379.05sec
neue app 915.01sec

Gipsel
14.12.2008, 12:38
Twodee hat im MW-Forum mal seine Ergebnisse gepostet (http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=508&nowrap=true#7719). Mal sehen was passiert. Wenn er Pech hat, wird er als Cheater beschimpft und ultimativ aufgefordert die App auszuliefern.
Aber im Prinzip ist die ja jetzt schon öffentlich zugänglich :]

J-R
14.12.2008, 13:25
Wenn er Pech hat, wird er als Cheater beschimpft und ultimativ aufgefordert die App auszuliefern.


wird er doch sowieso.
gibt ja auch bei uns leute die mit dem optimieren bzw. der tatsache das es user gibt die wg. creditgeilheit nur MW rechnen, nicht einverstanden sind.
letzteres finde ich aber auch nicht ok.

ansonsten, hab jetzt den läppi modifiziert welche spannung ich jetzt habe kann ich aufgrund der unauslesbarkeit der vcore nicht sagen.
laut Intel Spec Finder sollte die cpu 1.3v haben, das kann aber nicht stimmen oder gilt nur fürs runterschalten im akkubetrieb.
eingestellt ist jetzt (lt. Intel VidTabelle) 1.45v, lüfter läuft überwiegend in stufe 2 (bei Spin stufe3), stromverbrauch hat sich um rd 10W reduziert.
zusammen mit der änderung am kühler (3. Heatpipe eingebaut) hat sich die temperatur um rd. 15° reduziert. der lärm ist auch erheblich geringer, da der lüfter nicht mehr permanent auf maximum läuft.

jetzt werden nochmal die verschiedenen app getestet, angefangen mit der bisher schnellsten vom 08.12.08 (@Twodee)

Twodee
14.12.2008, 14:01
Twodee hat im MW-Forum mal seine Ergebnisse gepostet (http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=508&nowrap=true#7719). Mal sehen was passiert. Wenn er Pech hat, wird er als Cheater beschimpft und ultimativ aufgefordert die App auszuliefern.
Aber im Prinzip ist die ja jetzt schon öffentlich zugänglich :]

Warum cheater? Travis duldet doch selbst compilierte Apps von daher sehe ich kein Problem. Es gibt auch andere, die das machen ;)

[ich würde nicht mal die leute, die das creditlimit aushelbeln als cheater bezeichnen, da sie nur für eine gerechte entlohnung sorgen, einen Core i7 hab ich gesehen, der dies scheinbar tut]

Gipsel
14.12.2008, 16:37
Warum cheater? Travis duldet doch selbst compilierte Apps von daher sehe ich kein Problem. Es gibt auch andere, die das machen ;)

[ich würde nicht mal die leute, die das creditlimit aushelbeln als cheater bezeichnen, da sie nur für eine gerechte entlohnung sorgen, einen Core i7 hab ich gesehen, der dies scheinbar tut]
Ich habe da auch nicht an Travis gedacht, eher so an Leute vom Schlage der Cruncher Junkies falls Du damals bei Milksop die Diskussionen im MW-Forum verfolgt hast.

Und den Core i7 habe ich auch schon gesehen. Da habe ich aber das Gefühl, daß das ab Montag weniger werden könnte. Leider ist das nicht meiner :-[
Konnte den Besitzer aber überzeugen, daß ein paar Tage Stabilitätstest nicht schaden können :w_grins:

Hatte Freitag auch schon mal angefangen, den ganzen Murks mit den Arrays zu bereinigen. Das würde die App ja noch mal ein wenig verschlanken und auch die Speicherlecks beseitigen. Aber das war etwas zu aufwendig, um das mal so eben zwischen Tür und Angel zu erledigen, sprich, das habe ich noch nicht geschafft. Wahrscheinlich bin ich damit soweit, wenn die 0.08 rauskommt :]

Twodee
14.12.2008, 18:25
Achso, was die anderen denken ist mir rel. egal, solange es offiziell von der Projektleitung geduldet wird.

ich habs geschafft die Fr2 Wus auf meinem 3.6Ghz quad unter 500 sekunden zu drücken.
mehr verspreche ich mir noch vom intel compiler 11, den ich ab morgen austesten kann.

manni.deutsch
14.12.2008, 22:40
Der Posteingang von Twodee ist voll. Twodee kann keine weiteren Privaten Nachrichten empfangen, solange ältere Private Nachrichten nicht gelöscht worden sind.

@ Twodee

dein postfach ist voll mann kann dir keine PM mehr senden !!!!!


mfg manni

@ admin vieleicht kann ihn sonnst das jemand sagen ...:w_grins::w_grins:

gruß manni

Gipsel
15.12.2008, 06:42
ich habs geschafft die Fr2 Wus auf meinem 3.6Ghz quad unter 500 sekunden zu drücken.
mehr verspreche ich mir noch vom intel compiler 11, den ich ab morgen austesten kann.
Habe den Code ein wenig umgestellt, so daß die Autovektorisierung des Compilers auch mal was tut ;) Jetzt benötigt ein X2@3.09GHz für die stripe79_fr1 WUs nur noch 430Sekunden :D Wenn man berücksichtigt, daß die aktuellen WUs etwa 4 mal so groß wie die alten sind, ist das jetzt nochmal ein Stückchen schneller als damals die 1.22 Version 8)

Edit:
Also was ein Core i7 mit der (auto)vektorisierten App macht, ist bald nicht mehr feierlich. Der benötigt @3.6GHz etwa 305s im Schnitt für eine WU. Und das mit 8 Threads! Um an den Durchsatz ranzukommen, müßte ein normaler Quad die WUs in 150s durchziehen.

Ohne Creditlimit wäre man bei etwa 90k/Tag. Außerdem kommt man damit schon extrem nah an das 300 WU/Tag-Limit ran. Wird also mal wieder Zeit, die VMs rauszuholen, Twodee *buck*

Edit2:
Ein Phenom schlägt sich übrigens auch nicht soo schlecht, etwa 375s @2.57GHz. Für die nicht mindestens SSE2-fähigen CPUs gibt es leider kaum Verbesserungen (unter 10%). Wenn ich alles mal ausgetestet habe, werde ich heute oder morgen die Apps verlinken. Oder Twodee zaubert bis dahin mit dem neuen Intel-Compiler 11 noch was Schnelleres.

J-R
15.12.2008, 08:59
offensichtlich liegt mein "Problem" mit der langsamen berechnung trotz höher optimierter App doch nicht am Cache oder HT sondern tatsächlich an der temperatur.
nachdem ich jetzt mit jeder SSE2 App einige wu berechnet habe, liegt die P4 Spezial @Gipsel vorne.
diese hat die erste (mit 1603-1922s bisher schnellste) App von @Twodee bei 1533-1824s ganz knapp geschlagen.
bis auf @Twodees erste SSE2 wurden alle nachfolgenden versionen schneller.

eigentlich sind alle projekte etwas schneller geworden, wenn auch nur ein paar sec.
sogar Simap bringt die cpu nicht mehr zum offensichtlichen throttln.

bei den recherchen zur vcore bin ich auch darauf gestoßen das es im P4 2 temp-dioden gibt, eine die offensichtlich nach außen eine niedrigere meldet um den lüfter zu steuern und den user in sicherheit zu wiegen und eine die intern benutzt wird um die CPU zu drosseln.
das erkärt jetzt auch warum mir NHC und Everest gleichzeitig 2 unterschiedliche, um etwa 10° abweichende temperaturen anzeigten.

da jetzt mein basteldrang geweckt ist bekommt der P4 nachher die 5 zähne, äh VidPins gezogen und ein Dipswitch + externer meßpunkt für die vcore wird eingebaut.
damit kann ich dann die vcore verstellen und mit einem multimeter die spannung prüfen ohne jedesmal die cpu auszubauen.
hab zwar ne familienpackung WLP, das demontieren ist aber auf dauer doch sehr aufwendig und nervig.

Twodee
15.12.2008, 09:11
Habe den Code ein wenig umgestellt, so daß die Autovektorisierung des Compilers auch mal was tut ;) Jetzt benötigt ein X2@3.09GHz für die stripe79_fr1 WUs nur noch 430Sekunden :D Wenn man berücksichtigt, daß die aktuellen WUs etwa 4 mal so groß wie die alten sind, ist das jetzt nochmal ein Stückchen schneller als damals die 1.22 Version 8)

Nett was der IntelCompiler alles kann ;) - ich habe mir letzte nacht das 700MB Installationsfiel des IC11 gezogen, heute Abend probiere ich ihn mal aus. Derzeit liege ich bei ~490 Sekunden.

Was mir aufgefallen ist, das die "32Bit" App unter WinXp64 um ganze 10% schneller abläuft als auf WinXp32, getestet mir einem Q6600. Ist das bei dir auch so?



Edit:
Also was ein Core i7 mit der (auto)vektorisierten App macht, ist bald nicht mehr feierlich. Der benötigt @3.6GHz etwa 305s im Schnitt für eine WU. Und das mit 8 Threads! Um an den Durchsatz ranzukommen, müßte ein normaler Quad die WUs in 150s durchziehen.

Ohne Creditlimit wäre man bei etwa 90k/Tag. Außerdem kommt man damit schon extrem nah an das 300 WU/Tag-Limit ran. Wird also mal wieder Zeit, die VMs rauszuholen, Twodee *buck*

Och nee keine VMs mehr, den Stress tue ich mir nicht mehr an ;)


Edit2:
Ein Phenom schlägt sich übrigens auch nicht soo schlecht, etwa 375s @2.57GHz. Für die nicht mindestens SSE2-fähigen CPUs gibt es leider kaum Verbesserungen (unter 10%). Wenn ich alles mal ausgetestet habe, werde ich heute oder morgen die Apps verlinken. Oder Twodee zaubert bis dahin mit dem neuen Intel-Compiler 11 noch was Schnelleres.
Heute Abend ist bissal früh, vllt morgen ;)

Gipsel
15.12.2008, 14:46
Also was ein Core i7 mit der (auto)vektorisierten App macht, ist bald nicht mehr feierlich. Der benötigt @3.6GHz etwa 305s im Schnitt für eine WU. Und das mit 8 Threads!
Mit einer SSE4.1 App sind es dann nur noch 295s. Wären also ~2300 WUs für den Rechner pro Tag, wenn er denn 24/7 mit MW laufen würde.

gruenmuckel
15.12.2008, 17:37
Wie wärs mal mit nem Download der neuen schnelleren Apps? :w_zipfel:

Gipsel
15.12.2008, 18:57
Wie wärs mal mit nem Download der neuen schnelleren Apps? :w_zipfel:
Der Compiler ist ein wenig störrisch. Der weigert sich irgendwie die wichtigen Teile zu vektorisieren, wenn lediglich SSE2 zur Verfügung steht *noahnung*
Da hat Twodee natürlich Vorteile, wenn er das manuell macht. Muß jetzt dummerweise weg, aber im Notfall gibt es dann morgen eine SSE3-App.

Sabroe SMC
15.12.2008, 19:02
..... dann morgen eine SSE3-App.
Mmmhhh lecker, mjam mjam

gruenmuckel
15.12.2008, 19:11
Ich wäre eher an einer SSE-app interessiert. Mit dem Hauptrechner renne ich ins Limit, aber ein paar andere Rechner könnte ich noch optimieren.

Twodee
16.12.2008, 14:31
Mit der SSE2 App bin ich mit 3.2Ghz bei 365 Sekunden, bzw. für 3.6Ghz ~ 325 Sekunden.

Neue Version gibts im Laufe des Tages.

342 Sekunden, bzw. 304 Sekunden.

Riddler82
16.12.2008, 14:35
also, ich hab jetzt auch mal wieder einige WUs durchrauschen lassen, mit nem Phenom @ 2,53GHz.
Und zwar mit der bisher letzten SSE2 App von Twodee.
Dabei lagen die Zeiten zwischen ca. 780sec (nm_stripe82_er1) und ca. 950sec (nm_stripe86_er1).

Bin gespannt, ob die neuere die Du heute zur Verfügung stellen willst, nochmal nen kleinen Schub bringt.

Gipsel
16.12.2008, 15:32
Ich wäre eher an einer SSE-app interessiert. Mit dem Hauptrechner renne ich ins Limit, aber ein paar andere Rechner könnte ich noch optimieren.
Leider kommt der Hauptteil der letzten Beschleunigung von der Vektorisierung. Da bei Milkyway mit doppelter Genauigkeit gerechnet wird, ist dazu mindestens SSE2 erforderlich. Ohne das ist meine Version nur knapp 10% schneller, als die bereits hier von mir verlinkte.

Mit der SSE2 App bin ich mit 3.2Ghz bei 365 Sekunden, bzw. für 3.6Ghz ~ 325 Sekunden.

Neue Version gibts im Laufe des Tages.SSE2 Intrinsics per Hand eingebaut oder Autovektorisierung des Compilers?
Ich habe hier immer noch das Problem, das sich der ICC10 standhaft weigert das zu vektorisieren, wenn nur SSE2 erlaubt ist, ab SSE3 macht er es aber *noahnung* Hast Du vielleicht noch einen Tipp?

Probier mal das ganze auch mal mit den höheren SSE-Versionen aus! Ich stehe mit SSSE3 auf einem 65nm Core2@1.86GHz bei ~555s (auf dem 45nm@3GHz kann ich zur Zeit nicht testen). Das wären ja hochgechnet auf 3.2GHz schon etwa 325s. Also vielleicht lohnt es sich ja SSE2 und SSE3-Varianten hier zu verlinken. Sollten uns dann bloß einigen, wer was hier reinstellt, muß ja nicht ales doppelt sein. SSE2 mußt Du wohl machen.

also, ich hab jetzt auch mal wieder einige WUs durchrauschen lassen, mit nem Phenom @ 2,53GHz.
Und zwar mit der bisher letzten SSE2 App von Twodee.
Dabei lagen die Zeiten zwischen ca. 780sec (nm_stripe82_er1) und ca. 950sec (nm_stripe86_er1).

Bin gespannt, ob die neuere die Du heute zur Verfügung stellen willst, nochmal nen kleinen Schub bringt.
Das wird definitiv schneller, die Phenom-Zeiten mit SSE3 habe ich ja hier schon gepostet (375s@2.57GHz). Ist also pro Takt etwas schneller als die 65nm Core2. Zumindest mit meiner App.

Twodee
16.12.2008, 15:41
SSE2 Intrinsics per Hand eingebaut oder Autovektorisierung des Compilers?
Ich habe hier immer noch das Problem, das sich der ICC10 standhaft weigert das zu vektorisieren, wenn nur SSE2 erlaubt ist, ab SSE3 macht er es aber *noahnung* Hast Du vielleicht noch einen Tipp?

Beides, bei den Teilen, die der ICC nicht vektorisiert habe ich per Hand nachgeholfen 8)


Probier mal das ganze auch mal mit den höheren SSE-Versionen aus! Ich stehe mit SSSE3 auf einem 65nm Core2@1.86GHz bei ~555s (auf dem 45nm@3GHz kann ich zur Zeit nicht testen). Das wären ja hochgechnet auf 3.2GHz schon etwa 325s. Also vielleicht lohnt es sich ja SSE2 und SSE3-Varianten hier zu verlinken. Sollten uns dann bloß einigen, wer was hier reinstellt, muß ja nicht ales doppelt sein. SSE2 mußt Du wohl machen.
SSE3/4.1 ist bei mir nur minimal schneller als SSE2, unter 5%


Das wird definitiv schneller, die Phenom-Zeiten mit SSE3 habe ich ja hier schon gepostet (375s@2.57GHz). Ist also pro Takt etwas schneller als die 65nm Core2. Zumindest mit meiner App. Ist bei mir auch so.

heavy-Ions@boinc
16.12.2008, 15:45
Habt ihr dafür eine Erklärung das der Phenom pro Takt schneller ist ? eigentlich ist der Intel ja meist schneller pro takt?

Caipi
16.12.2008, 15:48
Habt ihr dafür eine Erklärung das der Phenom pro Takt schneller ist ? eigentlich ist der Intel ja meist schneller pro takt?

Moin
mit der org. App is mein X2 @ 2500 :w_feiern:
genauso schnell wie mein C2D @ 3200
hats ev. was damit zu tun :w_verwirrt:

heavy-Ions@boinc
16.12.2008, 15:50
Moin
mit der org. App is mein X2 @ 2500 :w_feiern:
genauso schnell wie mein C2D @ 3200
hats ev. was damit zu tun :w_verwirrt:
aber auch dafür müßte es ja eine erklärung geben. es ist ja ansonsten fast unmöglich eine anwendung zu finden bei der ein alter K8 gegen einen C2D "gewinnt" und das auch noch bei weniger takt! :o

Gipsel
16.12.2008, 16:11
Habt ihr dafür eine Erklärung das der Phenom pro Takt schneller ist ? eigentlich ist der Intel ja meist schneller pro takt?
Nunja, MW macht ja nicht viel Kompliziertes. Und bei der theoretischen SSE/2/3-Leistungsfähigkeit liegt der Phenom nunmal bei den meisten Anwendungsfällen vor dem 65nm Core2.
Was mich an der Erklärung noch ein wenig stört, ist daß die X2s dafür etwas zu schnell sind. Die dürften durch die Vektorisierung eigentlich nicht soviel gewinnen, da der skalare SSE2/3 Durchsatz eigentlich genauso hoch sein sollte *suspect* Aber zumindest sind sie dann langsamer als die Core2.
.
EDIT :
.

Beides, bei den Teilen, die der ICC nicht vektorisiert habe ich per Hand nachgeholfen 8)Na darauf habe ich gerade keine Lust.

SSE3/4.1 ist bei mir nur minimal schneller als SSE2, unter 5%Wie machen wir es denn jetzt? Von Dir die SSE2-App und von mir die SSE3 für die etwas neueren Rechner? Oder meinst Du, das lohnt nicht? Und über die Standard-Variante SSE für die alten Rechner haben wir noch gar nicht geredet. Die würde ich sonst übernehmen.

Twodee
16.12.2008, 16:16
Moin
mit der org. App is mein X2 @ 2500 :w_feiern:
genauso schnell wie mein C2D @ 3200
hats ev. was damit zu tun :w_verwirrt:
die original app nutzt kein SSE, dafür intensiv x87 und da stehen dem x2 ganze 3 FPUs zur verfügung, der Core2 hat nur eine.
.
EDIT :
.

Nunja, MW macht ja nicht viel Kompliziertes. Und bei der theoretischen SSE/2/3-Leistungsfähigkeit liegt der Phenom nunmal bei den meisten Anwendungsfällen vor dem 65nm Core2.
Was mich an der Erklärung noch ein wenig stört, ist daß die X2s dafür etwas zu schnell sind. Die dürften durch die Vektorisierung eigentlich nicht soviel gewinnen, da der skalare SSE2/3 Durchsatz eigentlich genauso hoch sein sollte *suspect* Aber zumindest sind sie dann langsamer als die Core2.
.
EDIT :
.
Na darauf habe ich gerade keine Lust.
Wie machen wir es denn jetzt? Von Dir die SSE2-App und von mir die SSE3 für die etwas neueren Rechner? Oder meinst Du, das lohnt nicht? Und über die Standard-Variante SSE für die alten Rechner haben wir noch gar nicht geredet. Die würde ich sonst übernehmen.
mhm, ok dann erledige ich SSE2, du kümmerst dich um die SSE3 App

die SSE1 Variante probiere ich auch noch aus, wobei ich aber dann meine intrins ändern muss :(, vllt probierst du dich daran auch *g*

manni.deutsch
16.12.2008, 16:18
moin moin

dann könnt ihr ja auch gleich eine empfehlung posten welche cpu welche SSE


was soll ich zb. für meine x2 benutzen ?

gruß manni

Gipsel
16.12.2008, 17:26
die original app nutzt kein SSE, dafür intensiv x87 und da stehen dem x2 ganze 3 FPUs zur verfügung, der Core2 hat nur eine.
Von den 3 sogenannten FPUs erledigen aber 2 Einheiten die Hauptarbeit. Und auf soviele kann der Core2 auch zurückgreifen (P4 übrigens auch). Wenn ich mich richtig erinnere, war das ein Punkt, der gegenüber dem P3 aufgebohrt wurde.

mhm, ok dann erledige ich SSE2, du kümmerst dich um die SSE3 AppWird gemacht.


die SSE1 Variante probiere ich auch noch aus, wobei ich aber dann meine intrins ändern muss :(, vllt probierst du dich daran auch *g*
Willst' mit floats rechnen oder wie? Dann wäre natürlich nochmal eine gehörige Beschleunigung drin, aber ich bezweifle, ob die Jungs bei MW das so gerne sehen :]

Aber ehrlich gesagt habe ich darüber schon nachgedacht. Ich glaube, daß für die allermeisten WUs floats reichen würden. Die müßten bloß eventuell ihr (serverseitiges) Suchschema minimal anpassen. Mann, die nutzen jetzt schon die doubles nicht (schau mal auf die Länge der Zahlen in den Checkpoints *buck*).
Das Killerfeature der optimierten App wäre übrigens dann die GraKa-Nutzung. MW eignet sich eigentlich recht gut dafür. Ist doch bloß exp in der innersten Schleife drin, was die Party etwas stören könnte. Habe keine Ahnung, wie die GraKas das können, aber im Notfall macht man das per Table (Texture) Lookup. Ansonsten ist MW auch auf WU-Ebene "embarrassingly parallel". Das könnte man locker ohne großen Aufwand auf ein paar tausend Einheiten verteilen. Dann wäre man wahrscheinlich in 10s mit einer WU durch :w_zipfel:
Wenn ich 10 Jahre jünger wäre und nichts zu tun hätte, wäre das glatt mein Projekt fürs nächste WE. Weil dann hätte ich bestimmt auch eine passende GraKa *lol*
.
EDIT :
.
Also dann löse ich meinen Teil ein:

SSE-Version für ältere Rechner (http://www.file-upload.net/download-1319985/MW_SSEV2.zip.html) (ist wie schon gesagt nicht viel schneller als die ältere Version)

SSE3-Version für neuere Rechner (http://www.file-upload.net/download-1319990/MW_SSE3V2.zip.html)

Die SSE2-Variante kommt dann von Twodee.


dann könnt ihr ja auch gleich eine empfehlung posten welche cpu welche SSE


was soll ich zb. für meine x2 benutzen ?
Wenn Twodee nicht noch was an seiner Version schraubt, ist das ziemlich einfach. Immer das höchste nehmen, was die CPU unterstützt. Damit sollte man nicht schlecht fahren (evtl. gibt es Ausnahmen bei Prescotts).
Alle X2 unterstützen SSE3 (A64 ab Rev. E), genau wie alle Core2 und P4 ab Prescott.

manni.deutsch
16.12.2008, 17:44
moin moin

das ist ja nun echt ein Ding. :w_grins:

SSE 3 ist ja hammer schnell !!! ( 50 % also nur noch die hälfte an zeit )

supper arbeit !!!

gruß manni

SR530
16.12.2008, 17:50
Wenn Twodee nicht noch was an seiner Version schraubt, ist das ziemlich einfach. Immer das höchste nehmen, was die CPU unterstützt. Damit sollte man nicht schlecht fahren (evtl. gibt es Ausnahmen bei Prescotts).
Alle X2 unterstützen SSE3 (A64 ab Rev. E), genau wie alle Core2 und P4 ab Prescott.
Wer sich nicht sicher ist, kann natürlich CPU-Z (http://www.cpu-z.de/) befragen. Aber das wird ja wohl jeder hier kennen ... :w_zwinker:

Caipi
16.12.2008, 18:20
moin moin

das ist ja nun echt ein Ding. :w_grins:

SSE 3 ist ja hammer schnell !!! ( 50 % also nur noch die hälfte an zeit )

supper arbeit !!!

gruß manni

Moin
aber nur bei den amd :w_feiern:
c2 sind leider nicht schneller geworden :w_verwirrt:



Edit
Boah eyh klatsch Hand vor Kopf *chatt*

man muss die app auch austauschen *glaubses*

ps. hier fehlt noch der Smiley der sich die Hand vorn Kopp klatsch

Ole
16.12.2008, 18:21
350-370 auf einem PhenomX4 2.8GHz.
Allerdings lief nebenbei auch noch Team Fortress 2.

Ich sach mal so: Hut ab! Die geht ja gut ab! *g*

Gipsel
16.12.2008, 18:25
Moin
aber nur bei den amd :w_feiern:
c2 sind leider nicht schneller geworden :w_verwirrt:
:w_verwirrt:
Hast Du das mal über mehrere WUs beobachtet? Ab und zu geistern vielleicht noch welche mit anderer Länge durch die Gegend. Kann mir kaum vorstellen, daß der Intel-Compiler nur für AMDs schnellen Code erzeugt.

Caipi
16.12.2008, 18:35
hat sich erledigt, hatte nur vergessen bei den c2s die app auch zu tauschen
is halt nichts wenn man nebenher noch andere Sachen erledigt

Gladiator
16.12.2008, 18:46
@ Gipsel Test Rechner C2Q 3.2 GHZ (9x356)

twodees SSE2 app vom 9.12.2008 20:27 braucht 681 sek.

gipsels SSE3v2 app vom 16.12.2008 16:57 braucht 313 sek.

speedboost 108%

saubere Arbeit Gipsel :w_zipfel:

gruenmuckel
16.12.2008, 18:59
SSE3V2 = satte 50% Beschleunigung zur alten SSE3-App.
Wird aber auch gleich mal 3° C wärmer.


http://www.abload.de/img/sse3v2dxxj.png (http://www.abload.de/image.php?img=sse3v2dxxj.png)

Gipsel
16.12.2008, 19:11
speedboost 54%

SSE3V2 = satte 50% Beschleunigung zur alten SSE3-App.
Ihr immer mit Eurer 50% Beschleunigung. Die ist doppelt so schnell wie die alte, also 100% schneller *buck*

Wird aber auch gleich mal 3° C wärmer.
Irgendwo muß die Leistung ja herkommen ;D

Sabroe SMC
16.12.2008, 19:16
Q6600@3,2Ghz (8x400)
vorher (Twodees alte) 615-631 sec
jetzt (Gipsel) 299 -308 sec.

HAMMER:w_feiern:

gruenmuckel
16.12.2008, 19:19
Ihr immer mit Eurer 50% Beschleunigung. Die ist doppelt so schnell wie die alte, also 100% schneller *buck*

Meine Lehrerin hatte so recht! Abschreiben lohnt sich nicht... *nosorry*

Riddler82
16.12.2008, 19:24
sieht bei mir ähnlich aus auf dem Phenom.

nur noch ca. 380 bis 400sec statt den 780 bis 960 vorher, beeindruckend.


Die frage ist nur, ob das wirklich alles im Sinne der Betreiber ist, bei so fantastischen Beschleunigungen bin ich nunmal skeptisch.

Twodee
16.12.2008, 19:43
Ich hab meine App auch wieder etwas weiter gebracht, liege jetzt bei 284 Sekunden für einen 3.2GHz Quad, und damit im WU limit :(

manni.deutsch
16.12.2008, 19:46
lööööööl


Ihr immer mit Eurer 50% Beschleunigung. Die ist doppelt so schnell wie die alte, also 100% schneller

rechne mal 1000 sec minus 100 %

das sind dann null !!!!!!!
x minus 100 % gleich die hälfte :w_grins::w_grins:mann mann

1000 sec minus 50 % sind ???? na 500 sec !!


mathe 5 setzen !!!!!!!

Gipsel
16.12.2008, 19:58
Die frage ist nur, ob das wirklich alles im Sinne der Betreiber ist, bei so fantastischen Beschleunigungen bin ich nunmal skeptisch.
Fragt sich nur, wonach dem Betreiber eigentlich der Sinn steht. Wir hatten ja schon im September das Gefühl, daß die gar nicht so genau wissen, was sie da im Deteil eigentlich tun. Oder wie kommen sonst solche Aussagen über den Code der alten 1.22-Version (http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=386&nowrap=true#4851) zustande?

Given what our code is doing, honestly the only way i can see this kind of speed improvement being possible is through vectorizing most of the floating point operations in all the loops of our code. There's really no way to increase the algorithmic runtime of what we're doing (it's pretty simple -- just a sum of a lot of floating point ops).
Wohlgemerkt hat er hier über die alte Version gesprochen, die auf einem 3.2GHz C2Q etwa 20ks benötigt hat. Die heutigen WUs sind etwa 4mal so lang, hätten also 80ks (einen ganzen Tag *buck*) gedauert. Jetzt sind wir bei etwas über 300s (5 Minuten). Und jetzt erzähl' mir keiner, der Typ hätte von irgendwas Ahnung.
.
EDIT :
.

Ich hab meine App auch wieder etwas weiter gebracht, liege jetzt bei 284 Sekunden für einen 3.2GHz Quad, und damit im WU limit :(
Also jetzt unter 5 Minuten. Habe ich mir doch gedacht, daß Du weiter dran feilst.
Mir gehen langsam die Ideen für weitere Sprünge aus. Oder ich müßte mal in Ruhe (habe ich aber nicht) drüberschauen.

Twodee
16.12.2008, 19:59
245 Sekunden für 3.6Ghz *chatt*

Ole
16.12.2008, 20:06
670 - 680 auf einem X2 3800+ (939) mit Standardtakt.

Bodo vom D.See
16.12.2008, 20:29
240-245 sec mit 3200 MHz und Vista x64

tolle Sache und Hut ab

KGBerlin
16.12.2008, 20:34
SSE3

X2 9550 @ Stock @ Vista 64bit

stripe86 er_1 = 454sek
stripe86 er_1 = 450sek
stripe82 fr_1 = 437sek
stripe86 er_1 = 453sek

Be-2300 @ Stock @ XP 32bit

stripe79 fr_1 = 713sek
stripe82 er_1 = 717sek
stripe86 er_1 = 717sek
stripe82 fr_1 = 740sek

Auf beiden laufen aber noch TV, Chat oder Filme, also könnte man noch die eine oder andere Sekunde rausquetschen ;D

manni.deutsch
16.12.2008, 20:36
HEHEHE

mann sieht genau wer alles so in unser forum liest

immer paar stunden nach unseren neuen schnelleren APP
kommen diese auch bei den anderen Teams an ...

mal schauen wann die nächste welle losbricht..

gruß manni

Ole
16.12.2008, 20:36
Ärgerlich. Mein eee kann kein SSE3. *chatt*

So ein, zwei, drei WUs hätte ich aus Spaß an der Freude doch durchgehauen...

Gipsel
16.12.2008, 20:40
Ärgerlich. Mein eee kann kein SSE3. *chatt*

So ein, zwei, drei WUs hätte ich aus Spaß an der Freude doch durchgehauen...
Dann nerv' mal Twodee, daß er die SSE2-Variante verlinkt :w_zwinker:

Ole
16.12.2008, 20:42
2D Du olle Schlangeeeee, was brauchst Du zum posten soooolange? *sing*


Nee, nee, lass ma. Das Teil wäre wirklich nur für 3 oder 4 WUs an. :w_grins:

TiKu
16.12.2008, 20:55
Um mal zum Thema zurückzukommen: Ich finde das, was derzeit von euch praktiziert wird, unschön. Euer Ziel war es mal, die Betreiber von MilkyWay dazu zu bewegen, die App zu verbessern. Credits waren damals so unwichtig, dass extra ein teamloser Account genutzt wurde.
Davon ist nichts mehr übrig. Die App wird optimiert wie es nur geht, aber Druck auf die Projektbetreiber wird anscheinend nicht mehr wirklich ausgeübt (zumindest liest man hier nichts mehr davon), und gerechnet wird auf die normalen Accounts. Somit scheint der Sinn des ganzen inzwischen schnöde Creditscheffelei zu sein. Ich dachte, dass bei unserem DC-Team andere Dinge im Vordergrund stehen.;)

Twodee
16.12.2008, 20:59
2D Du olle Schlangeeeee, was brauchst Du zum posten soooolange? *sing*


Nee, nee, lass ma. Das Teil wäre wirklich nur für 3 oder 4 WUs an. :w_grins:
kommt gleich ;)
.
EDIT :
.

Um mal zum Thema zurückzukommen: Ich finde das, was derzeit von euch praktiziert wird, unschön. Euer Ziel war es mal, die Betreiber von MilkyWay dazu zu bewegen, die App zu verbessern. Credits waren damals so unwichtig, dass extra ein teamloser Account genutzt wurde.
Davon ist nichts mehr übrig. Die App wird optimiert wie es nur geht, aber Druck auf die Projektbetreiber wird anscheinend nicht mehr wirklich ausgeübt (zumindest liest man hier nichts mehr davon), und gerechnet wird auf die normalen Accounts. Somit scheint der Sinn des ganzen inzwischen schnöde Creditscheffelei zu sein. Ich dachte, dass bei unserem DC-Team andere Dinge im Vordergrund stehen.;)

TiKu, uns nützt es nix wenn die App schneller wird, da wir in ein Creditlimit rechnen, dem Projekt nützt es schon etwas, da wieder mal oh wunder mehr arbeit verrichtet wird.

im klartext, es ist für einen user egal ob er einen Quad mit 2Ghz oder 4Ghz rechnen läßt, er bekommt nicht mehr als 10K pro Tag ;)

TiKu
16.12.2008, 21:02
im klartext, es ist für einen user egal ob er einen Quad mit 2Ghz oder 4Ghz rechnen läßt, er bekommt nicht mehr als 10K pro Tag ;)...braucht für diese 10k aber nicht lang und hat danach mehr Zeit für andere Projekte, wodurch er letztenendes doch ganz gehörig von der optimierten App profitiert.

Twodee
16.12.2008, 21:08
...braucht für diese 10k aber nicht lang und hat danach mehr Zeit für andere Projekte, wodurch er letztenendes doch ganz gehörig von der optimierten App profitiert.
falsch, er braucht genau einen Tag dafür.

noch sind wir nicht komplett im WU limit angekommen.
.
EDIT :
.
**Update**

SSE2 App + SSE3 App

http://www.file-upload.net/download-1320653/MW.rar.html

SSE2 ~ 270 Sekunden -3.2Ghz Quad
SSE3 ~ 262 Sekunden -3.2Ghz Quad

Caipi
16.12.2008, 21:08
...braucht für diese 10k aber nicht lang und hat danach mehr Zeit für andere Projekte, wodurch er letztenendes doch ganz gehörig von der optimierten App profitiert.

Moin
nö da gibt es ein Kreditlimit von 0.03 credits sek
musst für die 10.000 also den ganzen tag rechnen :w_traurig:

heavy-Ions@boinc
16.12.2008, 21:09
...braucht für diese 10k aber nicht lang und hat danach mehr Zeit für andere Projekte, wodurch er letztenendes doch ganz gehörig von der optimierten App profitiert.

die betreiber haben die neuen source-codes frei gestellt, damit JEDER sie weiter optimieren kann. das ist von denen so gewollt.
und die apps sind hier frei zugänglich für jedermann. für mich also die gleiche situation wie bei seti mit den optimierten apps.

TiKu
16.12.2008, 21:10
Das Limit zu umgehen scheint aber recht einfach zu sein.

heavy-Ions@boinc
16.12.2008, 21:10
**Update**

SSE2 App + SSE3 App

http://www.file-upload.net/download-1320653/MW.rar.html

SSE2 ~ 270 Sekunden -3.2Ghz Quad
SSE3 ~ 262 Sekunden -3.2Ghz Quad
büdeebüddebüdde auch eine für linux.....

TiKu
16.12.2008, 21:10
und die apps sind hier frei zugänglich für jedermann. für mich also die gleiche situation wie bei seti mit den optimierten apps.Ist dort der Unterschied zwischen optimierter App und nicht optimierter App auch so extrem?

Ole
16.12.2008, 21:12
Tiku hat schon recht. Wie man an meinem Account sehen kann, rechne ich von den Dingern eigentlich immer nur ein paar am Tag, andere werden das sicherlich anders halten, leider.

Allerdings sehe ich die Sache anders als Tiku was die Kritik mit den Accounts angeht.

Die erste Geschichte war eine andere Sache, da die originale App nun wirklich eine Zumutung war, mittlerweile hat sich das wohl gebessert ist aber immer noch weit vom Ideal weg. Das so ein kleines Projekt keine x verschiedenen Applikationen für jede irgendwie, möglicherweise vorhandene CPU Spezialisierung bringt ist auch klar, ich will gar nicht wissen, was im Forum los wäre, wenn es plötzlich 8 verschiedene Clients für 32Bit, und nochmal soviele für 64Bit Windows und dasselbe nochmal für Linux geben würde.

Insofern sind die jetzigen Clients eine Hilfe für das Projekt, da die Arbeit wesentlich schneller fertig wird, was die Creditvergabe angeht: Das ist nun mal so eine Sache. Patentrezepte gibt es nicht, aber das Projekt könnte sich doch deutlich mehr bemühen das ganze zu optimieren. Wenn es nur eine handvoll sind, die mehr als andere ercrunchen ändert sich nie was, wenn dagegen wieder eine Mail vom Boincstats Creditmeister kommt, bewegt sich wohl eher was.

Wie gesagt: Man muss es ja nur nicht übertreiben mit der optimierten App.

Ausserdem: Wenn ich sehe, was einige mit den GPU Clients scheffeln...:w_zwinker: und "eigentlich" ist das auch nur eine optimierte App, wenn man App nicht auf die CPU sondern auf den Host bezieht.