C++: Mit mehreren Threads programmieren?

GR-Thunderstorm

BIOS-Overclocker(in)
Ich hoffe, dass die Frage jetzt nicht zu komplex ist, aber wie kann ich in meinen Code schreiben, welcher CPU-Kern welche Berechnung übernehmen soll?
Beispiel: Wie könnte ich alle 4 Kerne jeweils für sich die Fakultät von 200 berechnen lassen?
Bisher kann ich mit VC++ leider nur einen CPU-Kern alles machen lassen. :(
 
Zuletzt bearbeitet:
Neben den nativen Methoden (Winapi in der MSDN nachgucken, falls du für Windows entwickelst). Ansonsten kann ich dir openMP empfehlen.
 
Afaik kann OpenCL auch ganz profanes Multithreading auf der CPU (also nicht nur über GPU). Das wäre vielleicht auch eine Option für dich. (Ich denke, OpenCL ist etwas schwieriger. Die Beispiele für openMP sehen ja sehr einfach aus, dafür ist es halt nicht ganz so mächtig.)
 
VC++/VB/C# kann das auch recht einfach über sog. "Background Worker"
Damit kannst du schonmal mehrere Threads erstellen.

Und irgenwo im Internet meine ich schonmal gelesehn zu haben, wie man diese anderen Cores zuweist...
 
Ich kann mit dem Projekt erst demnächst anfangen und habe die Quellen noch nicht angeschaut.
Ist es denn damit möglich, dass man am Ende so in der Art wie in meinem Beispiel schreiben kann?

Pseudocode:

Code:
int main()
{


longint fakul(int wert)
{
   if (wert <= 1) return 1;
   else return wert*fakul(wert-1);
}

int C= System::get_number_of_CPU_Cores;
longint x[C-1];

for (int i=0; i<C; i++)
{
   System::CPU::Core[i]->do {x[i]=fakul(200*i)};
}

return 0;
}
Oder gehört da mehr dazu?
 
Zuletzt bearbeitet:
Ich bin jetzt in openmp net so drinnen, aber ich meine, der verteilte die Aufgabe auf alle vorhandenen Komponenten (ich meine sogar, der würde sogar Clustering unterstützen :ugly:). Da war was mit diesen Präprozessoranweisungen... such am besten mal nach nem openMP Tutorial.
 
Das trifft jetzt wahrscheinlich unter das bisherige Niveau in diesem Thread, aber ich sags einfach mal :)
Ich habe vor ca. einem halben Jahr mit dem Qt-Framework angefangen und habe schon ein paar Multithread-Anwendungen geschrieben. Ging recht einfach, obwohl ich nicht wirklich viel über Threadsynchronisierung und solche "Späße" wusste. *klick*
Ob du die einzelnen Threads auch auf jedem CPU-Kern gleichzeitig ausführen kannst, hört sich für mich ein bisschen unwahrscheinlich ein. Immerhin braucht das OS, das ja die Rechenzeit zuteilt auch ein bisschen Zeit für eigene Prozesse.
Falls ich etwas falsches gesagt habe, ich lasse mich gerne eines Besseren belehren :)

PS@Bauer87:
Dich trifft man in diesem Unterforum ja recht oft =)
Hast du eine Empfehlung für jemanden der gerne die in C++ so oft angepriesene Systemnähe kennenlernen möchte?(bspws CPU-Zeit auslesen)
PM mich bitte, damit wir den Fluss des Threads nicht unterbrechen :daumen:
 
PS@Bauer87:
Dich trifft man in diesem Unterforum ja recht oft =)
Hast du eine Empfehlung für jemanden der gerne die in C++ so oft angepriesene Systemnähe kennenlernen möchte?(bspws CPU-Zeit auslesen)
PM mich bitte, damit wir den Fluss des Threads nicht unterbrechen :daumen:
Da gibt es passende Funktionen in der WinAPI zu. Hier mal nen Artikel auf Wikipedia zum Time Stamp Counter.

@Topic: Qt kann man prinzipiell natürlich auch nutzen!
Ich meine mich dunkel zu erinnern, dass man unter Linux die CPUs festlegen kann (also welcher Thread zu welcher CPU). Ich habe es aber selbst noch nie versucht, wie das unter Win aussieht, kann ich dir atm auch nicht sagen. Bei meiner bisherigen Threadprogrammierung war sowas noch nie nötig :D
 
Ehrlich gesagt ist sowas auch eigentlich nicht wirklich sinnvoll - der Kernel wird wohl besser/effizienter das ganze verteilen als du das jemals im voraus könntest.

Ansonsten sieht openMP relativ nett aus, kannte ich noch gar nicht. Habe das bis jetzt bei immer "richtig" nativ via posix-threads gemacht.
 
Auf welcher CPU was läuft, interessiert mich eigentlich überhaupt nicht. Ich traue meinem OS da genügend zu, selber vernünftig zu entscheiden, welcher Thread wo laufen soll — schließlich gibt es ja noch andere Programme als meines, die gleichzeitig laufen. Wenn es Funktionen gibt, die das für mich überwachen, nutze ich die gerne — sind optimierter als alles, was ich schreiben würde. XD

PS und @ n0stradamus: Bin kein Fan von Insellösungen und lock-in. Außerdem würde ich WinAP nicht als systemnah bezeichnen…
 
Okay, hab ich ja auch nie behauptet. Ich wollte eigentlich nur sagen, den TSC mit RDTSC direkt auszulesen macht in den meisten Fällen auf heutigen Systemen eher nen Haufen Probleme (muss zum Beispiel unter den Cores nicht synchron sein, heißt: TSC(Kern1) != TSC(Kern2)). Systemnah läuft bei mir eh meistens auf Assembler hinaus, auch wenn ich mir der Existenz der SIMD-Instrincts bewusst bin :ugly:
 
Zurück