R system () verwendet immer dieselbe CPU, nicht Multi-Threaded / Multi-Core

8

In R 3.0.2 unter Linux 3.12.0 verwende ich die Funktion system (), um eine Reihe von Aufgaben auszuführen. Der gewünschte Effekt besteht darin, dass jede dieser Aufgaben so ausgeführt wird, als würde ich sie in der Befehlszeile über Rscript außerhalb von R system () ausführen.

Wenn sie jedoch innerhalb von R über system () ausgeführt werden, ist jede Task vom Master-R-Prozess an dieselbe CPU gebunden.

Mit anderen Worten:

Wenn sie über RScript direkt von einer Bash-Shell außerhalb von R gestartet werden, läuft jede Aufgabe so weit wie möglich auf ihrem eigenen Kern (dies ist erwünscht)

Beim Start in R über system () läuft jede Aufgabe auf demselben einzelnen Kern. Es gibt keine Multicore-Freigabe. Wenn ich 100 Aufgaben habe, sind sie alle auf einem Kern fest.

Ich kann nicht herausfinden, wie ich einen Prozess innerhalb von R erzeugen kann, so dass jeder Prozess seinen eigenen Kern verwendet.

Ich verwende einen einfachen Test, um CPU-Zyklen zu verbrauchen, damit ich den Effekt mit top / htop messen kann:

%Vor%

Wenn dieser einfache Test mehrere Male außerhalb von R gestartet wird, erhält jede Iteration ihren eigenen Kern. Aber wenn ich es innerhalb von R starte:

%Vor%

Sie stecken alle auf einem einzigen Kern.

Hier ist eine Visualisierung nach dem Ausführen von 4 simultanen / simultanen Iterationen von system ()

Bitte helfen Sie mir, ich muss in der Lage sein, R zu sagen, neue Aufgaben zu starten, wobei jeder in seinem eigenen Kern läuft.

UPDATE DEC 4 2013:

Ich habe einen Test in Python ausprobiert:

%Vor%

Ich habe den neuen Thread mehrmals wiederholt, und wie erwartet funktionierte alles (mehrere Kerne, eine pro Thread).

Ich denke also, installiere das rPython-Paket in R, und versuche dasselbe in R:

%Vor%

Leider war es auch nach wiederholten Anrufen wieder auf einen einzigen Kern beschränkt. Warum ist alles, was gestartet wird, auf einen einzelnen Kern beschränkt, wenn es von R ausgeführt wird?

    
ctrlbrk 02.12.2013, 09:07
quelle

2 Antworten

6

Nach dem Kommentar von @ agstudy sollten Sie parallel zuerst verwenden. Auf meinem System verwendet dies mehrere Kerne:

%Vor%

Ich hätte das selbst in einem Kommentar geschrieben, aber es ist zu lang. Ich weiß, dass Sie gesagt haben, dass Sie das Paket parallel ausprobiert haben, aber ich wollte bestätigen, dass Sie es richtig verwenden. Wenn es nicht funktioniert, können Sie bestätigen, dass ein systemfremder Aufruf mclapply korrekt verwendet, wie dieser?

%Vor%

Wenn Sie Ihre Kommentare lesen, vermute ich, dass Ihr pthreads Linux-Paket veraltet und defekt ist. Auf meinem System verwende ich libpthread-2.15.so (nicht 2.13). Wenn du auf Ubuntu bist, kannst du dir das neueste mit apt-get install libpthread-stubs0 holen.

Beachten Sie auch, dass Sie parallel , nicht multicore verwenden sollten. Wenn Sie in den Dokumenten nach parallel suchen, dann Beachten Sie, dass sie die Arbeit in multicore integriert haben.

Wenn ich Ihre nächsten Kommentare lese, muss ich darauf bestehen, dass es parallel und nicht multicore ist, das seit 2.14 in R eingeschlossen wurde. Sie können darüber in der CRAN-Task-Ansicht nachlesen.

Es ist entscheidend, dass parallel funktioniert. Ich habe dir vorher gesagt, dass du es direkt von der Quelle kompilieren könntest, aber das ist nicht korrekt. Ich denke, die einzige Möglichkeit, es neu zu kompilieren, wäre, R aus der Quelle zu kompilieren.

Können Sie auch überprüfen, ob Ihre CPU-Affinität richtig eingestellt ist? Können Sie auch überprüfen, ob R die Anzahl der Kerne erkennen kann? Einfach ausführen:

%Vor%     
nograpes 04.12.2013, 17:54
quelle
2

Ich habe das Laufen getestet:

%Vor%

auf Linux 2.6.32 mit R 3.0.2 und auf Linux 3.8.0 mit R 2.15.2. In beiden Fällen benötigt es (wie zu erwarten) 4 CPU-Kerne.

- Bearbeiten -

Ich habe Linux 3.12 auf einem Virtual-Box-Rechner installiert, und auch hier tut R 3.0.2 genau das, was ich erwarte: Nimmt 4 CPUs auf. Es wandert sogar langsam zwischen den CPUs - so bleibt jeder Prozess nicht bei der gleichen CPU, sondern ändert sich jede Sekunde oder so.

Dies führt dazu, dass ich Ihr System als einige lokale Modifikationen ansehe, die R zwingen, nur eine CPU zu verwenden.

Aus Ihrer Beschreibung würde ich erraten, dass die lokalen Änderungen in R und nicht systemweit sind (da Ihr Python keine Probleme hat, mehr Prozesse hervorzubringen).

Die Änderungen können nur von Ihrem Benutzer vorgenommen werden, erstellen Sie also einen neuen Benutzer und versuchen Sie es. Wenn es für den neuen Benutzer funktioniert, müssen wir herausfinden, was Ihre Benutzer-ID installiert hat.

Wenn es für den neuen Benutzer nicht funktioniert, könnten R-Bibliotheken, die das Problem verursachen, global installiert werden. Installieren Sie eine ältere R-Version und probieren Sie es aus. Wenn die ältere Version funktioniert, ist Ihre R 3.0.2-Installation wahrscheinlich defekt. Entfernen Sie es und installieren Sie es erneut.

    
Ole Tange 05.12.2013 02:33
quelle