So optimieren Sie die R-Leistung

Question

Wir haben einen aktuellen Leistungs-Benchmark, den ich zu verstehen versuche.Wir haben ein umfangreiches Skript, das besagt, dass die Leistung auf einem Redhat-Linux-Rechner um 50 % langsamer zu sein scheint als auf einem Windows 7-Laptop, dessen Spezifikationen vergleichbar sind.Der Linux-Rechner wird mit KVM virtualisiert und verfügt über 4 zugewiesene Kerne sowie 16 GB Arbeitsspeicher.Das Skript ist nicht io-intensiv, verfügt aber über einige for-Schleifen.Hauptsächlich frage ich mich, ob es R-Kompilierungsoptionen gibt, die ich zur Optimierung verwenden kann, oder Kernel-Compiler-Optionen, die dazu beitragen könnten, dies vergleichbarer zu machen.Für Hinweise wäre ich dankbar.Ich werde versuchen, mir eine andere Maschine zu besorgen und sie auch zum besseren Vergleich mit Rohmetall zu testen.

Dies sind die Konfigurationsflags, die ich zum Kompilieren von R auf dem Linux-Computer verwende.Ich habe ziemlich viel experimentiert und dies scheint die Ausführungszeit im grünen Bereich bei größeren Datensätzen um 12 Sekunden zu verkürzen.Im Wesentlichen konnte ich mit diesen Optionen die Zeit von 2,087 auf 1,48 Sekunden steigern.

./configure CFLAGS="-O3 -g -std=gnu99" CXXFLAGS="-O3 -g" FFLAGS="-O2 -g" LDFLAGS="-Bdirect,--hash-stype=both,-Wl,-O1" --enable-R-shlib --without-x --with-cairo --with-libpng --with-jpeglib

Update 1

Das Skript wurde noch nicht optimiert.Eine andere Gruppe arbeitet derzeit an dem Skript und wir haben Anfragen zur Verwendung der Apply-Funktion gestellt, sind uns aber nicht sicher, wie dies die zeitliche Ungleichheit erklärt.

Die Oberseite des Profils sieht so aus.Die meisten dieser Funktionen werden später mithilfe der Apply-Funktionen optimiert, aber derzeit werden auf beiden Maschinen Vergleiche durchgeführt.

"eval.with.vis"                    8.66    100.00      0.12     1.39
"source"                           8.66    100.00      0.00     0.00
"["                                5.38     62.12      0.16     1.85
"GenerateQCC"                      5.30     61.20      0.00     0.00
"[.data.frame"                     5.20     60.05      2.40    27.71
"ZoneCalculation"                  5.12     59.12      0.02     0.23
"cbind"                            3.22     37.18      0.34     3.93
"[["                               2.26     26.10      0.38     4.39
"[[.data.frame"                    1.88     21.71      0.82     9.47

Mein erster Verdacht und ich werde es in Kürze testen und mit meinen Erkenntnissen aktualisieren, ist, dass die KVM-Linux-Virtualisierung schuld ist.Dieses Skript ist sehr speicherintensiv und aufgrund der großen Anzahl von Array-Operationen und der Übergabe von R per Kopie (was natürlich an malloc erfolgen muss) kann dies die Ursache des Problems sein.Da die VM keinen direkten Zugriff auf den Speichercontroller hat und diesen mit ihren anderen VMs teilen muss, könnte dies höchstwahrscheinlich die Ursache des Problems sein.Ich werde später heute eine Rohmaschine bekommen und sie mit meinen Erkenntnissen aktualisieren.

Vielen Dank an alle für die schnellen Updates.

Update 2

Wir gingen ursprünglich davon aus, dass die Ursache des Leistungsproblems durch Hyper-Threading mit einer VM verursacht wurde, aber das stellte sich als falsch heraus und die Leistung war auf einer Bare-Metal-Maschine im Vergleich gleich.

Später stellten wir fest, dass der Windows-Laptop eine 32-Bit-Version von R für Berechnungen verwendet.Dies veranlasste uns, die 64-Bit-Version von R auszuprobieren und das Ergebnis war ~140 % langsamer als die 32-Bit-Version mit genau demselben Skript.Dies führt mich zu der Frage, wie es möglich ist, dass die 64-Bit-Version etwa 140 % langsamer ist als die 32-Bit-Version von R?

Was wir sehen ist, dass die 32

Windows 32 -Bit -Ausführungszeit 48 Sekunden Windows 64 -Bit -Ausführungszeit 2,33 Sekunden.

Linux 64-Bit-Ausführungszeit 2,15 Sekunden.Linux 32-Bit-Ausführungszeit <in Bearbeitung> (Erstellte eine 32-Bit-Version auf RHEL 6.3 x86_64, konnte jedoch keine Leistungsverbesserung feststellen. Ich werde mit der 32-Bit-Version von RHEL 6.3 neu laden.)

Ich habe diesen Link gefunden, aber er erklärt nur einen 15-20-prozentigen Treffer auf einigen 64-Bit-Rechnern.

http://www.hep.by/gnu/r-patched/r-admin/R-admin_51.html

Leider kann ich das Drehbuch nicht legal veröffentlichen.

Answer 1

Das Problem wurde gelöst und es wurde durch eine nicht optimierte Blas-Bibliothek verursacht.

Dieser Artikel war eine große Hilfe.Die Verwendung von Atlas war eine große Hilfe.

http://www.cybaea.net/Blogs / Daten / Faster-R-Through-Bigh-BLAS.html

Answer 2

Schauen Sie sich die Abschnitte bei "Profiling" auf der Erweiterungen Handbuch.

Von 30.000 Fuß können Sie nicht viel sagen - Sie benötigen Profilinformationen."Allgemeiner Konsens" (und ich setze dies in Zitaten, wie Sie diese Dinge nicht wirklich generalisieren können) ist, dass Linux dazu neigt, auf Speichermanagement und Dateizugriff besser zu machen, sodass ich von Ihren Ergebnissen ein bisschen erstaunt bin.

.

Answer 3

Gebäude R mit --enable-R-shlib kann zu einer Leistungseinbuße führen.Dies wird in besprochen R-Installation und -Administration, In Anhang B, Abschnitt 1.Das allein könnte 10–20 % der Variation erklären.Andere Quellen könnten die Unterschiede der „vergleichbaren Spezifikationen“ sein.