LinuxClient draussen !!!

[[Muon.FG]7F4]

Das habe ich auf dem Windows Client nie gesehen, da ist spätestens bei 60000 + x Schluß...

Das ist so nicht richtig -> sieh dir mal die Top250 von Stephen an!

Was ich natürlich jetzt schon sagen kann, ist das ich den Sack voll warnings, den ich beim kompilieren bekommen habe, nicht so ohne weiteres ignorieren würde.
Da waren einige ernstzunehmende cast-warnings (double/int mix etc.) drin.

Magst du recht haben (hab ich auch nicht ignoriert), allerdings sind diese Warnings alle aus dem Orginalcode übernommen, und unkritisch, da casts von double zu int an diesen Stellen gewollt sind (wollte nicht noch überall cast operatoren einbauen) - gcc ist halt mit seinen Warnmeldungen dem Borland C-Compiler von Stephen voraus

Nachdem ich mir die sourcen mal etwas näher betrachtet habe, denke ich sowieso, daß das Ding etwas auf "tönernen Füßen" steht ...

Oh, ich bin für jeden Hinweis dankbar!

[huraxprax]

Hi Ronny,
gut daß du auch hier vorbeischaust, du kennst das ja besser als wir hier.
Also war das wohl eine Mutarion von den obersten Ergebnissen gewesen sein mit 78xxx Partikeln? Ich hatte sowas noch nicht.
Dann könnt ihr beide das ja verbessern

Aber kannst du mal #include <stdlib.h> in die tools.cpp reinmachen? gcc 3.x und der berüchtigte 2.9x von Redhat kennen 'exit' sonst nicht.

Ansonsten hatte ich mit -O3 eine leichte verbesserung, mit gcc 3.2 und -march=athlon etwa 15% über der Standardversion, ich weiß jetzt nicht wie das auf nem Intel ausschaut.

Ciao, Benno

[[Muon.FG]7F4]

Hi Benno

<stdlib.h> kann ich in die tools.cpp einbauen, mir müssen solche Probleme nur berichtet werden ...

was O3 angeht kommt es wahrscheinlich stark auf den Compiler an, bei meinem 2.95.3 waren keine Geschwindigkeitsvorteile zu erkennen, im Gegenteil, es war sogar geringfügig langsamer ...

Mit dem Quellcode und leichten Modifizierungen der Makefile kann man ja für seine eigene Architektur übersetzen -> aber wenn's geht das Ergebnis testen. Hatte auch schon mal Erfahrungen mit einer C++ Klasse und O3 Optimierung: eine virtuelle Funktion wurde plötzlich nicht mehr aufgerufen, frag net... (bei O2 funktionierte es)
werde mich wohl auch der Fehlermeldungen entledigen (mit casts) die nerven dann nicht mehr so beim kompilieren (wollte ursprünglich am Orginalquelltext nicht soviel ändern ...)

ich denke, ich werde dann auch demnächst den Beta-Satus abschließen - es funktioniert soweit (mir bekannt) alles

Ronny

[Euler]

Ich hab jetzt ein paar mehr results, und es sieht so aus, als ob alles okay ist.

Trotzdem, die Partikelzahlen sind signifikant höher, als beim Windows Client. Das lässt sich nicht mehr mit einer Mutation erklären.

Code: Alles auswählen

2.638394 (80777 particles) [v4.21b] {B75C17BC}
2.497686 (63066 particles) [v4.21b] {B75C17BC}
2.410255 (62619 particles) [v4.21b] {B75C17BC}
2.506425 (61848 particles) [v4.21b] {B75C17BC}

Hinweis: Diese Maschine ist sehr langsam (400 MHz,AMD K6-III).

Kann es sein, daß da irgendein Echtzeitparameter in die Simulation greift?
An sich sollte die Simaulation unabhängig von der CPU performance sein.

Euler

[Pascal]

Ich hab jetzt ein paar mehr results, und es sieht so aus, als ob alles okay ist.

Trotzdem, die Partikelzahlen sind signifikant höher, als beim Windows Client. Das lässt sich nicht mehr mit einer Mutation erklären.
..

Die höheren Partikelzahlen sind laut Stephen ok. Ich hatte ihn gefragt.

[Euler]

Die höheren Partikelzahlen sind laut Stephen ok. Ich hatte ihn gefragt.

Das mag ja sein, ist aber keine Erklärung, warum der Linux Client sie produziert.

Oder aber, vielleicht auch nur auf einer sehr langsamen Maschine produziert.

Oder, nur auf meiner Maschine ?

Euler

[Pascal]

Die Partikelzahlen hängen eher nicht von der Maschine ab. Huraxprax hatte mir von den höheren Werten erzählt.