Dear R-dev,
I would like to accelerate my R computation by using parallel OpenMP compilers
(e.g from Pathscale) on a 2-processor AMD server and I would like to know
whether R is a tread safe library. The main kernel of the OpenMP
parallelization is a C SEXP function that performs the computational routine in
parallel with:
*******************
SEXP example(SEXP list, SEXP expr, SEXP rho)
{
R_len_t i, n = length(list);
SEXP ans, alocal;
omp_lock_t lck;
PROTECT(ans = allocVector(VECSXP, n));
ans = allocVector(VECSXP, n);
omp_init_lock(&lck);
#pragma omp parallel for default(none) private(i, alocal) shared(list,
lck,rho, ans, n, expr)
for(i = 0; i < n; i++) {
omp_set_lock(&lck);
PROTECT(alocal = allocVector(VECSXP, 1));
alocal = allocVector(VECSXP, 1);
defineVar(install("x"), VECTOR_ELT(list, i), rho);
omp_unset_lock(&lck);
/* do computational kernel in parallel */
alocal = eval(expr, rho);
omp_set_lock(&lck);
SET_VECTOR_ELT(ans, i, alocal);
UNPROTECT(1);
omp_unset_lock(&lck);
}
setAttrib(ans, R_NamesSymbol, getAttrib(list, R_NamesSymbol));
UNPROTECT(1);
return(ans);
}
***********
The code works fine using one thread and breaks currently down with 2 threads.
I am using a recent R distribution and the complete R code is compile with
"-openmp" and the Pathscale compiler suite.
Thanks in advance,
Olaf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 R is not yet thread safe. We are working on it, and I hope to make some progress before the end of the year. (This one even!) D. Olaf.Schenk at unibas.ch wrote:> Dear R-dev, > > I would like to accelerate my R computation by using parallel OpenMP compilers > (e.g from Pathscale) on a 2-processor AMD server and I would like to know > whether R is a tread safe library. The main kernel of the OpenMP > parallelization is a C SEXP function that performs the computational routine in > parallel with: > > ******************* > SEXP example(SEXP list, SEXP expr, SEXP rho) > { > R_len_t i, n = length(list); > SEXP ans, alocal; > > omp_lock_t lck; > PROTECT(ans = allocVector(VECSXP, n)); > ans = allocVector(VECSXP, n); > omp_init_lock(&lck); > #pragma omp parallel for default(none) private(i, alocal) shared(list, > lck,rho, ans, n, expr) > for(i = 0; i < n; i++) { > > omp_set_lock(&lck); > PROTECT(alocal = allocVector(VECSXP, 1)); > alocal = allocVector(VECSXP, 1); > defineVar(install("x"), VECTOR_ELT(list, i), rho); > omp_unset_lock(&lck); > > /* do computational kernel in parallel */ > alocal = eval(expr, rho); > > omp_set_lock(&lck); > SET_VECTOR_ELT(ans, i, alocal); > UNPROTECT(1); > omp_unset_lock(&lck); > > } > setAttrib(ans, R_NamesSymbol, getAttrib(list, R_NamesSymbol)); > UNPROTECT(1); > return(ans); > } > > *********** > > The code works fine using one thread and breaks currently down with 2 threads. > I am using a recent R distribution and the complete R code is compile with > "-openmp" and the Pathscale compiler suite. > > Thanks in advance, > Olaf > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel- -- Duncan Temple Lang duncan at wald.ucdavis.edu Department of Statistics work: (530) 752-4782 371 Kerr Hall fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDb8ia9p/Jzwa2QP4RAjHoAJ9/VVL5DIRwE4tYjwM+0oQPKjmQ4QCeNzFa lX6CVF5yVQZPNSE3bZPr7q4=hsjc -----END PGP SIGNATURE-----
On Mon, Nov 07, 2005 at 07:57:28PM +0100, Olaf.Schenk at unibas.ch wrote:> I would like to accelerate my R computation by using parallel OpenMP > compilers (e.g from Pathscale) on a 2-processor AMD server and I > would like to know whether R is a tread safe library. The mainR is not thread safe, but others will have to tell you just how and why not and what needs to be done to fix that (I don't know). Does OpenMP require thread support, or can it alternately use multiple processes plus System V shared memory? Perhaps the latter would still be an option even in R's currently non-thread-safe state. Your approach is interesting. Why do you want to do shared memory parallel programming with OpenMP, rather than say message passing via MPI or PVM? Do you have a particularly fine-grained problem for which message passing would be unsuitable? Or are you just hoping to automatically take advantage of both CPUs of your dual CPU workstation without having to write any extra message passing code? I haven't heard of anyone else doing shared memory programming with R. But if instead you are interested in message passing, there are lots of different tools and projects in R for that: http://cran.us.r-project.org/src/contrib/Descriptions/Rmpi.html http://cran.us.r-project.org/src/contrib/Descriptions/rpvm.html http://cran.us.r-project.org/src/contrib/Descriptions/papply.html http://cran.us.r-project.org/src/contrib/Descriptions/snow.html http://www.aspect-sdm.org/Parallel-R/ http://cran.us.r-project.org/src/contrib/Descriptions/RScaLAPACK.html http://cran.us.r-project.org/src/contrib/Descriptions/taskPR.html http://cran.us.r-project.org/src/contrib/Descriptions/biopara.html http://www.omegahat.org/download/R/packages/CORBA.tar.gz -- Andrew Piskorski <atp at piskorski.com> http://www.piskorski.com/
Duncan Temple Lang wrote (Mon Nov 7 22:35:22 CET 2005):>R is not yet thread safe. >We are working on it, and I hope to make some progress before >the end of the year. (This one even!) > > D.How is this going along? For some things it would be simpler to use threads compared to processes, to avoid the added complexity of passing the results back to a master process. With the emerging multicore processors it is essential that users can easily make use of them. A simple example of use: data1 <- data2 <- matrix(0, r, c) dataFiller <- function(i) { tmp <- someCalculation(i) data1[, i] <<- tmp$result1 data2[, i] <<- tmp$result2 } runParallelInThreads(1:c, dataFiller) If this can be done almost as fast and simple with processes, for instance using the multicore package, then I think it needs to be better documented. -- Regards Rune Schjellerup Philosof