Was zur Hölle ist hier los: FX 8150 vs Core2Dou E6400

Okay, werde ich mal testen. Jetzt frage ich mich im Moment nur, warum der Compiler nach einer Berechnung unter Windows nicht die Daten aus dem Ram nimmt, sondern mir alles "zuknallt".
 
Du meinst der Speicher wird nicht freigegeben? Klingt dann eher nach schlechtem Speichermanagement.
 
Also: Ich habe eine Graphenschicht, bestehend aus 8 Atomen. Nun möchte ich schauen, was das System nach 10 fs macht. Dabei berechnet mir das Programm 20 Zeitschritte zu je 0.5E-14 s.
Das Programm selber schreibt mir unter Windows zwar nach jedem Zeitschritt die berechneten Daten in die Datei. Leider wird im Ram der Speicher nicht weiter freigegeben. Das Programm schaut nach jedem Schritt, wieviele Schritte schon berechnet wurden und rechnet beim letzten Schritt automatisch weiter (wobei die berechneten Daten aus dem Ram geworfen werden sollen). Nun schleift aber das Programm noch die Daten der ersten Schritte im Ram mit umher und schreibt ihn dann voll, was eigentlich nicht sein kann.
Alles sehr komisch mit den Betriebssytemen^^....
 
Zuletzt bearbeitet:
Welches Modell? Tight Binding? Welches Näherungsverfahren, iterativ/rekursiv? Letzteres könnte auf das Speicherproblem hindeuten. Ein paar mehr Informationen wären schon hilfreich. Oder gleich der Quelltext ;)
 
Es wird eine modifizierte MD Simulation, basierend auf den Kohn Sham Gleichungen, durchgeführt (die quantenmechanischen Wellenfunktionen im Grundzustand wurden weiter optimiert für noch genauerer Berechnungen). Es ist eine selbstkonstiste Rechnung. Die Gleichungen werden iterativ gelöst, bis ein gewisser Konvergenzpunkt erreicht ist. Die Zeitschrittsteuerung erfolgt über den sogenannten Verlet-Velocity-Algorithmus.
Es werden entsprechende Eingabedaten zum Zeitpunkt t=0 s eingelesen und ein Zeitschritt vorgegeben. Danach werden für die Daten bei t=0 s die Gl. iterativ gelöst. Danach werden diese berechneten Daten -zum Zeitpunkt t=10E-14 s- genommen und es werden wieder die Gl. iterativ gelöst. Und dann so weiter und so fort....
Das Ganze wurde für den Intel Compiler unter Lunix geschrieben und auch soweit optimiert. Sowas mit Parallelisierung, Freigabe des Speichers....
Mein Freund, der schon länger sich mit dem Programm beschäftigt, hat es soweit auf Windows zum Laufen bekommen mit ein bisschen Mühe. Ob er selber die Probleme mit der Speicherfreigabe hat/hatte muss ich noch erfragen. Es könnte auch an dem Compiler liegen. Ich lade mir grad den Intel Compiler runter. Jedenfalls werde ich wohl alles auf Lunix legen. Vill. finde ich noch zusammen mit ihm den Fehler bei Windows =).
 
Also im Großen und Ganzen Dichtefunktionaltheorie. Mit Velocity-Verlet habe ich schon mal ein Schwarmmodell geschrieben. Das hatte weder unter Linux, noch unter Windows ein Speicherleck ;)

Ich würde da mal bei den ganzen Optimierungen ansetzen.
 
So der Abschluss^^:
Habe nun Linux installiert und das Programm mit nem Intel Ifort Compiler kompiliert. Der FX zeigt jetzt endlich mal seine Stärken -> diese liegen 100%ig im Multitasking. Das Programm verteilt die Last schön auf alle "integer cores". Die Gesamtlast liegt im Schnitt bei ~ 45%. Der C2D ist dem FX deutlich unterlegen.
Zu dem Problem mit der Speicherfreigabe:
Hierbei muss man wohl nochmal schaun, wo das Problem in Code liegt. Unter Linux wird der Speicher nach jeder Interation freigegeben. Das macht Windows jedoch nicht mit. Versuche es auch mal dem Intel Compiler neu zu kompilieren.

LG
 
Schön das es dann doch geklappt hat. Noch ne Frage: Hat der Patch irgendwas gebraucht, bzw. funktioniert er überhaupt?
 
Zurück
Oben Unten