2014-02-12 6 views
7

Ich versuche, eine QR-Dekomposition (LAPACKE_dgeqrf) in R auf einem Linux-Rechner (CentOS) mit einem C++ - Programm, das mit Rcpp Schnittstelle ist. Leider sehe ich nur 100% mit top. Dies geschieht auch auf einem Red Hat Enterprise Linux Server. Das C++ - Programm (mit LAPACKE_dgeqrf) wird jedoch bei nthreads * 100% ausgeführt, wenn es vom Terminal gestartet wird (unabhängig von R). Ich kompilierte OpenBLAS mitOpenBLAS-Routine von R/Rcpp verwendet läuft nur auf einem einzigen Kern in Linux

NO_AFFINITY=1 

und versuchte

export OPENBLAS_NUM_THREADS=4 
export GOTO_NUM_THREADS=4 
export OMP_NUM_THREADS=4 
export OPENBLAS_MAIN_FREE=1 

Nichts funktioniert. Auf einem Mac funktioniert alles einwandfrei. 'mcaffinity()' aus dem parallelen R-Paket gibt NULL zurück. Ich baute R

configure 'CFLAGS=-g -O3 -Wall -pedantic' 'CXXFLAGS=-g -O3 -Wall -pedantic' 'FCFLAGS=-g -O3' 'F77FLAGS=-g -O3' '--with-system-zlib' '--enable-memory-profiling' 

Meine C++ Code:

#include <Rcpp.h> 
#include <lapacke.h> 
#include <cblas.h> 

//[[Rcpp::export]] 
Rcpp::NumericMatrix QRopenblas(Rcpp::NumericMatrix X) 
{ 
    // Declare variables 
    int n_rows = X.nrow(), n_cols = X.ncol(), min_mn = std::min(n_rows, n_cols); 
    Rcpp::NumericVector tau(min_mn); 

    // Perform QR decomposition 
    LAPACKE_dgeqrf(CblasColMajor, n_rows, n_cols, X.begin(), n_rows, tau.begin()); 

    return X; 
} 

Mein R Code:

PKG_LIBS <- '/pathto/openblas/lib/libopenblas.a' 
PKG_CPPFLAGS <- '-I/pathto/openblas/include' 
Sys.setenv(PKG_LIBS = PKG_LIBS , PKG_CPPFLAGS = PKG_CPPFLAGS) 
Rcpp::sourceCpp('/pathto/QRopenblas.cpp', rebuild = TRUE) 

n_row <- 4000 
n_col <- 4000 
A <- matrix(rnorm(n_row * n_col), n_row, n_col) 
res <- QRopenblas(A) 
+0

Hm. Ich würde es vereinfachen: Versuchen Sie ein kleines C++ Standaolon, sehen Sie, ob das funktioniert. Rcpp legt die Anzahl der Kerne nicht fest bzw. setzt sie zurück, und Sie scheinen das richtige env zu verwenden. Vars. –

+0

Ich habe versucht, ein eigenständiges C-Programm und es hat funktioniert :-) Ich sehe mehr als 100% mit Top. Es muss ein Problem mit R sein. Hatten Sie nicht ein ähnliches Problem wie hier beschrieben: http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2012-June/003903.html – chris

+0

Ja. Da war etwas - hier ist irgendwo ein Post von Claudia Beleites. Suchen Sie nach OpenBLAS und parallel. Und ich denke, jemand (Simon?) Schrieb ein Paket oder eine Funktion, um dies zu setzen. –

Antwort

2

ich eine Lösung durch den Wiederaufbau R gefunden und es Konfiguration mit

../configure --enable-BLAS-shlib --enable-R-shlib --enable-memory-profiling --with-tcltk=no 

Danach musste ichersetzenmit der entsprechenden OpenBLAS-Datei libopenblas.so. Btw, ich baue OpenBLAS mit Standardeinstellungen (d. H. Mit Affinität). Die R-Funktion qr() verwendet jetzt auch alle Cores und die C++ - Programme. Der Grund dafür ist, dass R beim Start mit mehreren Threads gestartet wird (wie mit cat /proc/pid/status verifiziert). Ohne libRblas.so zu ersetzen, wird R mit einem Thread gestartet und dann werden beim Aufruf von OpenBLAS mehrere Threads gestartet, die korrekt an den ersten Kern angeheftet sind.

+0

Nun, natürlich, ja. Das Debian-Paket (nach dem ich schon seit zehn Jahren suche) * verwendet immer Shared-Library-Builds, so dass Sie Atlas/OpenBLAS, MKL, AMDs Variante, ... ein- und auslagern können. Wenn Sie eine eingebaute LAPACK/BLAS-Konfiguration hätten, könnten Sie * offensichtlich * nicht mit mehreren Kernen arbeiten. Das hat nichts mit Rcpp zu tun, aber es geht nur um Ihre R-Konfiguration, also sollen wir das Rcpp-Tag entfernen? –

+0

Ich habe das Rcpp-Tag aus Ihrem Post entfernt. –

+0

Ok, danke. Ich bin froh, dass ich es herausgefunden habe. – chris

Verwandte Themen