Skip to content

[Rcpp-devel] OpenMP and Rcpp - compiler error

7 messages · Michael Braun, Dirk Eddelbuettel, Davor Cubranic

#
Dirk:

I've been able to upgrade my compiler to g++ 4.6 on the Mac, and I also checked this on a Red Hat Linux system with g++ 4.4.  In both cases, the OpenMP code does compile and run, so I agree that it must have been a compiler issue.  However, 4.6 appears to be an experimental version, with some odd quirks (like not recognizing the -arch option).  I was able to find only a binary for 4.6, and compiling 4.5 takes a very, very long time.  So I'm wondering if you could suggest a source for a binary of a stable version of gcc for the Mac, or possibly suggest a way that Rcpp could run under the compiler that ships with Snow Leopard.

I'll start another thread for the second issue, about the compiler not being able to compile one of the Rcpp-sugar examples, since it is still unsolved and unrelated.

Thanks again.

Michael
On Mar 24, 2011, at 6:15 PM, Dirk Eddelbuettel wrote:

            
-------------------------------------------
Michael Braun
Homer A. Burnell (1928) Career Development Professor, 
	and Assistant Professor of Management Science (Marketing Group)
MIT Sloan School of Management
100 Main St.., E62-535
Cambridge, MA 02139
braunm at mit.edu
617-253-3436



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20110406/a589d08c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1844 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20110406/a589d08c/attachment-0001.bin>
#
Hi Michael,
On 6 April 2011 at 22:49, Michael Braun wrote:
| Dirk:
| 
| I've been able to upgrade my compiler to g++ 4.6 on the Mac, and I also checked
| this on a Red Hat Linux system with g++ 4.4.  In both cases, the OpenMP code
| does compile and run, so I agree that it must have been a compiler issue.
|  However, 4.6 appears to be an experimental version, with some odd quirks (like
| not recognizing the -arch option).  I was able to find only a binary for 4.6,
| and compiling 4.5 takes a very, very long time.  So I'm wondering if you could
| suggest a source for a binary of a stable version of gcc for the Mac, or
| possibly suggest a way that Rcpp could run under the compiler that ships with
| Snow Leopard.

Sorry, I would like to help but as I am not an OS X user (or even in a
position to access an OS X machine) I have to refer you to Romain or maybe
Simon and r-sig-mac.  

You choose your development platform, so you need to sort out how you to get
your ducks in a row. It all works trivially well on Linux so maybe you can
consider VirtualBox or Parallels for your Mac, or else access another machine
on campus.

For what it is worth, g++ 4.6.1 works perfectly fine on (Debian) Linux (which
is why CRAN already uses it for tests on the incoming/ directory) but g++ 4.4
is still the default on Ubuntu 10.10.  It will be a while til 4.6 becomes the
default.

| I'll start another thread for the second issue, about the compiler not being
| able to compile one of the Rcpp-sugar examples, since it is still unsolved and
| unrelated.

Absolutely. 

If there are issues, we want to know them.  Small replicable examples are best.

Cheers, Dirk

 
| Thanks again.
| 
| Michael
| 
| 
|
| On Mar 24, 2011, at 6:15 PM, Dirk Eddelbuettel wrote:
| 
| 
| 
|
| On 24 March 2011 at 17:50, Michael Braun wrote:
|     | Dirk:
|     |
|     | This does work when I use the Intel compiler, so perhaps you are right.
|      I am, however, using the standard Apple-provided version, which is 4.2.1.
|     |
|     | I suspect there is a related issue in how OpenMP handles private Rcpp
|     objects in a parallel section.  For example, if I declare
|     |
|     | NumericVector X;
|     |
|     | #pragma omp parallel (private X)
|     | {
|     | #pragma omp for
|     | for (i=0; i<n; i++) {
|     | // some code that uses X
|     |
|     | }
|     | }
|     |
|     | then I would have thought that the compiler would create an instance of X
 |     for each thread.  Instead, I am getting memory segfaults even with the
|     Intel compiler, and I wonder if these two issues are related (i.e., perhaps
|     the compielr doesn't know what to do with code like this, and hence the
|     error).
| 
|     There should never be a segfault.  Even is copies are made (which would be
|     shallow, deep copies require clone) I fail to see how that would great out
|     of
|     bounds access.  Maybe there are other issue with the Intel compiler and
|     Rcpp so
|     maybe you could try a full 'R CMD check Rcpp_0.9.2.tar.gz' for it?
| 
|     | Could I be on track, or way off base?
| 
|     I don't not know but fear the latter.  Anyway, as I had already compiled
|     your
|     example earlier (as shown in the quoted text below):
| 
|     edd at max:/tmp$ cat michael.cpp
| 
|     #include <Rcpp.h>
| 
|     RcppExport SEXP omptest (SEXP X) {
| 
|      BEGIN_RCPP
| 
|     Rcpp::NumericVector Y = X;
|     int n = Y.size();
|     Rcpp::NumericVector Z(n);
|     int i;
|     double a;
| 
|     #pragma omp parallel
|     {
|     #pragma omp for
|     for (i=0; i<n; i++) {
|       a = sqrt(Y(i));
|       Z(i) = a;
|     }
|     }
|     return Z;
| 
|     END_RCPP
| 
|     }
|     edd at max:/tmp$ R --quiet
|     R> dyn.load("michael.so")
|     R> .Call("omptest", 1:10)
|     [1] 1.00000 1.41421 2.64575 2.00000 2.64575 2.44949 2.64575 2.82843 3.00000
|     3.16228
|     R> q()
|     Save workspace image? [y/n/c]: n
|     edd at max:/tmp$
| 
|     So still no issue here....
| 
|     Dirk
| 
|     |
|     | Thanks,
|     |
|     | Michael
|     |
|     |
|     |
|     |
| | On Mar 24, 2011, at 1:03 PM, Dirk Eddelbuettel wrote:
|     |
|     | >
|     | > Michael,
|     | >
|     | > As a quick off-the-cuff remark, I suspect it is your compiler. I have
|     done
|     | > quite a few builds with OpenMP when experimenting with a parallel
|     version of
|     | > RcppDE (the differential evolution optimisation I "ported" from C to
|     | > C++/Rcpp).  I had no issues building this (but issues getting
|     replicable
|     | > streams going which is still unsolved though I have some tests
|     working).
|     | >
|     | > The incomplete RcppParDE fragment is actually in Rcpp's SVN and there I
|     | > simply do
|     | >
|     | > ## Hey Emacs make this a -*- mode: makefile; -*- file
|     | > ##
|     | > ## -- compiling for OpenMP
|     | > PKG_CXXFLAGS=-fopenmp
|     | > ##
|     | > ## -- linking for OpenMP
|     | > #PKG_LIBS= -fopenmp -lgomp $(shell $(R_HOME)/bin/Rscript -e
|     "Rcpp:::LdFlags()") $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
|     | > ##
|     | > ## -- linking for OpenMP and Google Perftools profiling
|     | > PKG_LIBS= -fopenmp -lgomp $(shell $(R_HOME)/bin/Rscript -e
|     "Rcpp:::LdFlags()") $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) -lprofiler
|     | >
|     | > and that is all it takes to deploy OpenMP with R and Rcpp on my Linux
|     box:
|     | >
|     | > edd at max:~/svn/rcpp/pkg/RcppParDE$ R CMD INSTALL .
|     | > * installing to library ?/usr/local/lib/R/site-library?
|     | > * installing *source* package ?RcppParDE? ...
|     | > ** libs
|     | > ccache g++ -I/usr/share/R/include   -I"/usr/local/lib/R/site-library/
|     Rcpp/include" -I"/usr/local/lib/R/site-library/RcppArmadillo/include"
|      -fopenmp -fpic  -g -O3 -Wall -pipe -pedantic -Wno-variadic-macros  -c
|     deoptim.cpp -o deoptim.o
|     | > ccache g++ -I/usr/share/R/include   -I"/usr/local/lib/R/site-library/
|     Rcpp/include" -I"/usr/local/lib/R/site-library/RcppArmadillo/include"
|      -fopenmp -fpic  -g -O3 -Wall -pipe -pedantic -Wno-variadic-macros  -c
|     devol.cpp -o devol.o
|     | > ccache g++ -I/usr/share/R/include   -I"/usr/local/lib/R/site-library/
|     Rcpp/include" -I"/usr/local/lib/R/site-library/RcppArmadillo/include"
|      -fopenmp -fpic  -g -O3 -Wall -pipe -pedantic -Wno-variadic-macros  -c
|     permute.cpp -o permute.o
|     | > g++ -shared -o RcppParDE.so deoptim.o devol.o permute.o -fopenmp -lgomp
|     -L/usr/local/lib/R/site-library/Rcpp/lib -lRcpp -Wl,-rpath,/usr/local/lib/R
|     /site-library/Rcpp/lib -llapack -lblas -lgfortran -lm -lprofiler -L/usr/
|     lib64/R/lib -lR
|     | > installing to /usr/local/lib/R/site-library/RcppParDE/libs
|     | > ** R
|     | > ** preparing package for lazy loading
|     | > ** help
|     | > *** installing help indices
|     | > ** building package indices ...
|     | > ** testing if installed package can be loaded
|     | >
|     | > * DONE (RcppParDE)
|     | > edd at max:~/svn/rcpp/pkg/RcppParDE$
|     | >
|     | > Now this packages has run-time issue, and my recent test code is
|     somewhere so
|     | > take the package for a working package -- but it does prove that OpenMP
|     can
|     | > easily be thrown in the mix on suitable systems.
|     | >
|     | > And what "suitable systems" are is an open question. We know Rtools for
|     | > Windows does not include the libgomp library needed.  Maybe OS X is not
|     | > suitable either in that version?
|     | >
|     | > Your file certainly builds here:
|     | >
|     | > edd at max:/tmp$ cat michael.cpp
|     | >
|     | > #include <Rcpp.h>
|     | >
|     | > RcppExport SEXP omptest (SEXP X) {
|     | >
|     | >  BEGIN_RCPP
|     | >
|     | > Rcpp::NumericVector Y = X;
|     | > int n = Y.size();
|     | > Rcpp::NumericVector Z(n);
|     | > int i;
|     | > double a;
|     | >
|     | > #pragma omp parallel
|     | > {
|     | > #pragma omp for
|     | > for (i=0; i<n; i++) {
|     | >   a = sqrt(Y(i));
|     | >   Z(i) = a;
|     | > }
|     | > }
|     | > return Z;
|     | >
|     | > END_RCPP
|     | >
|     | > }
|     | > edd at max:/tmp$ PKG_LIBS="-fopenmp -lgomp -L/usr/local/lib/R/site-library
|     /Rcpp/lib -lRcpp -Wl,-rpath,/usr/local/lib/R/site-library/Rcpp/lib -llapack
|     -lblas -lgfortran -lm -L/usr/lib64/R/lib -lR" PKG_CXXFLAGS="-I/usr/share/R/
|     include   -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/usr/local/lib/
|     R/site-library/RcppArmadillo/include"  -fopenmp -fpic  -g -O3 -Wall -pipe
|     -pedantic" R CMD SHLIB michael.cpp
|     | > ccache g++ -I/usr/share/R/include     -I/usr/share/R/include   -I/usr/
|     local/lib/R/site-library/Rcpp/include -I/usr/local/lib/R/site-library/
|     RcppArmadillo/include  -fopenmp -fpic  -g -O3 -Wall -pipe -pedantic -fpic
|      -g -O3 -Wall -pipe -pedantic -Wno-variadic-macros  -c michael.cpp -o
|     michael.o
|     | > g++ -shared -o michael.so michael.o -fopenmp -lgomp -L/usr/local/lib/R/
|     site-library/Rcpp/lib -lRcpp -Wl,-rpath,/usr/local/lib/R/site-library/Rcpp/
|     lib -llapack -lblas -lgfortran -lm -L/usr/lib64/R/lib -lR -L/usr/lib64/R/
|     lib -lR
|     | > edd at max:/tmp$
|     | >
|     | > I am using g++ 4.4 (and sometimes 4.5), current R 2.12.2, current Rcpp
|     0.9.2.
|     | >
|     | > Regards, Dirk
|     | >
|     | >
|     | >
|     | >
|     | > --
|     | > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
|     |
|     | -------------------------------------------
|     | Michael Braun
|     | Homer A. Burnell (1928) Career Development Professor,
|     | and Assistant Professor of Management Science (Marketing Group)
|     | MIT Sloan School of Management
|     | 100 Main St.., E62-535
|     | Cambridge, MA 02139
|     | braunm at mit.edu
|     | 617-253-3436
|     |
|     |
| 
|     --
|     Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
| 
| 
| -------------------------------------------
| Michael Braun
| Homer A. Burnell (1928) Career Development Professor, 
| and Assistant Professor of Management Science (Marketing Group)
| MIT Sloan School of Management
| 100 Main St.., E62-535
| Cambridge, MA 02139
| braunm at mit.edu
| 617-253-3436
| 
| 
| 
| xapplication/pkcs7-signatu [Click mouse-2 to save to a file]
#
On April 6, 2011 08:17:47 pm Dirk Eddelbuettel wrote:
I believe g++ will be bumped up to 4.5 on Ubuntu 11.04.

Davor
#
On April 6, 2011 07:49:32 pm Michael Braun wrote:
MacPorts has a wide range of versions of GCC: 4.4, 4.5, and 4.6 are all there. 
See http://www.macports.org/ports.php?by=name&substr=gcc

Davor
#
I've tried the MacPorts route, and it takes forever.  Perhaps this is a MacPorts problem, but I've found that it consumes all available system resources as it compiles all possible dependencies before even getting to the compilation of gcc.
On Apr 7, 2011, at 12:34 AM, Davor Cubranic wrote:

            
-------------------------------------------
Michael Braun
Homer A. Burnell (1928) Career Development Professor, 
	and Assistant Professor of Management Science (Marketing Group)
MIT Sloan School of Management
100 Main St.., E62-535
Cambridge, MA 02139
braunm at mit.edu
617-253-3436



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20110407/35caa0de/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1844 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20110407/35caa0de/attachment.bin>
#
On 6 April 2011 at 21:30, Davor Cubranic wrote:
| On April 6, 2011 08:17:47 pm Dirk Eddelbuettel wrote:
| > For what it is worth, g++ 4.6.1 works perfectly fine on (Debian) Linux
| > (which is why CRAN already uses it for tests on the incoming/ directory)
| > but g++ 4.4 is still the default on Ubuntu 10.10.  It will be a while til
| > 4.6 becomes the default.
| 
| I believe g++ will be bumped up to 4.5 on Ubuntu 11.04.

Sure. We have been using it as the default in Debian unstable for a while
too.  

But I was talking about _4.6_ and I doubt that will be the default in 11.10
so maybe 12.04 or later. 

Dirk
#
On 2011-04-06, at 9:45 PM, Michael Braun wrote:

            
Gcc ports hardly have that many dependencies[1], but you're right: some ports do take a very long time to compile. Whenever I'm upgrading the firefox port, I may as well leave my computer for an hour or so, because it really ties up the CPU while it's compiling.

On the other hand, I hardly ever see my gcc44 port change, so it's pretty much a one-time penalty. Just start the install before you head home for the day and it will be done by the time you get back the next morning. (Remember to turn off powersave sleep, though.)

Davor

[1]: gcc46 dependencies:

$ port rdeps gcc46
The following ports are dependencies of gcc46 @4.6-20110325_0:
  gmp
  mpfr
    xz
      libiconv
        gperf
      gettext
        ncurses
          ncursesw
        expat
  libmpc