[Bug 211393] math/R: update patches and options

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211393

Joseph Mingrone <jrm at ftfl.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #173018|0                           |1
        is obsolete|                            |
 Attachment #173086|                            |maintainer-approval+
              Flags|                            |

--- Comment #6 from Joseph Mingrone <jrm at ftfl.ca> ---
Created attachment 173086
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173086&action=edit
second svn diff to improve math/R

Thanks for testing.  The last diff had LTO_USE=GCC, but it should have been
LTO_USE= gcc=yes.

Other new changes:

- Return the option for the shared R library [1].  This performance hit
described in the reference is one reason why the math/libR port should stick
around, i.e., for the few ports that require an embedded R.
- Create an option for memory profiling (like upstream, off by default).
- Create an option for R profiling (like upstream, on by default).
- --enable-BLAS-shlib when R's internal BLAS is chosen.

P.S., Rainer, I've seen some old blog posts that show ATLAS can be faster.  Do
you have any specific tests I can reproduce to gauge the current speedups using
ATLAS versus R's internal BLAS?

----------------------------------------
[1] From the R Installation and Administration Manual:

"Flag --enable-R-shlib causes the make process to build R as a dynamic (shared)
library, typically called libR.so, and link the main R executable R.bin against
that library. This can only be done if all the code (including system
libraries) can be compiled into a dynamic library, and there may be a
performance47 penalty*. So you probably only want this if you will be using an
application which embeds R."

"* We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux."

-- 
You are receiving this mail because:
You are the assignee for the bug.