Projekt des Monats Juli - Abstimmung

Welches Projekt soll Projekt des Monats Juli werden?

  • 3x+1@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=3x%2B1%40home]Infos[/url]

    Stimmen: 0 0,0%
  • ABC@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=ABC%40home]Infos[/url]

    Stimmen: 6 7,0%
  • BURP - [url=http://dc.planet3dnow.de/wiki/index.php?title=BURP]Infos[/url]

    Stimmen: 0 0,0%
  • ClimatePrediction.net - [url=http://dc.planet3dnow.de/wiki/index.php?title=ClimatePrediction.net]Inf

    Stimmen: 8 9,3%
  • Cosmology@Home - [url=http://dc.planet3dnow.de/wiki/index.php?title=Cosmology%40Home]Infos[/url]

    Stimmen: 4 4,7%
  • Leiden Classical - [url=http://dc.planet3dnow.de/wiki/index.php?title=Leiden Classical]Infos[/url]

    Stimmen: 0 0,0%
  • Malariacontrol.net - [url=http://dc.planet3dnow.de/wiki/index.php?title=Malariacontrol.net]Infos[/ur

    Stimmen: 5 5,8%
  • MilkyWay@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=MilkyWay%40home]Infos[/url]

    Stimmen: 1 1,2%
  • MindModeling@Home - [url=http://dc.planet3dnow.de/wiki/index.php?title=MindModeling%40Home]Infos[/ur

    Stimmen: 2 2,3%
  • PrimeGrid - [url=http://dc.planet3dnow.de/wiki/index.php?title=PrimeGrid]Infos[/url]

    Stimmen: 0 0,0%
  • QMC@Home - [url=http://dc.planet3dnow.de/wiki/index.php?title=QMC%40Home]Infos[/url]

    Stimmen: 7 8,1%
  • Rectilinear Crossing Number - [url=http://dc.planet3dnow.de/wiki/index.php?title=Rectilinear_Crossin

    Stimmen: 2 2,3%
  • Riesel Sieve - [url=http://dc.planet3dnow.de/wiki/index.php?title=Riesel_Sieve]Infos[/url]

    Stimmen: 10 11,6%
  • Rosetta@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=Rosetta%40home]Infos[/url]

    Stimmen: 7 8,1%
  • SETI@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=SETI%40home]Infos[/url]

    Stimmen: 6 7,0%
  • SHA-1 Collision Search Graz - [url=http://dc.planet3dnow.de/wiki/index.php?title=SHA-1_Collision_Sea

    Stimmen: 2 2,3%
  • Spinhenge@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=Spinhenge%40home]Infos[/url]

    Stimmen: 21 24,4%
  • SZTAKI Desktop Grid - [url=http://dc.planet3dnow.de/wiki/index.php?title=SZTAKI_Desktop_Grid]Infos[/

    Stimmen: 0 0,0%
  • TANPAKU - [url=http://dc.planet3dnow.de/wiki/index.php?title=TANPAKU]Infos[/url]

    Stimmen: 1 1,2%
  • Virtual Prairie - [url=http://dc.planet3dnow.de/wiki/index.php?title=Virtual_Prairie]Infos[/url]

    Stimmen: 2 2,3%
  • World Community Grid - [url=http://dc.planet3dnow.de/wiki/index.php?title=World_Community_Grid]Infos

    Stimmen: 1 1,2%
  • yoyo@home - [url=http://dc.planet3dnow.de/wiki/index.php?title=yoyo%40home]Infos[/url]

    Stimmen: 0 0,0%
  • µFluids@Home - [url=http://dc.planet3dnow.de/wiki/index.php?title=UFluids%40Home]Infos[/url]

    Stimmen: 1 1,2%

  • Anzahl der Umfrageteilnehmer
    86
  • Umfrage geschlossen .
Aber trotz Race machen wir um Durchschnitt bei unseren Stammprojekten Rosetta, WCG und Spinhenge 50k am Tag (was ich nicht schlecht finde) und das wird jetzt auch wieder steigen. Habe schon den ersten Großcruncher wieder zu Spinhenge geschickt... :P

Und ansonsten hat Twodee ja schon alles gesagt. ;D

@ Twodee
Mach Mal Sunshine an. ;)

ne du war leider nich mehr drinn, mußte eher ins bett ;D

dafür heute.

;)
 
So na dann mal alle Cluster-Nodes zu Spin ;D
 
So na dann mal alle Cluster-Nodes zu Spin ;D
Die Clusternodes schwitzen sich momentan an CPDN kaputt, bei durchgehender Berechnung sollten die im September fertig werden. Momentan 5% pro Woche, dass ist hart!:o Müssen die Nodes gezwungenermaßen immer beim PDM dabei sein?
 
So na dann mal alle Cluster-Nodes zu Spin ;D

Müssen die Nodes gezwungenermaßen immer beim PDM dabei sein?

Muss ehrlich sagen, daß ich mal sowas von überhaupt keine Lust auf Spinhenge habe.
Wahrscheinlich werde ich erst mal mithelfen die nächste Simap-Welle zu vernichten und dann bei Superlink die Führung ausbauen.
Ansonsten werde wohl auch mal wieder einige der Underdog-Projekte in Angriff nehmen.

Bin auf jeden Fall dagegen die Nodes immer ans PDM zu binden.
 
soweit ich weiß steht dem betreiber frei wo er "seine" nodes rechnen läßt.

ich lassen meine 2 nodes erstmal noch bei POEM.
 
Ich verweise mal drauf, dass es gerade wieder Monatsanfang ist, und es neue Simap WUs gibt. Damit wenigstens der 1. Platz gehalten wird, würde ich vorschlagen, dass wir für den Monatsanfang die aktuellen Simap WUs wegcrunshen.

Neue Applikation 5.10 gibts übrigends auch.

ciao

Alex
 
Ich verweise mal drauf, dass es gerade wieder Monatsanfang ist, und es neue Simap WUs gibt. Damit wenigstens der 1. Platz gehalten wird, würde ich vorschlagen, dass wir für den Monatsanfang die aktuellen Simap WUs wegcrunshen.

Neue Applikation 5.10 gibts übrigends auch.

ciao

Alex


Dann verweise ich mal auf SuperLink, da besteht derzeit deutlich mehr Gefahr bzgl. Verlust des P1, Simap is Safe 8) auch für die ESL derzeit ;D
 
Dann verweise ich mal auf SuperLink, da besteht derzeit deutlich mehr Gefahr bzgl. Verlust des P1, Simap is Safe 8) auch für die ESL derzeit ;D
Bei Simap sind eh nur noch 30000 Wus da .. die sind morgen weg ... ich würds mitnehmen.

ciao

Alex
 
@Twodee
Zitat:
Zitat von Opteron Beitrag anzeigen
Ich glaube mich daran erinnern zu können, dass es beim Spin Race geheißen hat, dass AMD CPUs dort mehr Credits / MHz abliefern. Ob da jetzt 3DNOW oder sonstwas unterstützt wird ist egal, hauptsache AMD ist schneller, bzw. zeigt gute (bessere) Leistung ;-) Mir gehts nur um die Optimierung der credits/MHz des Gesamtteams
nein.
Spin ist überhauptnicht optimiert. Spinhenge stützt sich nur auf die alte FPU (wovon der K8/10 ganze 3 hat, der Core2 nur eine). Was meinst du warum Spin auf Vista64 so schlecht abscheidet? Weil die FPU da mittels WOW emuliert wird, was natürlich Leistung kostet. Spinhenge ist nur ein Beipiel dafür für ein nicht optimiertes Projekt, basierend auf altem Code.

Du schuldest mir immer noch einen Beleg für: Die meisten sind ja eher für Intel optimiert.


Ich habe ja win xp64 pro auf 3 rechner am laufen, da werden auch alle 32bit anwenungen durch den WOW emmuliert, jedoch hatte ich bisher nict den eindruck das es längsämer rennt als mit 32bit xp.

für aufklärung bin ich empfänglich....

gruss thorshammer

PS: ja ich weiss ich hinke ein wenig hinther im fred....war ja auch im race so...aber was solls
 
:-)

Laprechum (oder wie der kerl heißt), ein verantwortlicher von der Spinhenge hat das mal gesagt warum er Vista64 + Spin nicht mag.

Das WinXp64 ebenso verfährt stimmt. Allerdings hab ich das jetzt nciht selber geprüft ob spin da auch langsamer is. Bei Vista64 vs WinXp32, beides auf einem K8 X2 lagen 10% Unterschied (wenn ich mich genau erinnere), also 880c vs 800c (2.1GHz)
 
Inwiefern wird bei Vista x64 die FPU emuliert? Mir fällt es sehr schwer das zu glauben.
 
Inwiefern wird bei Vista x64 die FPU simuliert? Mir fällt es sehr schwer das zu glauben.

steht zumindest hier: http://www.computerbase.de/artikel/hardware/prozessoren/2003/test_athlon_64_fx-51_athlon_64_3200/13/

[...]Das liegt vor allem daran, dass unter Windows XP 64-Bit keine FPU/MMX Einheit zur Verfügung steht und entsprechende Befehle über SSE/SSE2 (das macht letztendlich auch die FPU) ausgeführt werden müssen. Hierbei handelt es sich aber weniger um ein Problem vom Athlon 64 sondern vielmehr um eine Eigenart von Windows XP 64-Bit Edition
 
Jo, microsoft hat mit vista64 bei 64bit die unterstützung für x87 übern haufen geworfen. allerdings dachte ich das 32bit anwendungen diese noch nutzen können...

gruß

cumec
 
Moinsen.

Da Spin eh mein "Stammprojekt" ist (neben Seti Beta),
bin ich über das Abstimmungsergebnis doch schon erfreut.
Nun seht aber mal zu, dass Ihr in die Puschen kommt.
Habe seit heute morgen (!) über 320 Cr im Pending.... 8)


Auf gehts *attacke*
 
Okay, kurze Recherche hat ergeben, dass AMD in der Tat von der Nutzung der FPU abrät und auf die SSE-Einheiten drängt. Aber nichtsdestotrotz sollte das ja wohl eher ein Compiler-Problem als ein OS-Problem sein.*noahnung*
 
Okay, kurze Recherche hat ergeben, dass AMD in der Tat von der Nutzung der FPU abrät und auf die SSE-Einheiten drängt. Aber nichtsdestotrotz sollte das ja wohl eher ein Compiler-Problem als ein OS-Problem sein.*noahnung*

hat ja auch keiner behauptet das es ein OS problem ist.

schade das spinhenge weiterhin so rückständig bleibt und auf veralteten code/compilereinstellungen setzt.
 
Dann sollte Leprechaun (oder wie auch immer er geschrieben wird) aber aufhören auf Vista x64 zu schimpfen und stattdessen einen anderen Compiler suchen.*buck*
 
Dann sollte Leprechaun (oder wie auch immer er geschrieben wird) aber aufhören auf Vista x64 zu schimpfen und stattdessen einen anderen Compiler suchen.*buck*

hatte er nicht gesagt das der verantwortliche prof den code unter verschluß hält wegen patente und so? schon alles ziemlich merkwürdig ;D
 
danke für eure erklärungen, aber ganz stimmig finde ich sie nicht.
ich denke schon das der WOW die FPU auch ansprechen kann, alles andere gibt kein sinn. WOW und D3D sind ja ähnliche anwendungen, den beide sitzen zwischen der Hardware und der Anwendersoftware.

beim beispiel mit 880zu800PPD beim x2 sind die 10% einbusse eher beim zusätzlichen verwaltungsaufwand zu suchen als in einer fehlenden FPU....den ohne diese FPU müsste der leistungs abfall um einiges höher sein.

PS: habe auch nur spekuliert!!!
 
danke für eure erklärungen, aber ganz stimmig finde ich sie nicht.
ich denke schon das der WOW die FPU auch ansprechen kann, alles andere gibt kein sinn.

nein das kann sie eben nicht. WoW wandelt die FPU-Befehle in SSE-Befehle um, MMX und FPU werden in WinXP64 und Vista64 nicht mehr unterstützt/angesprochen.

WOW und D3D sind ja ähnliche anwendungen, den beide sitzen zwischen der Hardware und der Anwendersoftware.
richtig, es ist eine Zwischenschicht (keine Anwendung), wobei WoW unter D3D sitzen dürfte.
beim beispiel mit 880zu800PPD beim x2 sind die 10% einbusse eher beim zusätzlichen verwaltungsaufwand zu suchen als in einer fehlenden FPU...
nein. bei anderen Projekte habe ich diese, eigentlich, minimalen Einbußen nicht, eher Zugewinn.
....den ohne diese FPU müsste der leistungs abfall um einiges höher sein.
Und noch einmal: Der Anwendung fehlt die FPU nicht, sie wird nur über Umwege (SSE-Unit) angesprochen bzw. emuliert. Die Anwendung (hier Spinhenge) merkt das nicht.
PS: habe auch nur spekuliert!!!
Ich weiß ;)
 
nein das kann sie eben nicht. WoW wandelt die FPU-Befehle in SSE-Befehle um, MMX und FPU werden in WinXP64 und Vista64 nicht mehr unterstützt/angesprochen.
Das bezweifle ich. Wenn ich ein Programm ausführe, die in Native Code vorliegt (also kein .net, Java o. ä.), wird dieser Code doch nicht von Windows interpretiert. Windows erzeugt einen Prozess, lädt den Code in den Speicher usw. und springt dann zum Einstiegspunkt des Codes. Der Code selbst wandert quasi direkt an die CPU und wird dort auf einer Ebene decodiert und an ALU/FPU/SSE/whatever gereicht, auf die Windows gar keinen Zugriff hat.
Was sein kann, ist, dass Windows x64 intern keine FPU nutzt und der Microsoftsche C/C++-Compiler für x64 Code erzeugt, der ohne die FPU auskommt (eingebetteten Assembler-Code ausgenommen).
 
Das bezweifle ich. Wenn ich ein Programm ausführe, die in Native Code vorliegt (also kein .net, Java o. ä.), wird dieser Code doch nicht von Windows interpretiert. Windows erzeugt einen Prozess, lädt den Code in den Speicher usw. und springt dann zum Einstiegspunkt des Codes. Der Code selbst wandert quasi direkt an die CPU und wird dort auf einer Ebene decodiert und an ALU/FPU/SSE/whatever gereicht, auf die Windows gar keinen Zugriff hat.
Was sein kann, ist, dass Windows x64 intern keine FPU nutzt und der Microsoftsche C/C++-Compiler für x64 Code erzeugt, der ohne die FPU auskommt (eingebetteten Assembler-Code ausgenommen).


jetzt hab ich selber noch einmal nachgeschlagen und folgendes gefunden:

WinXp64 (und Vista64) sprechen im 32bit comp.mode die FPU/MMX nach wie vor an, nur läuft das ganze über den WOW64 Wrapper, der die 32Bit App in einem 64Bit System lauffähigbekommt. (dieser wird wohl mit der CPU und dessen 32/64 bit-umschaltfähigkeiten zusammenarbeiten).
Im reinen 64Bit App-Mode steht die FPU/MMX-Einheit nicht mehr zur Verfügung, sie wird auch nicht emluliert. Compiler, die im 64Bit Mode compilieren, müssen das berücksichtigen.

Dann muss ich meine ursprüngliche Aussage revidieren und behaupte das Spin Probleme mit dem WoW64 Wrapper hat ???
 
Zuletzt bearbeitet:
gute antworten habt ihr zwei......big smile

ich muss woll auch mal nachforschungen machen, dabei hab ich doch genug anders zu tun....grrr

auf jedemfall gefällt mir das xp64pro.

gruss thorshammer

oh sehe gerade deinen nachtrag.....big big smile

das schwierige ist, dass man leider nicht wirklich viel im Web findet, und das was man findet kann man beim drüberfliegen schnell missdeuten bzw. ist u.U. auch nicht eindeutig fomuliert. Dazu kommt noch das Person XY dies und jenes dazu gesagt hat.

Ich bleibe aber dennoch bei meiner Aussage das Spin durch den WoW64 Wrapper perfomanceeinbußen hat.
 
Zuletzt bearbeitet:
Zurück
Oben Unten