EPYC-HPC Cluster auf x86-Basis - nur wie?
- Ersteller el-mujo
- Erstellt am
el-mujo
Admiral Special
Guten Abend in die Runde,
Der Thread soll mal der Sondierung des Marktes dienen.
Es geht um HPC - also High Performance Computing und wie man das als Laie oder Amateur für sich nutzbar macht.
Beruflich komme ich mit meinen Standard-Single-Sockel-Windows-Workstations nicht mehr weiter (auch Cloud-basierte Dienste wie Code-DE liefern nicht ansatzweise die nötige Rechenpower). Ich benötige richtig massiv Floating-Point-Power auf Basis von x86. Der Grund: Die eingesetzte Software R setzt ein x86-System voraus. Betriebssystem ist erstmal egal. Es muss nur R mit allen gewünschten Paketen laufen - R-Studio wird nicht zwingend benötigt - dafür wären die einfachen Workstations gedacht. Es geht also um eine extra Recheninstanz, die nur zum Rechnen da ist, ganz ohne GUI und ganz ohne GPU. GPU fällt grundsätzlich flach, da hier mit Floating-Points gerechnet wird, und da kacken GPUs noch immer ab.
Mal grob überschlagen bräuchte ich ein System, dass ca. 200-500 mal schneller rechnet als ein Threadripper-System mit 64-Kern-CPU aus dem Jahr 2020.
Was gibt es da überhaupt für technische Möglichkeiten, dass R auf einem Cluster rechnet? Ich war bisher immer davon ausgegangen, dass ein Multi-Prozessor-System immer auch ein Multi-Sockel-System sein muss, damit es vom OS richtig angesprochen und verwaltet werden kann. Aber beim Epyc ist bei 2 Sockeln schluss mit Lustig. Mehr kann Windows auch garnicht verarbeiten. Dennoch gibt es ja große EPYC-Cluster mit hunderten CPUs.
Aber es gibt ja Systeme, die Modular aufgebaut sind, ich glaube IBM war damals Vorreiter mit seinen Blades. Heute bezeichnet man solche Einschübe als Nodes. Also kleine kompakte Systeme, die in einen größeren Frame geschoben werden - ganz ähnlich der Konzeption von Mainframes. Aber wie aggreriere ich dass dann zu einem sich mir gegenüber als einheitliches System darstellend? Kennt sich jemand grundsätzlich mit solchen Cluster-Geschichten aus oder weiß, wo ich damit gut aufgenhoben bin?
Ansonsten wäre mein Favorit derzeit ein System auf Basis des brandneu erschienenen AMD Epyc 9754 mit dem SR5-Sockel. Der bringt 128 echte Kerne pro Sockel. Das macht schon 512 Threads und wäre schonmal ein kleiner Anfang und eine deutliche Steigerung ggü. meinem alten 24Core-Threadripper und nun Xeon-16-Core-Sparversion. Aber es sollte massiv gesteigert werden, so dass ein parallelisierter Rechenprozess (das Parallelisieren geht ganz simpel über ein Parameter, in dem für jeden Core eine extra Container-Recheninstanz geöffnet wird, also beliebig skalierbar ist) alle Ressourcen eines sich über mehrere Nodes verteilten System nutzen kann.
Also ich will ein R-System, mit sagen wir mal 2048 echten CPU-Kernen, die ich alle über ein einheitliches Skript und daher auch über eine (EINE) installierte R-Softwareinstanz ansprechen kann. Das wäre schon mal ein guter Schritt nach vorn
Und, das es ein AMD-System sein soll, da das wohl die derzeit technische Leistungsspitze mit mehreren Jahren Vorsprung vor Intel ist. Am Ende wird die Sache aber ausgeschrieben werden müssen, so es denn durchgeht. *Haushaltskrise lässt grüßen
Danke schonmal im Voraus.
PS: Es geht um den Wald
EDIT: wie stellt man denn das Foren-Theme auf dunkel? Dachte das ginb mal irgendwie früher.
Der Thread soll mal der Sondierung des Marktes dienen.
Es geht um HPC - also High Performance Computing und wie man das als Laie oder Amateur für sich nutzbar macht.
Beruflich komme ich mit meinen Standard-Single-Sockel-Windows-Workstations nicht mehr weiter (auch Cloud-basierte Dienste wie Code-DE liefern nicht ansatzweise die nötige Rechenpower). Ich benötige richtig massiv Floating-Point-Power auf Basis von x86. Der Grund: Die eingesetzte Software R setzt ein x86-System voraus. Betriebssystem ist erstmal egal. Es muss nur R mit allen gewünschten Paketen laufen - R-Studio wird nicht zwingend benötigt - dafür wären die einfachen Workstations gedacht. Es geht also um eine extra Recheninstanz, die nur zum Rechnen da ist, ganz ohne GUI und ganz ohne GPU. GPU fällt grundsätzlich flach, da hier mit Floating-Points gerechnet wird, und da kacken GPUs noch immer ab.
Mal grob überschlagen bräuchte ich ein System, dass ca. 200-500 mal schneller rechnet als ein Threadripper-System mit 64-Kern-CPU aus dem Jahr 2020.
Was gibt es da überhaupt für technische Möglichkeiten, dass R auf einem Cluster rechnet? Ich war bisher immer davon ausgegangen, dass ein Multi-Prozessor-System immer auch ein Multi-Sockel-System sein muss, damit es vom OS richtig angesprochen und verwaltet werden kann. Aber beim Epyc ist bei 2 Sockeln schluss mit Lustig. Mehr kann Windows auch garnicht verarbeiten. Dennoch gibt es ja große EPYC-Cluster mit hunderten CPUs.
Aber es gibt ja Systeme, die Modular aufgebaut sind, ich glaube IBM war damals Vorreiter mit seinen Blades. Heute bezeichnet man solche Einschübe als Nodes. Also kleine kompakte Systeme, die in einen größeren Frame geschoben werden - ganz ähnlich der Konzeption von Mainframes. Aber wie aggreriere ich dass dann zu einem sich mir gegenüber als einheitliches System darstellend? Kennt sich jemand grundsätzlich mit solchen Cluster-Geschichten aus oder weiß, wo ich damit gut aufgenhoben bin?
Ansonsten wäre mein Favorit derzeit ein System auf Basis des brandneu erschienenen AMD Epyc 9754 mit dem SR5-Sockel. Der bringt 128 echte Kerne pro Sockel. Das macht schon 512 Threads und wäre schonmal ein kleiner Anfang und eine deutliche Steigerung ggü. meinem alten 24Core-Threadripper und nun Xeon-16-Core-Sparversion. Aber es sollte massiv gesteigert werden, so dass ein parallelisierter Rechenprozess (das Parallelisieren geht ganz simpel über ein Parameter, in dem für jeden Core eine extra Container-Recheninstanz geöffnet wird, also beliebig skalierbar ist) alle Ressourcen eines sich über mehrere Nodes verteilten System nutzen kann.
Also ich will ein R-System, mit sagen wir mal 2048 echten CPU-Kernen, die ich alle über ein einheitliches Skript und daher auch über eine (EINE) installierte R-Softwareinstanz ansprechen kann. Das wäre schon mal ein guter Schritt nach vorn
Und, das es ein AMD-System sein soll, da das wohl die derzeit technische Leistungsspitze mit mehreren Jahren Vorsprung vor Intel ist. Am Ende wird die Sache aber ausgeschrieben werden müssen, so es denn durchgeht. *Haushaltskrise lässt grüßenDanke schonmal im Voraus.
PS: Es geht um den Wald
EDIT: wie stellt man denn das Foren-Theme auf dunkel? Dachte das ginb mal irgendwie früher.
Zuletzt bearbeitet:
TOMBOMBADIL
Lt. Commander
Schau dir mal slurm an um mehrere computer zu einem cluster zu verbinden. https://en.m.wikipedia.org/wiki/Slurm_Workload_Manager
R sieht hier aber nicht einen computer, sondern du musst die vorbereiteten Aufgaben mit slurm auf den Maschinen verteilen.
Ansonsten, da du container erwähnt hast, vlt mehrere Maschinen hinter einem kubernetes System verstecken und da dann die Container verteilen lassen?
R sieht hier aber nicht einen computer, sondern du musst die vorbereiteten Aufgaben mit slurm auf den Maschinen verteilen.
Ansonsten, da du container erwähnt hast, vlt mehrere Maschinen hinter einem kubernetes System verstecken und da dann die Container verteilen lassen?
MagicEye04
Grand Admiral Special
Ich nutze das Dark Reader plugin - damit lassen sich alle Webseiten auf Dunkel umstellen.
Maverick-F1
Grand Admiral Special
Wenn die SW Container für die Berechung erzeugen kann, ist halt die Frage ob es gängige Container-Orchestrierungslösungen alà Kubernetes unterstützt?
Weil dann sollte es eigentlich ein Leichtes sein, die Container auf beliebige Clusternodes zu verteilen - aber da bin auch alles andere als ein Spezialist...
Ansonsten gibt es für Xeons nach wie vor 4-Sockel-Systeme - Super-Micro bietet wohl inzwischen sogar 8-Socket-Systeme an - dafür müsstet Ihr aber halt ins blaue Lager wechseln...
Dafür wären dann wohl "immerhin" 480 physische Cores in einem System möglich.
Weil dann sollte es eigentlich ein Leichtes sein, die Container auf beliebige Clusternodes zu verteilen - aber da bin auch alles andere als ein Spezialist...
Ansonsten gibt es für Xeons nach wie vor 4-Sockel-Systeme - Super-Micro bietet wohl inzwischen sogar 8-Socket-Systeme an - dafür müsstet Ihr aber halt ins blaue Lager wechseln...
Dafür wären dann wohl "immerhin" 480 physische Cores in einem System möglich.
el-mujo
Admiral Special
Ja genau, ich müsste die Recheninstanzen nur verteilen - und am Ende die Ergebnisse wieder zusammenführen. Glaub, da muss ich mich mal tiefer informieren, wie das mit R umsetzbar ist. Nicht ganz einfach da noch durchzublicken. Sowas lernt man ja als Naturwissenschaftler nicht wirklich im Studium. Wir können zwar super Algos zur Analyse und so schreiben, aber wie man HPC für sich nutzbar macht gehört nicht zur Ausbildung. Dabei wird das in der Verarbeitung immer größer werdender Datenmengen doch immer wichtiger.
Ich bräuchte eigentlich ein Informatiker an meiner Seite, der wissenschaftlich programmieren kann und der sich mit Hardware/HPC auskennt. Das können leider nur wenige.
www.microway.com
Das dürfte sowas sein, wonach ich suche. Hier mit 160 echten Prozessoren.
Ich hab nochmal mein Bedarf genauer hochgerechnet. Ich bräuchte 45120 echte CPU Kerne. Das wären 352 128-Kern CPUs der neuesten Generation. Mit 2 soclhen Schränken müsste das doch machbar sein - von der Hardware. die schreiben Linux als System. Oder sind das dann solche spezial-Linuxe, die das alles zu einem System vereinheitlichen? Das wär natürlich genial.
Hab aber die Befürchtung, dass das nicht ganz billig wird .... Das wären ja schon 2,3 Mille allein für die Prozessoren ... hmmmm ...am Ende wohl 5 Mio oder so.
Für den Wald - bundesweit - sollte man das dochmal springen lassen können? Was meint ihr Mist!
Ich bräuchte eigentlich ein Informatiker an meiner Seite, der wissenschaftlich programmieren kann und der sich mit Hardware/HPC auskennt. Das können leider nur wenige.
Doppelposting wurde automatisch zusammengeführt:
AMD EPYC Clusters - Microway
Clusters Navion™ Clusters with AMD EPYC CPUs Navion clusters integrate the latest 4th Gen AMD EPYC “Genoa” CPUs. They scale from small departmental clusters to large-scale, shared HPC resources. What Makes a Microway Cluster Unique? Comprehensive Burn-In Testing by Microway Each piece of...
www.microway.com
Ich hab nochmal mein Bedarf genauer hochgerechnet. Ich bräuchte 45120 echte CPU Kerne. Das wären 352 128-Kern CPUs der neuesten Generation. Mit 2 soclhen Schränken müsste das doch machbar sein - von der Hardware. die schreiben Linux als System. Oder sind das dann solche spezial-Linuxe, die das alles zu einem System vereinheitlichen? Das wär natürlich genial.
Hab aber die Befürchtung, dass das nicht ganz billig wird .... Das wären ja schon 2,3 Mille allein für die Prozessoren ... hmmmm ...am Ende wohl 5 Mio oder so.
Für den Wald - bundesweit - sollte man das dochmal springen lassen können? Was meint ihr
Mist!
Zuletzt bearbeitet:
TOMBOMBADIL
Lt. Commander
Sonst mach doch ein BOINC Projekt daraus 
el-mujo
Admiral Special
Hatte ich auch schon überlegt - aber ist das nicht auch etwas aus der Zeit gefallen? Gibt's da überhaupt noch Leute die da mitrechnen? Stromkosten lassen grüßen. War ja selbst einer der Vorreiter auch hier bei P3dNow mit über 5 Mio CPDN-Credit-points.
Von der Sache her wär das aber denkbar. Ein guter PC rechnet an einer Kachel, bzw. einem Stapel einer Kachel, die ist so 100 x100 km groß bei 11000x11000 Pixel, so ca. 40 Tage. Das ist in etwas die Größenordnung, die auch CPDN pro Modell veranschlagt. 50 Kacheln müssen (sollen) kontinuierlich gerechnet werden - mehrmals im Jahr - was der Abdeckung von Deutschland entspricht. Problem ist aber, dass die Berechnung in einem Stück durchlaufen muss.
Jede Berechnung besteht also auf 16,9 Mrd Datenpunkten und gliedert sich in 121 Mio Einzelrechnungen mit je ~140 Datenpunkten pro Kachel auf die eine Dichteverteilungsfunktion angesetzt wird, um über einen nicht-parametrischen Ansatz, die zugrunde liegende Verteilung zu ermitteln.
Diese ist dann meine Basis, anhand derer ich meine Abweichungen von jener bemaße, was also ein zweiter anschließender Rechenprozess ist.
Das nur mal zu den Größenordnungen. Und mit jedem Jahr wird die Datenmenge größer, da die Zeitreihen immer länger werden. Aktuell sind's gerade mal 7-8 Jahre.
Von der Sache her wär das aber denkbar. Ein guter PC rechnet an einer Kachel, bzw. einem Stapel einer Kachel, die ist so 100 x100 km groß bei 11000x11000 Pixel, so ca. 40 Tage. Das ist in etwas die Größenordnung, die auch CPDN pro Modell veranschlagt. 50 Kacheln müssen (sollen) kontinuierlich gerechnet werden - mehrmals im Jahr - was der Abdeckung von Deutschland entspricht. Problem ist aber, dass die Berechnung in einem Stück durchlaufen muss.
Jede Berechnung besteht also auf 16,9 Mrd Datenpunkten und gliedert sich in 121 Mio Einzelrechnungen mit je ~140 Datenpunkten pro Kachel auf die eine Dichteverteilungsfunktion angesetzt wird, um über einen nicht-parametrischen Ansatz, die zugrunde liegende Verteilung zu ermitteln.
Diese ist dann meine Basis, anhand derer ich meine Abweichungen von jener bemaße, was also ein zweiter anschließender Rechenprozess ist.
Das nur mal zu den Größenordnungen. Und mit jedem Jahr wird die Datenmenge größer, da die Zeitreihen immer länger werden. Aktuell sind's gerade mal 7-8 Jahre.
TOMBOMBADIL
Lt. Commander
Ich weiß ja nicht wie genau das funktioniert, aber eventuell kann man das ja optimieren und muss jedes Jahr nur einmal berechnen und speichert das Ergebnis und nutzt es als input im nächsten Jahr?
el-mujo
Admiral Special
Ja, das wäre ein enormer Vorteil. Mal sehen, vllt. kann man an dem Programmcode noch etwas optimieren.
Hier ist das Verfahren, das in Chile entwickelt wurde, beschrieben.
Mir persönlich schwob da noch ein etwas anderer Ansatz vor, in dem Jahre nicht als Reihe von Punkten, sondern als stetige Funktion begriffen werden und so in die Dichtefunktion eingehen, um Jahre mit wenigen Datenpunkten nicht unterzurepräsentieren. Beid er Gelegenheit könnte mans gleich auf Matlab portieren, was deutlich schneller rechnet als R.
Hier ist das Verfahren, das in Chile entwickelt wurde, beschrieben.
Mir persönlich schwob da noch ein etwas anderer Ansatz vor, in dem Jahre nicht als Reihe von Punkten, sondern als stetige Funktion begriffen werden und so in die Dichtefunktion eingehen, um Jahre mit wenigen Datenpunkten nicht unterzurepräsentieren. Beid er Gelegenheit könnte mans gleich auf Matlab portieren, was deutlich schneller rechnet als R.
x87 (klassische Intel FPU) oder AVX? Eine Alternative wären allenfalls dicke ARM-Systeme (Ich weiss nicht ob die bei Float gut sind, die scheinen sich primär an Hyperscaler zu richten), allerdings sollte man da IMHO immer noch etwas Manpower in Form von Experten haben, um allfällige Inkompatibilitäten zu behandeln.
Die Frage ist dann, wie man diese Cluster organisiert. Ich weiss nicht was aktuell der Stand ist, theoretisch kann man die als grosses NUMA-System organisieren, das hat dann aber massive Latenzen. Verbreiteter ist heute der Ansatz, dass man den einzelnen Nodes Arbeit zuweist, da läuft dann auf jedem Node ein eigenes Betriebsystem und Verwaltungssoftware, und die einzelnen Nodes bekommen Arbeitspakete zugeteilt und liefern die Resultate zurück.
Eine kurze Google-Suche hat ergeben, dass R offenbar schon auf diversen Clustern eingesetzt wird, es lohnt sich sicher, mal zu schauen wie das dort gemacht wird.
Blades sind ein Ansatz, um bei gegebenen Platz in einem System mit gemeinsamer Backplane und Stromversorgung mehr Systeme unterbringen zu können. Das Konzept scheint wieder etwas an Traktion verloren zu haben, was vermutlich auch daran liegt, dass moderne CPUs zusehends mehr Strom verbrauchen, was einerseits die Kühlung im Blade erschwert (Das Blade muss dicker werden, was die Packungsdichte reduziert), andererseits muss der Standort auch in der Lage sein, ausreichend Strom und Klimatisierung zur Verfügung zu stellen. Hohe Packungsdichte hilft nichts, wenn man das Rack nur zur Hälfte füllen kann
Der Epyc 9754 hat Zen 4c-Kerne, die sind gegenüber den Zen 4 in einem 9654 etwas weniger leistungsfähig.
https://www.cpubenchmark.net behauptet dass der 9654 schneller sei, andere Benchmarks behaupten das Gegenteil. Im Zweifelsfall solltest du gerade bei den hier angesprochenen Investitionsvolumen möglichst eigene Benchmarks auf der in Frage kommenden Hardware fahren, welche deiner Arbeitslast entspricht.
Wäre es allenfalls auch eine Option, bei bestehenden Grossrechnern Zeit zu beantragen? So grosse Maschinen machen nur Sinn, wenn die auch permanent benutzt werden (Alleine die Kosten für Strom und Klimatisierung werden schnell erheblich).Aber es sollte massiv gesteigert werden, so dass ein parallelisierter Rechenprozess (das Parallelisieren geht ganz simpel über ein Parameter, in dem für jeden Core eine extra Container-Recheninstanz geöffnet wird, also beliebig skalierbar ist) alle Ressourcen eines sich über mehrere Nodes verteilten System nutzen kann.
Also ich will ein R-System, mit sagen wir mal 2048 echten CPU-Kernen, die ich alle über ein einheitliches Skript und daher auch über eine (EINE) installierte R-Softwareinstanz ansprechen kann. Das wäre schon mal ein guter Schritt nach vorn
Intel unterstützten bei den neusten Xeons nur noch 2 Sockel, ich denke die Zeit der richtig grossen Intel-Maschinen mit 4 oder 8 Sockeln ist vorbei. Auch deswegen, weil man heute pro Sockel bei dicken CPUs schnell mal 300+W Abwärme hast, die muss irgendwie auch aus dem Rechner raus. Dazu kommt eine vermutlich eher geringe Nachfrage bei den Kunden, auch mit 2 Sockeln kriegt man heute massiv mehr CPU-Leistung als früher mit 8, und viele Aufgaben lassen sich heute gut auf mehrere Rechner verteilen.
Die Frage ist, was brauchst du? Wenn sich das Problem gut parallelisieren lässt, und keine grosse Abhängigkeiten der einzelnen Aufgaben bestehen, dann kannst du das "relativ" günstig machen mit einigermassen handelsüblicher Hardware, und das Problem dann auf die Rechner verteilen. Wenn du Aufgaben hast, die stark und zeitkritisch untereinander Daten austauschen, dann landest du schnell bei sehr teuren Vernetzungslösungen wie Infiniband.Ja genau, ich müsste die Recheninstanzen nur verteilen - und am Ende die Ergebnisse wieder zusammenführen. Glaub, da muss ich mich mal tiefer informieren, wie das mit R umsetzbar ist. Nicht ganz einfach da noch durchzublicken. Sowas lernt man ja als Naturwissenschaftler nicht wirklich im Studium. Wir können zwar super Algos zur Analyse und so schreiben, aber wie man HPC für sich nutzbar macht gehört nicht zur Ausbildung. Dabei wird das in der Verarbeitung immer größer werdender Datenmengen doch immer wichtiger.
Ich bräuchte eigentlich ein Informatiker an meiner Seite, der wissenschaftlich programmieren kann und der sich mit Hardware/HPC auskennt. Das können leider nur wenige.
Doppelposting wurde automatisch zusammengeführt:
Das dürfte sowas sein, wonach ich suche. Hier mit 160 echten Prozessoren.AMD EPYC Clusters - Microway
Clusters Navion™ Clusters with AMD EPYC CPUs Navion clusters integrate the latest 4th Gen AMD EPYC “Genoa” CPUs. They scale from small departmental clusters to large-scale, shared HPC resources. What Makes a Microway Cluster Unique? Comprehensive Burn-In Testing by Microway Each piece of...
Ich hab nochmal mein Bedarf genauer hochgerechnet. Ich bräuchte 45120 echte CPU Kerne. Das wären 352 128-Kern CPUs der neuesten Generation. Mit 2 soclhen Schränken müsste das doch machbar sein - von der Hardware. die schreiben Linux als System. Oder sind das dann solche spezial-Linuxe, die das alles zu einem System vereinheitlichen? Das wär natürlich genial.
Mainboard, RAM, Massenspeicher, Vernetzung, Klimatisierung, Stromversorgung... kosten auch Geld. Ich würde mich hüten da an Hand des Preises der CPUs eine Preisschätzung für das Gesamtsystem abgeben zu wollen.Hab aber die Befürchtung, dass das nicht ganz billig wird .... Das wären ja schon 2,3 Mille allein für die Prozessoren ... hmmmm ...am Ende wohl 5 Mio oder so.
Für den Wald - bundesweit - sollte man das dochmal springen lassen können? Was meint ihr
MagicEye04
Grand Admiral Special
Womöglich liegt der Schlüssel ja darin, die Berechnung so zu optimieren, dass diese enormen Ressourcen gar nicht mehr nötig wären?
Alan Touring hat beim Knacken der Enigma-Codes ja auch anfangs nicht genug Rechenpower gehabt - erst eine Optimierung der Strategie des Durchprobierens hat dann den Durchbruch gebracht.
el-mujo
Admiral Special
Ja, das ist eigentlich der bessere und saubere Ansatz. Denn die in Chile - das sieht man bei Betrachtung des Quellcodes deutlich - sind keine Informatiker. Da wird z.B. noch viel mit Schleifen gearbeitet. Der Versuch von Floating auf Integer zu wechseln brachte NULL Geschwindigkeitszuwachs. R kann einfach nicht gut bzw. effizient. bzw. schnell rechnen. Das zog sich durchs ganze Studium für verschiedenste Anwendungen. Die haben halt R gewählt, weil's kostenlos ist.
Aber es ist nunmal nicht günstiger. Vor allem dann, wenn die Code-Ausführung derart ineffizient ist, dass die Kosten potenter Hardware die der Software um Größenordnungen übersteigen.
Ja, den Code neu aufzusetzen wäre wohl das Beste, aber das tut mich auch etwas überfordern - derzeit noch. Aber ich kann genau sagen, wass ich haben will. Vllt. ne Promotion ausschreiben oder so. Betreuen kann ich die aber nicht, da mir selbst die Promotion fehlt. Das wäre nur mit ner Masterarbeit möglich.
Wer will sich da probieren?
Soweit erstmal danke für die wertvollen Infos.
Ja, so langsam komme ich ein wenig voran mit dem Cluster.
Stichwort SLURM
slurm.schedmd.com
Also ein Schedule-Manager für HPC-Linux-Cluster. Beschrieben ist das Verfahren auf einfache Weise hier:
Das könnte tatsächlich der goldene Weg sein. Mit einem Sktipt definiert man seine gewünschte Arbeitsumgebung, die sich auch über mehrere Nodes erstrecken kann und definiert ein data-und runtime-environment und schickt das R-Sript mit los. Ich glaub ich muss mal mit ITZBund in Kontakt treten.
Aber es ist nunmal nicht günstiger. Vor allem dann, wenn die Code-Ausführung derart ineffizient ist, dass die Kosten potenter Hardware die der Software um Größenordnungen übersteigen.
Ja, den Code neu aufzusetzen wäre wohl das Beste, aber das tut mich auch etwas überfordern - derzeit noch. Aber ich kann genau sagen, wass ich haben will. Vllt. ne Promotion ausschreiben oder so. Betreuen kann ich die aber nicht, da mir selbst die Promotion fehlt. Das wäre nur mit ner Masterarbeit möglich.
Wer will sich da probieren?
Soweit erstmal danke für die wertvollen Infos.
Doppelposting wurde automatisch zusammengeführt:
Ja, so langsam komme ich ein wenig voran mit dem Cluster.
Stichwort SLURM
Slurm Workload Manager - Overview
Das könnte tatsächlich der goldene Weg sein. Mit einem Sktipt definiert man seine gewünschte Arbeitsumgebung, die sich auch über mehrere Nodes erstrecken kann und definiert ein data-und runtime-environment und schickt das R-Sript mit los. Ich glaub ich muss mal mit ITZBund in Kontakt treten.
Zuletzt bearbeitet:
Ich bin kein Coder, aber ich hätte erwartet dass ein guter Compiler kurze Schleifen wegoptimiert, oder die CPU erschlägt das Problem dann hinterher grösstenteils mit der Sprungvorhersage.
Spätestens wenn du tatsächlich viel Geld für Hardware willst, wir man kritische Fragen stellen, inwiefern die Software denn schon optimiert ist. Das wäre zumindest meine Erwartung.
Möglicherweise stehen bei dir im Institut auch Rechner von Kollegen rum, die du mit Arbeit belegen kannst, wenn die Nachts nicht benutzt werden. Ich hatte so was mal in einem anderen Umfeld, da wurden die Workstations nachts für Berechnungen genutzt.Ja, so langsam komme ich ein wenig voran mit dem Cluster.
Stichwort SLURM
Also ein Schedule-Manager für HPC-Linux-Cluster. Beschrieben ist das Verfahren auf einfache Weise hier:Slurm Workload Manager - Overview
Das könnte tatsächlich der goldene Weg sein. Mit einem Sktipt definiert man seine gewünschte Arbeitsumgebung, die sich auch über mehrere Nodes erstrecken kann und definiert ein data-und runtime-environment und schickt das R-Sript mit los. Ich glaub ich muss mal mit ITZBund in Kontakt treten.
TOMBOMBADIL
Lt. Commander
Ist matlab da so viel schneller wenn der Code die identische unoptimierte Schleife macht? R Code kann man auch optimieren und vektorisieren. Matlab und R sind beides interpreted languages. Matlab hat halt einige hoch optimierte packages die selbst in c/c++ geschrieben sind. Aber R hat das ja auch... Bei R ist aber vermutlich die Qualität der 3rd Party packages nicht immer so hoch wie bei vom matlab Team selbst vertriebenen...
Wenn der Code nicht von so einem c/c++ package gebrauch machen kann, glaube ich nicht das matlab die lösung ist. Dann eher c/c++, wobei matlab nach c compilieren kann soweit ich weiß. Wenn du also matlab programmieren kannst aber nicht c/c++, dann wäre das eine Option trotzdem an c Code zu kommen.
Wenn der Code nicht von so einem c/c++ package gebrauch machen kann, glaube ich nicht das matlab die lösung ist. Dann eher c/c++, wobei matlab nach c compilieren kann soweit ich weiß. Wenn du also matlab programmieren kannst aber nicht c/c++, dann wäre das eine Option trotzdem an c Code zu kommen.
el-mujo
Admiral Special
Wie das mit Schleifen ist weiß ich nicht genau. Aber allein das Auftrennen von Rastern in einzelne Spektralbänder erledigt Matlab um Faktor 200 schneller - nachgemessen.
Die Berechnung von Matrizen ist nunmal die Spezialität von MatLab - daher ja auch der Name. Und Raster bzw. Bilder sind nichts weiter als n-dimensionale Matrizen zumindest solange sie Pixelbasiert sind und nicht über Interpolationen rechnen wie JPG. Den Vektorisierungs-Tipp hab ich bereits an die Entwickler weitergereicht - leider bisher ohne Erfolg. Das Blöde ist, dass ich selbst den Quellcode nicht verändern kann, da R dann die Ausführung nicht hinbekommt und immer mit einer Fehlermeldung quittiert. Ich muss nichtmal was ändern - nur das manuelle Ausführen des Codes schlägt schon fehl. Es will/muss über die bereitgestellte Funktion benutzt werden.
Mir wäre die Portierung auf Matlab in der Tat am liebsten. Die Schwieigkeit liegt eigentlich nur in der Programmierung eines Moving-Window - das macht R in dem Falle elegant parallel über die Cluster-Funktion in R. Also ein Prozess, der Pixelweise den Durchstich durch den Bildstapel an Pixel-XY macht, die Berechnung durchführt und anschließend das Ergebnis (ein eiziger Wert) für den Pixel zurückliefert. Für jeden Pixeldurchstrich ein Prozess - auf einem Prozessor. Jeder Pixel ist dabei vom Rest völlig unabhängig. Matlab selbst ist woweit ich weiß in C++ geschrieben.
Kann doch eigentlich nicht so schwer sein ...
Ist doch kein Hexenwerk wie DL, sonderrn nur schnöde Rasterdatenverarbeitung mit 250 Jahre alten Algorithmen (Gauss).
Zuletzt bearbeitet:
TOMBOMBADIL
Lt. Commander
Ah das heißt ja nichts. R ist in c und fortan geschrieben und python (CPython) in c. Aber gut, das matlab mit Matrizen schneller umgehen kann glaub ich dir.
Ob alles 200 mal schneller ist... wer weiß? Aber klingt auf jeden Fall mal so als ob das wirklich erstmal in Software optimiert werden sollte, bevor du dir für ein paar Millionen deinen eigenen HPC cluster zulegst.
Ob alles 200 mal schneller ist... wer weiß? Aber klingt auf jeden Fall mal so als ob das wirklich erstmal in Software optimiert werden sollte, bevor du dir für ein paar Millionen deinen eigenen HPC cluster zulegst.
Also zumindest unter Windows ist Matlab@AMD wirklich mies, was an der Intel MKL liegt. Man kann eine andere MKL definieren, aber das "gelbe von Ei" ists dann trotzdem nicht.
Wenn Dir R zu langsam ist, was je nach Anwendung, Package und Skills durchaus beachtlich sein kann, dann schau Dir doch mal den "heißen scheiß" Python an genauer an. Zumindest bekomme ich das Feedback, dass Python durchaus fixer als R ist und auch in den Paradedisziplinen von Matlab gut rumwildert.
Sind die Berechnungen gut (von Hand) parallelisierbar? Benötigst Du eine Interaktion? Sonst würde sich wirklich ein HPC mit Batch lohnen. Mittlerweile schnallen ja auch die HPC-Päpste, dass eine hohe Auslastung der Systeme sinnvoll ist.
Wenn Dir R zu langsam ist, was je nach Anwendung, Package und Skills durchaus beachtlich sein kann, dann schau Dir doch mal den "heißen scheiß" Python an genauer an. Zumindest bekomme ich das Feedback, dass Python durchaus fixer als R ist und auch in den Paradedisziplinen von Matlab gut rumwildert.
Sind die Berechnungen gut (von Hand) parallelisierbar? Benötigst Du eine Interaktion? Sonst würde sich wirklich ein HPC mit Batch lohnen. Mittlerweile schnallen ja auch die HPC-Päpste, dass eine hohe Auslastung der Systeme sinnvoll ist.
Ähnliche Themen
