Hello, My question is: Can I use the 64-bit gcc to build a 32-bit package with the -m32 command line option with Rtools? And, can that work for CRAN? Or more generally, is there a work-around for needing lots of RAM during compilation with the 32-bit compiler? The background is: I'm trying to compile a the development version of RxODE (https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting 32-bit memory limits (using >3GB and possibly >4GB RAM during compilation) using the 32-bit version of gcc. Specifically, "C:/rtools40/mingw32/bin/"gcc [etc., see the link above for the full command line] yields the error cc1.exe: out of memory allocating 65536 bytes There is no problem building with mingw64, and I played around to confirm that by using: Sys.setenv(BINPREF="c:/rtools40/mingw64/bin/") And compilation completed successfully (though installation failed as expected because the compiled .dll couldn't load on 32-bit R). Thanks, Bill
[R-pkg-devel] Compiling 32-bit on Windows using 64-bit gcc and -m32
4 messages · biii m@iii@g oii de@@ey@ws, Tomas Kalibera, Dirk Eddelbuettel
1 day later
On 9/7/20 7:07 PM, bill at denney.ws wrote:
Hello, My question is: Can I use the 64-bit gcc to build a 32-bit package with the -m32 command line option with Rtools? And, can that work for CRAN? Or more generally, is there a work-around for needing lots of RAM during compilation with the 32-bit compiler? The background is: I'm trying to compile a the development version of RxODE (https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting 32-bit memory limits (using >3GB and possibly >4GB RAM during compilation) using the 32-bit version of gcc. Specifically,
I think this is too much memory to be used for compilation. I think it would be best to simplify the code, possibly split it, or just reduce the optimization level, as I read you have done already anyway. Maybe it doesn't have to be -O0, maybe you can enable some. In the past I've seen similar cases when inlining too aggressively in large files, maybe you could just reduce that a bit. It may very well be that reducing the optimization level just a little bit will provide about the same performance, but require far less memory at compile time (in the past there have been cases when -O3 did not produce faster code than -O2 on a set of standard benchmarks, of course that may be different in today's compilers). Spending much more time for optimizing of the 32-bit builds may not be worth the effort (and neither on the R/CRAN side). Best Tomas
"C:/rtools40/mingw32/bin/"gcc [etc., see the link above for the full command line] yields the error cc1.exe: out of memory allocating 65536 bytes There is no problem building with mingw64, and I played around to confirm that by using: Sys.setenv(BINPREF="c:/rtools40/mingw64/bin/") And compilation completed successfully (though installation failed as expected because the compiled .dll couldn't load on 32-bit R). Thanks, Bill [[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 9 September 2020 at 10:33, Tomas Kalibera wrote:
| Spending much more time for optimizing of the 32-bit builds may not be | worth the effort (and neither on the R/CRAN side). As we are in conditional mode: maybe that could be recognized by adding an explicit flag allowing us to disable 32-bit builds on a case by case basis? And it would be nice to be able to do this for that other OS none of us have access too (outside of a win-builder instance that differs subtly in setup from the CRAN one). Dirk
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
From: Tomas Kalibera <tomas.kalibera at gmail.com>
Can I use the 64-bit gcc to build a 32-bit package with the -m32 command line option with Rtools? And, can that work for CRAN? Or more generally, is there a work-around for needing lots of RAM during compilation with the 32-bit compiler? The background is: I'm trying to compile a the development version of RxODE (https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting 32-bit memory limits (using >3GB and possibly >4GB RAM during compilation) using the 32-bit version of gcc.
I think this is too much memory to be used for compilation. I think it would be best to simplify the code, possibly split it, or just reduce the optimization level, as I read you have > done already anyway. Maybe it doesn't have to be -O0, maybe you can enable some. In the past I've seen similar cases when inlining too aggressively in large files, maybe you could just reduce that a bit. It may very well be that reducing the optimization level just a little bit will provide about the same performance, but require far less memory at compile time (in the past there have been cases when -O3 did not produce faster code than -O2 on a set of standard benchmarks, of course that may be different in today's compilers).
Yes, we are testing reducing the optimization level. Using -O0 works to compile using ~500 MB. The code can't be simplified as it is a very long algebraic equation. The function is often used in the middle of an optimization routine that can often takes minutes to hours (statistical minimization here, not meaning compiler optimization), so optimization is preferable. But, it's a fair point that I don't know the value of the different -O optimization levels for what is only long algebra. Thanks, Bill