C++ parallele Rechnungen
-
Hi,
knivil schrieb:
MPI ist fuer Cluster mit non-shared-memory. Ein 4, 6 oder 48-Kern-Prozessor ist keine shared-memory-Architektur.
Nun, meine Antwort ist jetzt ein wenig gewagt, aber dass ich das für Rechnungen auf Clustern benötige bestärkt mich nur darin, dass ich mich damit erstmal nicht beschäftigen muss, wenn ich das ganze auf meinem Heim PC erreichen möchte.
Falls meine obigen Überlegungen für meinen Heim PC quatsch sind, dann können wir den Thread auch einfach ganz schnell schließen.
Gruß,
Klaus.
-
Nun, meine Antwort ist jetzt ein wenig gewagt, aber dass ich das für Rechnungen auf Clustern benötige bestärkt mich nur darin, dass ich mich damit erstmal nicht beschäftigen muss, wenn ich das ganze auf meinem Heim PC erreichen möchte.
Du hast wohl den Satz davor ignoriert. Es sollte zum Ausdruck bringen, dass du zu wenig Ahnung von der Materie hast. Da dir Kommandozeilenparameter unbekannt sind, solltest du dich erstmal weiter mit Grundlagen beschaeftigen.
-
Hi,
knivil schrieb:
Nun, meine Antwort ist jetzt ein wenig gewagt, aber dass ich das für Rechnungen auf Clustern benötige bestärkt mich nur darin, dass ich mich damit erstmal nicht beschäftigen muss, wenn ich das ganze auf meinem Heim PC erreichen möchte.
Du hast wohl den Satz davor ignoriert. Es sollte zum Ausdruck bringen, dass du zu wenig Ahnung von der Materie hast.
Also werde ich mal nach Kommandozeilenparameter (und damit shell scripting?) und Multithreading suchen und mich damit beschäftigen.
Vielen Dank!
knivil schrieb:
Komme wieder, wenn du konkrete Fragen hast!
Mach ich!
Gruß,
Klaus.
-
Klaus82 schrieb:
Also werde ich mal nach Kommandozeilenparameter (und damit shell scripting?) und Multithreading suchen und mich damit beschäftigen.
Nein, du brauchst keine Shellscripe um Kommandozeilenparameter zu verwenden. Die kannst du in jedem primitiven C++-Programm benutzen. Genauso wie unter C und wohl jeder anderen Programmiersprache da draußen auch.
-
knivil schrieb:
Also um es mal ganz konkret zu formulieren: Sagen wir mein Programm soll für eine Mittelwertbildung 1000 mal eine for-Schleife durchlaufen. Das würde schneller gehen, wenn die for-Schleife nur 250 Mal durchlaufen wird, aber ich das Programm vier Mal starte?
Ja.
Ich glaube dem OP ist nicht klar, dass die Ergebnisse eine parallelisierten Berechnung am Ende synchron zusammengeführt werden müssen.
-
int main(int argc, char** argv)
argc: Anzahl der Kommandozeilenparameter
argv: Array mit Kommandozeilenparameter als nullterminierte Char-ArraysBeispiel: ./halloWelt 89 test
argc: 3
argv[0] = "halloWelt"
argv[1] = "89"
argv[2] = "test"
-
Hi,
dafuqDidIread schrieb:
knivil schrieb:
Also um es mal ganz konkret zu formulieren: Sagen wir mein Programm soll für eine Mittelwertbildung 1000 mal eine for-Schleife durchlaufen. Das würde schneller gehen, wenn die for-Schleife nur 250 Mal durchlaufen wird, aber ich das Programm vier Mal starte?
Ja.
Ich glaube dem OP ist nicht klar, dass die Ergebnisse eine parallelisierten Berechnung am Ende synchron zusammengeführt werden müssen.
Wie sich gezeigt hat, habe ich nahezu Null Ahnung, aber ich behaupte, dass ich zumindest so viel verstanden habe, dass meine Rechnungen im Zuge der Monte Carlo Methode voneinander unabhängig sind.
D.h. ob ich eine Rechnung mit einer for-Schleife von 1000 Durchläufen habe, oder vier Rechnungen mit je 250 Durchläufen pro Schleife, macht für mich keine Unterschied.
Im zweiten Fall muss ich nachträglich manuell noch die Ergebnisse mitteln, klar - aber ich mache ja nichts 'falsch'.
Die Rechnungen müssen ja keine Informationen untereinander austauschen.
Kann sein, dass ich deinen Einwand nicht verstanden habe, weil ich zu wenig Ahnung habe, aber was genau sollte den synchron zusammengeführt werden müssen?
Gruß,
Klaus.
-
aber ich mache ja nichts 'falsch'
Wenn du den Zufallsgenerator mit dem gleichen Seed initialisierst, bringt es dir rein gar nichts. Zeige doch mal die 3 Codezeilen fuer die Initialisierung des Zufallsgenerators!
-
knivil schrieb:
aber ich mache ja nichts 'falsch'
Wenn du den Zufallsgenerator mit dem gleichen Seed initialisierst, bringt es dir rein gar nichts. Zeige doch mal die 3 Codezeilen fuer die Initialisierung des Zufallsgenerators!
Äh ja,
das hatte ich doch weiter oben auch geschrieben als Problematik. Aus dem Grund der Hinweis, dass ich mittels Kommandozeilenparameter einen Seed an den rng übergeben kann, d.h. ich starte das Programm vier mal, aber mit einem anderen seed.
Gruß,
Klaus.
-
Jetzt macht es dem Klaus doch nicht so schwer
Du kannst, wie auch schon erwähnt, ein Programm mit Parametern starten.
Sagen wir dein Parameter ist jetzt dein Seed, dann kannst du im Programm selbst wieder 4 neue Seeds ( rand(), srand() oder andere / bessere ) erstellen.Du kannst aber natürlich auch direkt 4 Seeds übergeben!
"./mainWater 1 2 3 4"
Das parallele rechnen kannst du mit fork() oder mit threads erledigen.
und mit dem synchronen zusammenführen dürfte sowas wie "darauf achten dass wirklich alles fertig ist, parallele zugriffe auf gleiche Variablen" usw gemeint sein.
-
knivil schrieb:
MPI ist fuer Cluster mit non-shared-memory. Ein 4, 6 oder 48-Kern-Prozessor ist keine shared-memory-Architektur.
Man kann MPI auch auf einem Rechner laufen lassen und meiner Erfahrung nach ist das sogar effektiver als pThreads, wenn viel Kommunikation nötig wird.
Viele pthread-Funktionen scheinen auch nicht allzu performant zu sein (barrier zB).
-
Hallo ihr Lieben,
ich möchte ja nach wie vor auf mehreren Kernen meines PCs arbeiten.
Ich habe angefangen ein ganz einfaches Programm zu schreiben, dass als Eingabe in
int main()
die Zahl bekommt, wie oft es Hello World ausgeben soll.#include <stdio.h> #include <stdlib.h> #include <iostream> int main(int argc, char** argv) { int n = atoi(argv[1]); for(int i = 0; i < n; ++i) { std::cout << "Hello World" << std::endl; } return 0; }
Jetzt habe ich wiederum ein shell Skript geschrieben, dass das Programm drei Mal aufruft:
#!/bin/bash for i in 'seq 1 3' do ./mb $1 done
Also hier jetzt die naive Frage: Wenn mein shell Skript nun das Programm drei Mal startet - tut es dann jeweils auf einem neuen Kern? Oder muss ich diesen 'Wunsch' nochmal als eigenen Befehl mitgeben?
Gruß,
Klaus.
-
So wie du es derzeit startest werden die Programme nacheinander ausgeführt.
Wenn du es parallel startest, entscheidet der Scheduler wo die Programme ausgeführt werden und du wirst feststellen, dass er das in der Regel sehr gut verteilt (er achtet sogar auf den Unterschied zwischen echten und virtuellen Kernen). Bei einem "Hello World", wird er aber gar nicht dazu kommen, das richtig aufzuteilen, weil viel zu kurze Laufzeit.
edit: Und bitte lern erst einmal C oder C++. Wie kann man in einem Hello-World noch so viele Fehler haben, aber gleichzeitig über parallele Programmierung nachdenken?
-
Guten Morgen,
SeppJ schrieb:
edit: Und bitte lern erst einmal C oder C++. Wie kann man in einem Hello-World noch so viele Fehler haben, [..]
Was genau meinst du? Das einzige wobei ich mir unsicher bin ist dieses atoi, es funktioniert zunächst - doch selbst auf zugehörigen C++ Reference Eintrag stehen ja ein paar Bedenken dazu. Akzeptiert.
Aber was sind denn hier noch so viele Fehler?
Gruß,
Klaus.
-
Kommt drauf an. Ich bin mir momentan nicht einmal sicher, ob das C oder C++ sein soll. Dies ist auch ein großer Kritikpunkt. Jedenfalls scheinst du das Beispiel aus der Referenz zu atoi blind übernommen zu haben, ohne genau zu verstehen, warum welche Zeile wofür da ist. Wie schon gesagt, macht selbst dein Bashscript nicht das was du möchtest.
Aber um mal Klartext zu sprechen: Wie viel Erfahrung* in C++ hast du? Tage? Ein paar Wochen? Das ist zu wenig um auch nur anzufangen, über Parallelisierung nachzudenken. Du brauchst dich nicht irgendwie vor mir zu rechtfertigen. Ich erkenne deine Kenntnisse und gebe meinen Rat. Den kannst du annehmen oder ignorieren. Ich bin bloß irgendein Typ im Internet. Vielleicht sitze ich gerade neben dir im Büro, vielleicht am anderen Ende der Welt. Wir werden es nie erfahren.
*: du hast offensichtlich im März schon programmiert, aber wie viele Tage hast du seitdem tatsächlich mit programmieren verbracht?
-
SeppJ schrieb:
Aber um mal Klartext zu sprechen: Wie viel Erfahrung* in C++ hast du? Tage? Ein paar Wochen?
Das ist jetzt für mich wieder eine schwierige Frage, da ich den Eindruck habe, dass das Niveau was Programmieren angeht hier allgemein sehr hoch ist [1] .
Also ich hatte in der Schule nie Informatik und hatte es auch während meines Studiums nicht als Nebenfach o.ä.
Irgendwann nahm ich dann einen HiWi Job an, um ein Gerät mit Labview anzusteuern was dazu geführt hatte, dass mein Einstieg in Programmieren über Labview war, wenn das hier was zählt.Ansonsten bin ich jetzt seit ca. 2 Jahren kontinuierlich damit beschäftigt zu programmieren. wobei das eben in zwei Richtungen läuft. Zum Einen in die Richtung, dass das Programm tut was ich will und zum Anderen in die Richtung noch genauer verstehen zu wollen warum es das tut, immerhin habe ich das alles nie von Grund auf gelernt.
Wobei ich glaube das letzte viertel Jahr mit am Meisten gelernt zu haben.
Gruß,
Klaus.[1] Was ich ja an sich begrüße.
-
SeppJ schrieb:
Aber um mal Klartext zu sprechen: Wie viel Erfahrung* in C++ hast du? Tage? Ein paar Wochen?
Ach das war eine rhetorische Frage. Tut mir leid, hatte ich nicht direkt gemerkt ...
Tja, dann werde ich mich wohl einen anderen Weg suchen müssen.
Gruß,
Klaus.
-
Ich hab nicht den ganzen Thread gelesen, aber man kann beim Programmierne nie auslernen. Fakt ist, aber dass man gewisse Sachen einfach im Schlaf können und auch verstehen muss.
Gerade bei C und C++ ist es so, dass auch Code kompiliert der einfach falsch ist. Das ist nicht nur frustrierend, sondern auch gefährlich, weil das Programm dann komische Dinge macht.
Und bei der Parallelisierung betritt man praktisch die Hölle des ganzen Elends. Spätestens hier muss man wissen, was man da tut. Sonst hat man einfach keine Chance. Grundlagen sind da absolut notwendig. Auch zum Thema Parallelisierung gibt es dann wieder neue Grundlagen über Synchronisationen, usw.
Das klingt am Anfang alles so simpel und toll, aber das Problem steckt im Detail.
-
hfghfghfghfg schrieb:
Und bei der Parallelisierung betritt man praktisch die Hölle des ganzen Elends. Spätestens hier muss man wissen, was man da tut. Sonst hat man einfach keine Chance. Grundlagen sind da absolut notwendig. Auch zum Thema Parallelisierung gibt es dann wieder neue Grundlagen über Synchronisationen, usw.
Vielleicht reden wir da wieder aneinander vorbei. Soweit ich das mit meinen bescheidenen Kenntnissen überblicke will ich nicht parallelisieren im Sinne von MPI.
Ich arbeite mit der MC Methode, d.h. ich benötige (sagen wir) 1000 Durchläufe meines Programms, um anschließend einen sinnvollen Mittelwert zu bilden. Und jetzt will ich einfach sagen können:
Anstatt 1000 Durchläufe auf einem Kern durchzuführen, kann ich doch auch 250 Durchläufe auf vier Kernen laufen lassen und anschließend mitteln.Dabei müssen die Kerne ja keine Informationen austauschen.
Soweit ich das verstanden habe kann ich bei Linux also auch vier mal eine Konsole öffnen und darin das Programm starten und dann mittels des Befehls
top
sehen, dass alle vier Kerne ausgelastet sind.Gruß,
Klaus.
-
Dann mach dein C-Programm komplett Singlethreaded und simpel und sammel die Daten erst nachher aus einem Shellscript heraus zusammen.
Oder war das sogar deine ursprüngliche Frage und wir haben sie falsch verstanden?