Fersus
Bloody Newbie
|
ahja sehr cool 
|
Rogaahl
Elderinterrupt
|
mmd  Edit: Schade doch nicht so lustig, habe Schublade gelesen..
|
that
Hoffnungsloser Optimist
|
Die Datenmenge ist für gewöhnlich vernachlässigbar. Meistens lese ich die Daten einmal ein und habe Sie dann eh im RAM. Für lange Simulationen muss ich aber immer wieder Zwischenergebnisse rausschreiben, d.h. ein .txt oder .csv file öffnen, am Ende des Files eine neue Zeile einfügen und wieder schließen.
Bei einer Testsimulation habe ich mir mal angesehen, wie sehr dieses Speichern die Laufzeit beeinflusst. Das war enorm! ohne speichern brauchte es nichtmal eine Minute, mit Speichern ca. 20. Deshalb hege ich die Hoffnung dass so eine M.2 SSD mir da weiter helfen kann... Nur die Ausgabe eines CSV-Files kann nicht 19 Minuten dauern, nicht einmal auf einer sehr alten Festplatte und ohne Cache, außer die Datei ist extrem groß und die Festplatte ist per USB 1.1 angebunden. Ich probiers nochmal: Wie groß ist "vernachlässigbar", wieviele Zeilen schreibst du in das CSV-File, in welchem Zeitabstand, und wie groß wird das File am Ende? Generell ist es effizienter, die Datei offen zu lassen statt für jede Zeile neu zu öffnen und zu schließen, was aber nur dann wirklich relevant ist, wenn das mehrmals pro Sekunde passieren soll.
|
Fersus
Bloody Newbie
|
Ich schreibe ja nicht nur einmal rein, sondern für gewöhnlich habe ich einen großen Suchraum, in dem ich nach gewünschten Ergebnissen suche. D.h. in regelmäßigen Abständen schreibe ich meinen Progress nieder, damit ich nicht zu viel verliere, sollte irgendwas passieren was den RAM löscht (Strom weg o.Ä.) und wann immer eine Konfiguration die gewünschten Eigenschaften hat wird der Index dieser Konfigurtion ebenfalls nieder geschrieben.
Also mein aktuelles Problem funktioniert so, damit ihr euch mal ein Bild machen könnt von der Art von Problemen die ich bearbeiten möchte:
Ich habe g Gruppen zu e Elementen. In Summe also g*e Elemente. Diese sollen nun permutiert, also auf die unterschiedlichen Gruppen aufgeteilt, werden. Die Reihenfolge der Gruppen und die Reihenfolge innerhalb einer Gruppe ist dabei unerheblich.
Mit jeder dieser Konfigurationen muss ich ein paar simple Operationen machen: äußeres Produkt, aber statt mit "*" mit ">", dannach gruppenweise summieren, dann überprüfen ob ein Nashgleichgewicht vorliegt. Wenn KEIN Nashhleichgewicht vorliegt: merken, wenn schon: verwerfen.
für g=5 und e=6 sind das ~10^16 Möglichkeiten. Selbst wenn ich in einer Sekunde eine Milliarde Fälle überprüfen könnte, würde das 35 Jahre dauern. D.h. ich muss da noch einiges an Hirnschmalz reinstecken um den Suchraum zu verkleinern.
In der zwischenzeit übe ich mich schon mal an kleineren Problemen (g=5 und e=3 sind nur 1,4 Millionen Fälle mit 44 Ergebnissen, 5*4 sind 2,5 Mrd Fälle und ca. 2000 Ergebnisse) am Optimieren des Codes und lernen neuer Techniken (parrallelisieren) um den verbleibenden Suchraum schneller durchsuchen zu können.
Eine Idee ist nicht immer gleich den ganzen Vektor zu überprüfen sondern nur mal einen kleinen Teil, also die ersten beiden Gruppen. Wenn die schon mal nicht passen kann ich gleich (im Falle von g5e6) die nächsten 126126 Fälle überspringen...
Wieviele das sind weiß ich aber im Vorfeld noch nicht, also schreibe ich halt mal mit.
im Falle von g5e3 (~1,4Mio) hat mein erste Codeversuch (mal nur proof of concept, noch nichts optimiert, immer ganzen Vektor überprüft) nicht ganz 3 min gedauert und 44 Ergebnisse geliefert. Für g5e4(2,5Mrd) habe ich den iterativen Ansatz gewählt um zu sehen wie viee Fälle ich mir ersparen würde. Da hat die erste Iteration ca. 400k Fälle, aber hat ~290k Ergebnisse geliefert. D.h. es wurde 290k Mal eine neue Zeile ins Protokoll geschrieben, und das hat halt ~20 min gedauert...
|
Crash Override
BOfH
|
Das spricht sehr für EINE nvme SSD für System und Daten. SSDs werden schneller je größer sie sind. Eine Festplatte schafft 100 Schreiboperationen pro Sekunde, eine Samsung 960 EVO 500G dagegen schon 330.000.
Unter der würde ich nicht mit einer Workstation anfangen. Ansonsten die SSD lieber größer wählen anstatt eine 2.
|
Fersus
Bloody Newbie
|
Aber an eine RAM Disk kommt das ja trotzdem nicht ran, nehme ich an? Weil ich denke, dass ich damit wirklich am besten fahre: die Protokolle in den RAM schreiben lassen und alle paar Minuten per skript eine Sicherheitskopie anlegen. Letzteres sollte die Simulation ja gar nicht beeinflussen und schneller wie RAM wirds wohl nicht werden...
|
that
Hoffnungsloser Optimist
|
Aber an eine RAM Disk kommt das ja trotzdem nicht ran, nehme ich an? Weil ich denke, dass ich damit wirklich am besten fahre: die Protokolle in den RAM schreiben lassen und alle paar Minuten per skript eine Sicherheitskopie anlegen. Letzteres sollte die Simulation ja gar nicht beeinflussen und schneller wie RAM wirds wohl nicht werden... Genau das macht das Betriebssystem schon immer so und ganz von selbst - Schreibzugriffe werden prinzipiell im RAM zwischengespeichert, so dass die Daten im Hintergrund auf die Platte rausgeschrieben werden können.
|
Crash Override
BOfH
|
@that: nicht unbedingt. Es gibt Sync writes und Buffered writes. Sync writes werden ehrst commited, wenn sie auf Platte angekommen sind.
@Fersus: Die Ramdisk klaut dir RAM und bietet natürlich auch keinerlei Sicherheit. Wenn du die Daten nicht Programmtechnisch im RAM halten kannst ist eine Ramdisk auch nur eine Krücke um schlechte Programmierung auszugleichen.
|
Viper780
ElderEr ist tot, Jim!
|
Warum ein CSV File?
Sowas hat man in den 70iger gemacht.
Schreib doch bitte in eine In-Memory-Datenbank und lass ein teil der (Metadaten) Operationen da drauf laufen.
Ich hab morgen einen Termin wo es etwas konkreter wird.
Zum System:
Warum so ein starkes Netzteil? 450W sollten eigentlich reichen
Je nach dem wie knapp kalkuliert werden soll würd ich gleich eine m.2 SSD nehmen (Samsung SSD 960 EVO 500GB ab ~220€)
Ich würd mir trotzdem mal ansehen wie gut dein Code auf Kerne >4 skaliert und ob ein Intel mit AVX512 nicht wesentlich flotter ist
|
Fersus
Bloody Newbie
|
@Crash Override: Wie gesagt ist die Datenmenge normalerweise verachlässigbar. Wenn ich mir ein halbes GB vom RAM klau und dafür superschnell Ergebnisse zwischenspeichern kann ist das ausreichend. Aber ja: vermutlich ist vieles an Zeitverzögerung meiner mangelnden Programmierkenntnis geschuldet ^^ Aber immerhin: mein Testcase ist durch RAMdisk heute in 7 statt 17 min gelaufen @Viper780: CSV bzw. txt reichen normalerweise, sind platzsparend und problemlos in Excel weiter verarbeitbar. Das Netzteil hab ich so stark gewählt, damit, sollte ich irgendwann mal genügend Durchblick bzgl. GPU Programmierung haben, mir eine zweite dazu hängen kann... Ein Intel mit was?
|
that
Hoffnungsloser Optimist
|
@Aber immerhin: mein Testcase ist durch RAMdisk heute in 7 statt 17 min gelaufen Schreibst du für jede neue Zeile das ganze File neu? Weil sonst gibts das ja nicht, dass das so langsam ist.
|
Fersus
Bloody Newbie
|
nein, es wird nur an das bestehende file eine Zeile angefügt. 290k mal. hat nachher 4MB
|
that
Hoffnungsloser Optimist
|
nein, es wird nur an das bestehende file eine Zeile angefügt. 290k mal. hat nachher 4MB Ich habe das mal schnell in meiner Shell simuliert, und wie zu erwarten war dauert das keine 10 Minuten, nicht einmal 2 Sekunden: $ time for i in {1..290000}; do echo 12345678,$i >> test; done
real 0m1.597s
user 0m1.188s
sys 0m0.399s
Ich weiß nicht, was du da machst, aber es wird nicht an einer langsamen Platte liegen.
|
Fersus
Bloody Newbie
|
Ich weiß nicht, was du da machst, aber es wird nicht an einer langsamen Platte liegen. das ist gut, dann ist das einfach nur ein Software Problem, was bedeutet, ich muss nicht all zu viel Geld für die Platte ausgeben Ich verwende aktuell die Statistik Software R und der Befehl ist einfach der native "write.table" Befehl.
|
Viper780
ElderEr ist tot, Jim!
|
Ich meinte damit eine moderne Intel CPU die spezielle Befehle hat für Vektor und Matrizen Operationen https://en.wikipedia.org/wiki/AVX-512Je nach dem was du für einen Solver hast sind die sehr schlecht parallelisiert. Im Grunde macht man das mit dem csv File so nicht mehr. Das kostet nur unnötig Performance und es ist nur schwer reproduzierbar bzw nachher nicht sauber versionierbar. R ist für Datenoperationen halt nicht gedacht und frisst deshalb nochmals an performance. Wir werden deshalb Python nehmen und überlegen ob wir die Datenoperationen nicht besser direkt in der Datenbank (welche ist noch offen) mit SQL machen. Da es Konnektoren für GAMS (den von uns favorisierten Solver) zu diversen Datenbanken gibt passt das gut ins Konzept. Schau mal an was aktuelle BI Lösungen für den Umgang mit Daten so alles bereit stellen. Da wird sich bei den Modellierern in den nächsten Jahren viel tun
|
Anmeldung