Hallo liebe Forengemeinde!
Mein Programm besitzt ca 3000 Zeilen Code -- und da ich es mit unterschiedlichen Parametern aufrufe, habe ich es in eine for Schleife eingebettet -- das resultierte dann mal in einem ordentlichen Ram overflow
-- worauf hin ich meine Funktionen in Module ausgelagert habe. Der Quellcode umfasst nun ca 1500 Zeilen, der Schleifenkörper ist der gleiche, nur mit dem Unterschied, dass ich anstatt 7GB Ram nur noch 1 GB im Speicher hängen habe.
Bringen Module in diesem Falle so viel weniger Ram Belastung? Ich meine gelesen zu haben, dass die Programme durch 'vorkompilieren' nicht schneller werden. Ich bin bisher immer davon ausgegangen, dass sie einzig und allein zum Quellcode schrumpfen da sind .
weniger Ram Verbrauch dank Modulen?
- Defnull
- User
- Beiträge: 778
- Registriert: Donnerstag 18. Juni 2009, 22:09
- Wohnort: Göttingen
- Kontaktdaten:
Selbst ein Python-Programm mit 10^6 Zeilen Code verbraucht keine 7GB Ram! Das Speicherproblem liegt definitiv in deiner Implementierung und nicht in der Größe des Python codes. Was tut das Programm denn?
Bottle: Micro Web Framework + Development Blog
Hi!
....alles Mögliche ...
pdb Files(Kristallstrukturen von Enzymen) einlesen, berechnen wo es zu Interaktion zwichen Ligand und Bindingsite kommt, und schließlich Kraftfeldpunkte (also x/y/z + Energiewert; --> alles in einem Asci File) auf diese Interaktionspunkte via Distanzmatrix matchen.
Die Kraftfelder sind ziemlich große Dateien (15-20MB), mit ein Paar Interaktionpunkten kommt schnell mal eine Dist. Matrix von 50 x 60.000 zustande -- das ganze *4 (4 Felder);
... das alles für eine Struktur....insgesamt habe ich 85 davon.
verwendete Module (nicht meine eigenen):
openbabel
pybel
biopython
numpy
und hcluster (für die Distanzmatritzen)....
ich bin einfach verwundert, dass das bisschen modularisieren so viel bringen soll.
--- an der eigentlichen Implementierung hab ich nichts geändert!
gruß,
flo
....alles Mögliche ...
pdb Files(Kristallstrukturen von Enzymen) einlesen, berechnen wo es zu Interaktion zwichen Ligand und Bindingsite kommt, und schließlich Kraftfeldpunkte (also x/y/z + Energiewert; --> alles in einem Asci File) auf diese Interaktionspunkte via Distanzmatrix matchen.
Die Kraftfelder sind ziemlich große Dateien (15-20MB), mit ein Paar Interaktionpunkten kommt schnell mal eine Dist. Matrix von 50 x 60.000 zustande -- das ganze *4 (4 Felder);
... das alles für eine Struktur....insgesamt habe ich 85 davon.
verwendete Module (nicht meine eigenen):
openbabel
pybel
biopython
numpy
und hcluster (für die Distanzmatritzen)....
ich bin einfach verwundert, dass das bisschen modularisieren so viel bringen soll.
--- an der eigentlichen Implementierung hab ich nichts geändert!
gruß,
flo
Du hattest vorher wahrscheinlich viel mehr Objekte nutzlos herumliegen die der GC nicht aufgeräumt hat weil du noch Referenzen darauf hattest. Durch die Module hast du das Problem sicherlich eingedämmt aber trotzdem dürfte der Code grausam sein.
-
- User
- Beiträge: 996
- Registriert: Mittwoch 9. Januar 2008, 13:48
Würde mich brennen mal interessieren, der Code. Da gibts bestimmt einiges zu optimieren ;-)
Hoi,
- Wieso hast Du mehrere Kraftfelder? Normalerweise braucht man für eine Simulation genau eines. Ggf. möchte man verschiedene vergleichen. Ok, aber denn läßt man doch verschiedene Simulationen mit je einem Kraftfeld laufen, oder was machst Du da Außergewöhnliches???
- Wieso sind die Kraftfeldspezifikationen so riesig? Ich kenne keine einzige, die so groß ist und ich kenne einige .
- So eine Dinstanzmatrix ist an sich schon problematisch, weil extrem schlecht skalierbar. Du solltest Dir vielleicht mal ein Buch zum Thema Simulieren anschauen, bzw. berücksichtigen, was Dein Kraftfeld für einen fall-off hat, denn unendliche Wechselwirkungen willst Du doch sicher nicht berücksichtigen, oder?
Und bist Du Dir sicher, daß Python die Programmiersprache der Wahl für MD-Simulationen ist?
Und bist Du Dir sicher, daß Du das Rad neu erfinden willst? Es gibt freie MD-Simulationsprogramme und welche für wenig Geld (sogar mit Pythoninterface - will hier keine Werbung machen, aber bei Interesse PN an mich), die sogar auf Mehrkernprozessoren oder / und Clustern laufen.
Gruß,
Christian
edit: Ups, oder machst Du Docking. Dann wäre dass zwar ein ähnlicher Fall, aber mein Kommentar zum Thema Distanzmatrix wäre entsprechend abzuändern - aber nicht viel. Auch in diesem Fall gibt es andere, freie und unfreie Programme, teils auch mit Pythoninterface.
Neben den Dingen, die die anderen hier schon angesprochen haben, interessiert mich:acidk hat geschrieben:Die Kraftfelder sind ziemlich große Dateien (15-20MB), mit ein Paar Interaktionpunkten kommt schnell mal eine Dist. Matrix von 50 x 60.000 zustande
- Wieso hast Du mehrere Kraftfelder? Normalerweise braucht man für eine Simulation genau eines. Ggf. möchte man verschiedene vergleichen. Ok, aber denn läßt man doch verschiedene Simulationen mit je einem Kraftfeld laufen, oder was machst Du da Außergewöhnliches???
- Wieso sind die Kraftfeldspezifikationen so riesig? Ich kenne keine einzige, die so groß ist und ich kenne einige .
- So eine Dinstanzmatrix ist an sich schon problematisch, weil extrem schlecht skalierbar. Du solltest Dir vielleicht mal ein Buch zum Thema Simulieren anschauen, bzw. berücksichtigen, was Dein Kraftfeld für einen fall-off hat, denn unendliche Wechselwirkungen willst Du doch sicher nicht berücksichtigen, oder?
Und bist Du Dir sicher, daß Python die Programmiersprache der Wahl für MD-Simulationen ist?
Und bist Du Dir sicher, daß Du das Rad neu erfinden willst? Es gibt freie MD-Simulationsprogramme und welche für wenig Geld (sogar mit Pythoninterface - will hier keine Werbung machen, aber bei Interesse PN an mich), die sogar auf Mehrkernprozessoren oder / und Clustern laufen.
Gruß,
Christian
edit: Ups, oder machst Du Docking. Dann wäre dass zwar ein ähnlicher Fall, aber mein Kommentar zum Thema Distanzmatrix wäre entsprechend abzuändern - aber nicht viel. Auch in diesem Fall gibt es andere, freie und unfreie Programme, teils auch mit Pythoninterface.