URL: https://www.overclockers.at/desktops/einsteiger-workstation_249884/page_4 - zur Vollversion wechseln!
ahja sehr cool
mmd 
Edit: Schade doch nicht so lustig, habe Schublade gelesen..
Zitat aus einem Post von FersusDie 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...
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...
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.
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...
Zitat aus einem Post von FersusAber 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: 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.
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
@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?
Zitat aus einem Post von Fersus@Aber immerhin: mein Testcase ist durch RAMdisk heute in 7 statt 17 min gelaufen
nein, es wird nur an das bestehende file eine Zeile angefügt. 290k mal. hat nachher 4MB
Zitat aus einem Post von Fersusnein, es wird nur an das bestehende file eine Zeile angefügt. 290k mal. hat nachher 4MB
Code:$ time for i in {1..290000}; do echo 12345678,$i >> test; done real 0m1.597s user 0m1.188s sys 0m0.399s
Zitat aus einem Post von thatIch weiß nicht, was du da machst, aber es wird nicht an einer langsamen Platte liegen.
Ich meinte damit eine moderne Intel CPU die spezielle Befehle hat für Vektor und Matrizen Operationen https://en.wikipedia.org/wiki/AVX-512
Je 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
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2026