WPC... geht weiter! -> wpc12
-
Ich werde wohl den Celeron mit 475Mhz benutzen. Weil der einfach deutlich mehr RAM hat und ich dadurch größere Lichterketten fahren kann, ohne daß ich swappen muß. Der Speed-Unterschied zwischen den 475Mhz und den 650 ist ja nicht soo schrecklich riesig.
Der 475Mhz-Rechner hat 75Mhz Bustakt. Ihr könnt also getrost davon ausgehen, daß der Prozessor schneller ist als das RAM.
Ungefähr das System verraten hab ich schon vor ein paar Seiten als ich gesagt hab welche Rechner ich habe.
Ich bin mir ziemlich sicher, daß ihr Eure Meßergebnisse daher getrost übertragen könnt. Die Zahlen werden halt nur nicht ganz so groß.
-
Hm, ein bisschen konnte ich heute nochmal rauskitzeln, andererseits habe ich auch wieder ein bisschen was verloren, nachdem ich festgestellt habe, dass die rndBool() Funktion meines Messprogrammes unbefriedigende Resultate geliefert hat und ich sie etwas umgeschrieben habe... Vorher hat sie zu oft 'true' geliefert, auf ausgeglicheneren Ketten ist mein Algorithmus ein paar ms langsamer. Mist
Mal eine andere Frage, jester, auch wegen der Messung: Ist es wirklich klug, dass der Algorithmus bei Nichtlösbarkeit eine Exception wirft? Da ist zwar an und für sich nichts Verkehrtes dran, aber wenn während der Zeitmessung eine Exception geworfen wird, dann verfälscht das die Messung signifikant... andererseits sollen nicht lösbare Ketten ja sicher nicht ausgeklammert werden?
-
kwaart schrieb:
Ist es wirklich klug, dass der Algorithmus bei Nichtlösbarkeit eine Exception wirft? Da ist zwar an und für sich nichts Verkehrtes dran, aber wenn während der Zeitmessung eine Exception geworfen wird, dann verfälscht das die Messung signifikant... andererseits sollen nicht lösbare Ketten ja sicher nicht ausgeklammert werden?
bei langen ketten verfälscht die exception doch gar nicht messbar.
-
Hm, hast recht. Komisch, ich hatte einmal eine Messung, bei der die Exception über 100ms Verzögerung bewirkt hat, ehe der try/catch-Block fertig war, aber offenbar war das wohl mit deaktivierten Compileroptimierungen. Nichts für ungut, mein Fehler.
-
kwaart schrieb:
Mal eine andere Frage, jester, auch wegen der Messung: Ist es wirklich klug, dass der Algorithmus bei Nichtlösbarkeit eine Exception wirft? Da ist zwar an und für sich nichts Verkehrtes dran, aber wenn während der Zeitmessung eine Exception geworfen wird, dann verfälscht das die Messung signifikant... andererseits sollen nicht lösbare Ketten ja sicher nicht ausgeklammert werden?
Am besten wäre es, einen Vektor, dessen letztes Element N ist, zurückzugeben. Es stehen ja nur die Schalter 0...N-1 zur Verfügung.
-
Was genau wäre daran besser?
Kannst Du bei 1000002 Lichtern durch Messung rausfinden ob ne Excpetion fliegt?
Und bei 100000002?
-
Jester schrieb:
Kannst Du bei 1000002 Lichtern durch Messung rausfinden ob ne Excpetion fliegt?
Und bei 100000002?Da kann gar keine Exception geworfen werden
Es sei denn der Algorithmus ist fehlerhaft.
Selbst wenn Exceptions viel Zeit brauchen sollten, so ist es letztendlich doch egal, weil jeder der Teilnehmer in diesem Fall eine Exception werfen muss, also gleiche Bedingungen für alle.
-
Stimmt.
Da kann nix fliegen. Aber ich wollte ja nix verraten.
Wie auch immer, ich denke nicht, daß es meßbar ist wenn eine fliegt.MfG Jester
-
Nein, bei eingeschalteten Compileroptimierungen kann ich es nicht messen, habe mich da geirrt. Ohne Optimierungen schon, aber da ist der ganze Algorithmus sowieso deutlich langsamer, dass es schon wieder egal wäre
-
Ich hab mal die verschiedenen Versionen des Algorithmus mit verschiedenen Compilern und auf verschiedenen Rechnern getestet. Dabei ist das nicht besonders überraschende Ergebnis herausgekommen, dass je nach Compiler, Compileroptionen und Rechnerarchitektur eine andere Version die schnellste ist. Etwas überrascht hat mit dagegen, dass jede Version des Algorithmus, die bei einer Konstellation die schnellste ist, bei einer anderen Konstellation die langsamste ist.
Deshalb frage ich mal, welcher Compiler in welcher Version wird verwendet und welche Compileroptionen werden genutzt?
Zum Beispiel ist es auf einem Celeron wesentlich, ob man g++ -march=pentium3 -O3 oder nur g++ -O3 benutzt.
-
ich hatte eigentlich daran gedacht nur -O3 zu benutzen. Wäre das okay?
-
Jester schrieb:
ich hatte eigentlich daran gedacht nur -O3 zu benutzen. Wäre das okay?
Das zu deiner Maschine zugehörige -march= wäre besser. Zumindest meiner Meinung nach. Du sparst dann auch Zeit beim Testen, da die Programme schneller laufen.
-
Was genau gehört zu nem Celeron? Pentium II?
Wegen mir auch das.btw.: Ponto, hast Du meine Mail bekommen?
-
Jester schrieb:
Was genau gehört zu nem Celeron? Pentium II?
Wegen mir auch das.ich schau für sowas auf sowas wie http://gentoo-wiki.com/Safe_Cflags
ich schätze, pentium2 ist genau die richtige march.
-
Jester schrieb:
Was genau gehört zu nem Celeron? Pentium II?
Wegen mir auch das.btw.: Ponto, hast Du meine Mail bekommen?
Zu einem Celeron gehört soweit ich weiss -march=pentium3 Aber auch -march=pentium2 macht keinen Unterschied, zumindest nicht auf meinem Celeron 600.
Die Mail hab ich bekommen und eine korrigierte Version wird bald zugeschickt.
-
Okay, gut.
werden dann -march=pentium2 verwenden, das scheint zu meinem Celeron zu passen. Ist auch ein alter Celeron, kein neuer. Als ich denk gekauft hab gab's glaub noch garkeinen P3.
-
Jester schrieb:
Okay, gut.
werden dann -march=pentium2 verwenden, das scheint zu meinem Celeron zu passen. Ist auch ein alter Celeron, kein neuer. Als ich denk gekauft hab gab's glaub noch garkeinen P3.
Bleibt mir nur noch zu sagen, dass die 3.4 Reihe der GCC schlecht optimiert und jede andere Reihe besser ist.
-
Ich werden den gcc verwenden, der bei meinem Dev-Cpp dabei ist. Hab keine Lust dafür jetzt noch was anderes zu installieren. Wenn es was 3.4.x-mäßiges ist, dann habt ihr halt Pech gehabt.
Aber es haben ja alle die gleiche Chance.
-
Wann kann man Ergebnisse erwarten?
-