Re: [Rd] default min-v/nsize parameters

[Martin Maechler]

> Peter Haverty 
> on Mon, 19 Jan 2015 08:50:08 -0800 writes:

> Hi All, This is a very important issue. It would be very
> sad to leave most users unaware of a free speedup of this
> size.  These options don't appear in the R --help
> output. They really should be added there.

Indeed, I've found that myself and had added them there about
24 hours ago. 
((I think they were accidentally dropped a while ago))

> if the garbage collector is working very hard, might it
> emit a note about better setting for these variables?

> It's not really my place to comment on design philosophy,
> but if there is a configure option for small memory
> machines I would assume that would be sufficient for the
> folks that are not on fairly current hardware.

There's quite a few more issues with this,
notably how the growth *steps* are done.
That has been somewhat experimental and for that reason is
_currently_ quite configurable via R_GC_* environment variables,
see the code in src/main/memory.c

This is currently discussed "privately" within the R core.
I'm somewhat confident that R 3.2.0 in April will have changes.

And -- coming back to the beginning -- at least the "R-devel" version now shows 

R --help | grep -e min-.size

  --min-nsize=N Set min number of fixed size obj's ("cons cells") to N
  --min-vsize=N Set vector heap minimum to N bytes; '4M' = 4 MegaB

--
Martin Maechler, ETH Zurich

> On Sat, Jan 17, 2015 at 11:40 PM, Nathan Kurz  wrote:

>> On Thu, Jan 15, 2015 at 3:55 PM, Michael Lawrence
>>  wrote:
>> > Just wanted to start a discussion on whether R could ship with more
>> > appropriate GC parameters.
>> 
>> I've been doing a number of similar measurements, and have come to the
>> same conclusion.  R is currently very conservative about memory usage,
>> and this leads to unnecessarily poor performance on certain problems.
>> Changing the defaults to sizes that are more appropriate for modern
>> machines can often produce a 2x speedup.
>> 
>> On Sat, Jan 17, 2015 at 8:39 AM,   wrote:
>> > Martin Morgan discussed this a year or so ago and as I recall bumped
>> > up these values to the current defaults. I don't recall details about
>> > why we didn't go higher -- maybe Martin does.
>> 
>> I just checked, and it doesn't seem that any of the relevant values
>> have been increased in the last ten years.  Do you have a link to the
>> discussion you recall so we can see why the changes weren't made?
>> 
>> > I suspect the main concern would be with small memory machines in
>> student labs
>> > and less developed countries.
>> 
>> While a reasonable concern, I'm doubtful there are many machines for
>> which the current numbers are optimal.  The current minimum size
>> increases for node and vector heaps are 40KB and 80KB respectively.
>> This grows as the heap grows (min + .05 * heap), but still means that
>> we do many more expensive garbage collections at while growing than we
>> need to.  Paradoxically, the SMALL_MEMORY compile option (which is
>> suggestd for computers with up to 32MB of RAM) has slightly larger at
>> 50KB and 100KB.
>> 
>> I think we'd get significant benefit for most users by being less
>> conservative about memory consumption.The exact sizes should be
>> discussed, but with RAM costing about $10/GB it doesn't seem
>> unreasonable to assume most machines running R have multiple GB
>> installed, and those that don't will quite likely be running an OS
>> that needs a custom compiled binary anyway.
>> 
>> I could be way off, but my suggestion might be a 10MB start with 1MB
>> minimum increments for SMALL_MEMORY, 100MB start with 10MB increments
>> for NORMAL_MEMORY, and 1GB start with 100MB increments for
>> LARGE_MEMORY might be a reasonable spread.
>> 
>> Or one could go even larger, noting that on most systems,
>> overcommitted memory is not a problem until it is used.  Until we
>> write to it, it doesn't actually use physical RAM, just virtual
>> address space.  Or we could stay small, but make it possible to
>> programmatically increase the granularity from within R.
>> 
>> For ease of reference, here are the relevant sections of code:
>> 
>> https://github.com/wch/r-source/blob/master/src/include/Defn.h#L217
>> (ripley last authored on Jan 26, 2000 / pd last authored on May 8, 1999)
>> 217  #ifndef R_NSIZE
>> 218  #define R_NSIZE 35L
>> 219  #endif
>> 220  #ifndef R_VSIZE
>> 221  #define R_VSIZE 6291456L
>> 222  #endif
>> 
>> https://github.com/wch/r-source/blob/master/src/main/startup.c#L169
>> (ripley last authored on Jun 9, 2004)
>> 157 Rp->vsize = R_VSIZE;
>> 158 Rp->nsize = R_NSIZE;
>> 166  #define Max_Nsize 5000 /* about 1.4Gb 32-bit, 2.8Gb

Re: [Rd] [PATCH] Makefile: add support for git svn clones

[Martin Maechler]

> Dirk Eddelbuettel 
> on Mon, 19 Jan 2015 16:35:31 -0600 writes:

> On 19 January 2015 at 17:11, Duncan Murdoch wrote:
> | The people who would have to maintain the patch can't test it.  

I agree that this is good reason to not add delicate code to the
R sources, indeed,  however, read on ..

> I don't understand this.

> The patch, as we may want to recall, was all of

> +GIT := $(shell if [ -d "$(top_builddir)/.git" ]; then \
> + echo "git"; fi)
> +

> and

> -   (cd $(srcdir); LC_ALL=C TZ=GMT svn info || $(ECHO) "Revision: -99") 
2> /dev/null \
> +   (cd $(srcdir); LC_ALL=C TZ=GMT $(GIT) svn info || $(ECHO) "Revision: 
-99") 2> /dev/null \

the other thing needed -- apart from a similar patch to the Windows Makefile
is to make the above "portable" in the sense that it works for
standard make as opposed to just GNU make
This requirement also helps portability to (albeit rare I think) platforms.
AFAICS, this simply needs replacement of  
$(shell  )
by  `  `

> I believe you can test that builds works before applying the patch, and
> afterwards---even when you do not have git, or in this case a git 
checkout.

> The idiom of expanding a variable to "nothing" if not set is used all over
> the R sources and can be assumed common.  And if (hypothetically speaking)
> the build failed when a .git directory was present?  None of R Core's 
concern
> either as git was never supported.

> I really do not understand the excitement over this.  The patch is short,
> clean, simple, and removes an entirely unnecessary element of friction.

I agree partly - as I agree with Duncan's points -
and for this case, in spite of good reasons why such a patch can
be problematic to accept, I'm tending to think of  "sponsoring"
it, i.e., putting
it in *and* maintain it (if that maintenance is close to "nil" :-),
notably after you add the changes mentioned above.  

As, indeed, I don't see how it can harm, and you, the git users
among us (= "the people interested in tracking R development
sources") would keep some responsibility with it.

I would like to keep us in a good "community" spirit of
collaborating and focused on the advancement of Free Software in
general and of R in particular, and so help each other as much
as possible with the limited resources we have

Best,
Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Link to NEWS.2 in NEWS is broken

[Martin Maechler]

> Tal Galili 
> on Tue, 20 Jan 2015 00:30:56 +0200 writes:

> I am not sure where to post this.

Maybe you could try to contact the CRAN maintainer by e-mail.
(E-mail: you know the thing people did before they "posted" everything :-) ;-))
but I agree that it is not easy to find e-mail addresses nowadays..

More seriously:  Thank you, Tal!

> I am looking at the NEWS file here:
> http://cran.r-project.org/bin/windows/base/NEWS.R-3.1.2.html
> And the links at the bottom seem to be broken.
> This link:
> http://cran.r-project.org/bin/windows/NEWS.2

> Should be this:
> http://cran.r-project.org/doc/manuals/NEWS.2

well, there yes.

If you look at the more typical place of the NEWS,
which you get to quickly from the Main CRAN or R-project web
page, namely
  http://www.r-project.org/news.html
and its bottom link
http://cran.r-project.org/src/base/NEWS.html

then on the bottom of that pakage, there, even the ./NEWS.2.html fails.


> CHANGES in previous versions
> -
> Older news can be found in text format in files NEWS.0
> , NEWS.1
>  and NEWS.2
>  in the ‘doc’ directory.
> News in HTML format for *R* versions from 2.10.0 to 2.15.3 is in
> NEWS.2.html .

As you probably know these are all autogenerated from the
source file  /doc/NEWS.Rd

  ((and so there is some reason why posting to R-devel may be somewhat ok))

and the relevant part of that is

\section{CHANGES in previous versions}{
  \itemize{
\item Older news can be found in text format in files
\ifelse{html}{\href{../NEWS.0}{NEWS.0}, \href{../NEWS.1}{NEWS.1}
  and \href{../NEWS.2}{NEWS.2}}{\file{NEWS.0}, \file{NEWS.1} and
  \file{NEWS.2}}
in the \file{doc} directory.  News in HTML format for
\R versions from 2.10.0 to 2.15.3 is in
\ifelse{html}{\url{NEWS.2.html}}{\file{doc/html/NEWS.2.html}}.
  }
}

*and* that source produces a NEWS.html which works correctly in
the important use of R's "builtin HTML help",
i.e. for me what I get after help.start(),  I presume that's
also the toplevel help page Rstudio users see.
And there, the "../NEWS.O" (relative link) *is* the correct location.

Using relative links is a very good idea here, as all that
should work completely offline.

The task here is to adapt all the other "published" versions of the
generated NEWS.html files to point to a web (as opposed to
local/relative) URL.

Yes ``just another'' tweak for the CRAN web page generation
scripts...

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Link to NEWS.2 in NEWS is broken

[peter dalgaard]

I think Kurt has this in hand since the same issue affected src/base/NEWS.html. 
The fix seems to be just not to copy the html formatted NEWS to the file 
distribution folders and have any links in there point to 
doc/manuals/r-release/NEWS.html instead. The relative links to the parent 
directory would be a pain to sort out.

(Cc: Kurt, as he may not be aware that there is a fix to apply to 
bin/windows/base/index.html as well.)

-pd

On 20 Jan 2015, at 13:05 , Martin Maechler  wrote:

>> Tal Galili 
>>on Tue, 20 Jan 2015 00:30:56 +0200 writes:
> 
>> I am not sure where to post this.
> 
> Maybe you could try to contact the CRAN maintainer by e-mail.
> (E-mail: you know the thing people did before they "posted" everything :-) 
> ;-))
> but I agree that it is not easy to find e-mail addresses nowadays..
> 
> More seriously:  Thank you, Tal!
> 
>> I am looking at the NEWS file here:
>> http://cran.r-project.org/bin/windows/base/NEWS.R-3.1.2.html
>> And the links at the bottom seem to be broken.
>> This link:
>> http://cran.r-project.org/bin/windows/NEWS.2
> 
>> Should be this:
>> http://cran.r-project.org/doc/manuals/NEWS.2
> 
> well, there yes.
> 
> If you look at the more typical place of the NEWS,
> which you get to quickly from the Main CRAN or R-project web
> page, namely
>  http://www.r-project.org/news.html
> and its bottom link
>http://cran.r-project.org/src/base/NEWS.html
> 
> then on the bottom of that pakage, there, even the ./NEWS.2.html fails.
> 
> 
>> CHANGES in previous versions
>> -
>> Older news can be found in text format in files NEWS.0
>> , NEWS.1
>>  and NEWS.2
>>  in the ‘doc’ directory.
>> News in HTML format for *R* versions from 2.10.0 to 2.15.3 is in
>> NEWS.2.html .
> 
> As you probably know these are all autogenerated from the
> source file  /doc/NEWS.Rd
> 
>  ((and so there is some reason why posting to R-devel may be somewhat ok))
> 
> and the relevant part of that is
> 
> \section{CHANGES in previous versions}{
>  \itemize{
>\item Older news can be found in text format in files
>\ifelse{html}{\href{../NEWS.0}{NEWS.0}, \href{../NEWS.1}{NEWS.1}
>  and \href{../NEWS.2}{NEWS.2}}{\file{NEWS.0}, \file{NEWS.1} and
>  \file{NEWS.2}}
>in the \file{doc} directory.  News in HTML format for
>\R versions from 2.10.0 to 2.15.3 is in
>\ifelse{html}{\url{NEWS.2.html}}{\file{doc/html/NEWS.2.html}}.
>  }
> }
> 
> *and* that source produces a NEWS.html which works correctly in
> the important use of R's "builtin HTML help",
> i.e. for me what I get after help.start(),  I presume that's
> also the toplevel help page Rstudio users see.
> And there, the "../NEWS.O" (relative link) *is* the correct location.
> 
> Using relative links is a very good idea here, as all that
> should work completely offline.
> 
> The task here is to adapt all the other "published" versions of the
> generated NEWS.html files to point to a web (as opposed to
> local/relative) URL.
> 
> Yes ``just another'' tweak for the CRAN web page generation
> scripts...
> 
> Martin
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Link to NEWS.2 in NEWS is broken

[Tal Galili]

Thanks Peter and Martin.

Cheers,
Tal



Contact
Details:---
Contact me: tal.gal...@gmail.com |
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
--


On Tue, Jan 20, 2015 at 2:49 PM, peter dalgaard  wrote:

> I think Kurt has this in hand since the same issue affected
> src/base/NEWS.html. The fix seems to be just not to copy the html formatted
> NEWS to the file distribution folders and have any links in there point to
> doc/manuals/r-release/NEWS.html instead. The relative links to the parent
> directory would be a pain to sort out.
>
> (Cc: Kurt, as he may not be aware that there is a fix to apply to
> bin/windows/base/index.html as well.)
>
> -pd
>
> On 20 Jan 2015, at 13:05 , Martin Maechler 
> wrote:
>
> >> Tal Galili 
> >>on Tue, 20 Jan 2015 00:30:56 +0200 writes:
> >
> >> I am not sure where to post this.
> >
> > Maybe you could try to contact the CRAN maintainer by e-mail.
> > (E-mail: you know the thing people did before they "posted" everything
> :-) ;-))
> > but I agree that it is not easy to find e-mail addresses nowadays..
> >
> > More seriously:  Thank you, Tal!
> >
> >> I am looking at the NEWS file here:
> >> http://cran.r-project.org/bin/windows/base/NEWS.R-3.1.2.html
> >> And the links at the bottom seem to be broken.
> >> This link:
> >> http://cran.r-project.org/bin/windows/NEWS.2
> >
> >> Should be this:
> >> http://cran.r-project.org/doc/manuals/NEWS.2
> >
> > well, there yes.
> >
> > If you look at the more typical place of the NEWS,
> > which you get to quickly from the Main CRAN or R-project web
> > page, namely
> >  http://www.r-project.org/news.html
> > and its bottom link
> >http://cran.r-project.org/src/base/NEWS.html
> >
> > then on the bottom of that pakage, there, even the ./NEWS.2.html
> fails.
> >
> >
> >> CHANGES in previous versions
> >> -
> >> Older news can be found in text format in files NEWS.0
> >> , NEWS.1
> >>  and NEWS.2
> >>  in the ‘doc’ directory.
> >> News in HTML format for *R* versions from 2.10.0 to 2.15.3 is in
> >> NEWS.2.html .
> >
> > As you probably know these are all autogenerated from the
> > source file  /doc/NEWS.Rd
> >
> >  ((and so there is some reason why posting to R-devel may be somewhat
> ok))
> >
> > and the relevant part of that is
> >
> > \section{CHANGES in previous versions}{
> >  \itemize{
> >\item Older news can be found in text format in files
> >\ifelse{html}{\href{../NEWS.0}{NEWS.0}, \href{../NEWS.1}{NEWS.1}
> >  and \href{../NEWS.2}{NEWS.2}}{\file{NEWS.0}, \file{NEWS.1} and
> >  \file{NEWS.2}}
> >in the \file{doc} directory.  News in HTML format for
> >\R versions from 2.10.0 to 2.15.3 is in
> >\ifelse{html}{\url{NEWS.2.html}}{\file{doc/html/NEWS.2.html}}.
> >  }
> > }
> >
> > *and* that source produces a NEWS.html which works correctly in
> > the important use of R's "builtin HTML help",
> > i.e. for me what I get after help.start(),  I presume that's
> > also the toplevel help page Rstudio users see.
> > And there, the "../NEWS.O" (relative link) *is* the correct location.
> >
> > Using relative links is a very good idea here, as all that
> > should work completely offline.
> >
> > The task here is to adapt all the other "published" versions of the
> > generated NEWS.html files to point to a web (as opposed to
> > local/relative) URL.
> >
> > Yes ``just another'' tweak for the CRAN web page generation
> > scripts...
> >
> > Martin
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] default min-v/nsize parameters

[Henrik Bengtsson]

Thanks for this.

Anyone know how I can find what those initial settings are from within
R?  Do I need to parse/look at both environment variables R_NSIZE and
R_VSIZE and then commandArgs()?

/Henrik

On Tue, Jan 20, 2015 at 1:42 AM, Martin Maechler
 wrote:
>> Peter Haverty 
>> on Mon, 19 Jan 2015 08:50:08 -0800 writes:
>
> > Hi All, This is a very important issue. It would be very
> > sad to leave most users unaware of a free speedup of this
> > size.  These options don't appear in the R --help
> > output. They really should be added there.
>
> Indeed, I've found that myself and had added them there about
> 24 hours ago.
> ((I think they were accidentally dropped a while ago))
>
> > if the garbage collector is working very hard, might it
> > emit a note about better setting for these variables?
>
> > It's not really my place to comment on design philosophy,
> > but if there is a configure option for small memory
> > machines I would assume that would be sufficient for the
> > folks that are not on fairly current hardware.
>
> There's quite a few more issues with this,
> notably how the growth *steps* are done.
> That has been somewhat experimental and for that reason is
> _currently_ quite configurable via R_GC_* environment variables,
> see the code in src/main/memory.c
>
> This is currently discussed "privately" within the R core.
> I'm somewhat confident that R 3.2.0 in April will have changes.
>
> And -- coming back to the beginning -- at least the "R-devel" version now 
> shows
>
> R --help | grep -e min-.size
>
>   --min-nsize=N Set min number of fixed size obj's ("cons cells") to N
>   --min-vsize=N Set vector heap minimum to N bytes; '4M' = 4 MegaB
>
> --
> Martin Maechler, ETH Zurich
>
> > On Sat, Jan 17, 2015 at 11:40 PM, Nathan Kurz  wrote:
>
> >> On Thu, Jan 15, 2015 at 3:55 PM, Michael Lawrence
> >>  wrote:
> >> > Just wanted to start a discussion on whether R could ship with more
> >> > appropriate GC parameters.
> >>
> >> I've been doing a number of similar measurements, and have come to the
> >> same conclusion.  R is currently very conservative about memory usage,
> >> and this leads to unnecessarily poor performance on certain problems.
> >> Changing the defaults to sizes that are more appropriate for modern
> >> machines can often produce a 2x speedup.
> >>
> >> On Sat, Jan 17, 2015 at 8:39 AM,   wrote:
> >> > Martin Morgan discussed this a year or so ago and as I recall bumped
> >> > up these values to the current defaults. I don't recall details about
> >> > why we didn't go higher -- maybe Martin does.
> >>
> >> I just checked, and it doesn't seem that any of the relevant values
> >> have been increased in the last ten years.  Do you have a link to the
> >> discussion you recall so we can see why the changes weren't made?
> >>
> >> > I suspect the main concern would be with small memory machines in
> >> student labs
> >> > and less developed countries.
> >>
> >> While a reasonable concern, I'm doubtful there are many machines for
> >> which the current numbers are optimal.  The current minimum size
> >> increases for node and vector heaps are 40KB and 80KB respectively.
> >> This grows as the heap grows (min + .05 * heap), but still means that
> >> we do many more expensive garbage collections at while growing than we
> >> need to.  Paradoxically, the SMALL_MEMORY compile option (which is
> >> suggestd for computers with up to 32MB of RAM) has slightly larger at
> >> 50KB and 100KB.
> >>
> >> I think we'd get significant benefit for most users by being less
> >> conservative about memory consumption.The exact sizes should be
> >> discussed, but with RAM costing about $10/GB it doesn't seem
> >> unreasonable to assume most machines running R have multiple GB
> >> installed, and those that don't will quite likely be running an OS
> >> that needs a custom compiled binary anyway.
> >>
> >> I could be way off, but my suggestion might be a 10MB start with 1MB
> >> minimum increments for SMALL_MEMORY, 100MB start with 10MB increments
> >> for NORMAL_MEMORY, and 1GB start with 100MB increments for
> >> LARGE_MEMORY might be a reasonable spread.
> >>
> >> Or one could go even larger, noting that on most systems,
> >> overcommitted memory is not a problem until it is used.  Until we
> >> write to it, it doesn't actually use physical RAM, just virtual
> >> address space.  Or we could stay small, but make it possible to
> >> programmatically increase the granularity from within R.
> >>
> >> For ease of reference, here are the relevant sections of code:
> >>
> >> https://github.com/wch/r-source/blob/master/src/include/Defn.h#L217
> >> (ripley last authored on Jan 26, 2000 / pd last authored on May 8, 
> 19

[Rd] updated R-cairo bridge, official R-3.1.*-mavericks.pkg crippled, snpMatrix 1.19.0.20

[Hin-Tak Leung]

R.framework-Versions-Resources-library-grDevices-libs-cairo_20150120.tgz in
http://sourceforge.net/projects/outmodedbonsai/files/R/
are dropped in replacement to the cairo.so's in the official R binaries 
(2.15.3, 3.0.3, 3.1.2).

updated to cairo-1.12.18 and freetype-2.5.4. The official R binaries' were
built with early freetype 2.4.x and cairo 1.11(?) and had a number of issues
with some windows and mac system fonts; also the one in the official binaries
were built with a freetype that's built differently from apple's and
and therefore can interfere with other GUI applications' use of dfonts on Mac 
OS X. (that
unfortunately means the most common typefaces like Time and Helvetica!).

While doing that, I found that the official R-3.1.*-mavericks.pkg are crippled, 
compared
to R-3.1.*-snowleopard.pkg. They have tiff functionality missing. Here are the 
sizes of
the official binaries':

3918832 
./R-3.1.2-snowleopard/R.framework/Versions/3.1/Resources/library/grDevices/libs/cairo.so
3778144 
./R-3.0.3/R.framework/Versions/3.0/Resources/library/grDevices/libs/cairo.so
3170596 
./R-3.1.2-mavericks/R.framework/Versions/3.1/Resources/library/grDevices/libs/cairo.so
3252656 
./R-2.15.3/R.framework/Versions/2.15/Resources/library/grDevices/libs/i386/cairo.so
3539992 
./R-2.15.3/R.framework/Versions/2.15/Resources/library/grDevices/libs/x86_64/cairo.so

"R-3.1.2-mavericks/R.framework/Versions/3.1/Resources/library/grDevices/libs/cairo.so"
 is so much smaller,
not because it is built with a better and newer compiler, but because tiff 
functionality is
missing.

The official R-3.1.*-mavericks.pkg is about 14MB smaller than
R-3.1.*-snowleopard.pkg (from 55MB-ish to 70MB-ish). Looking carefully, the 
size differently did
not come from better compilation - it is in 3 unrelated areas, one of the 
problematic:

- the snowleopard builds come the manuals in pdf's, mavericks don't. That's 
about 14MB.
- a few bundled gcc runtime libraries (libgcc/libfortran...) are quad arch in 
the former, and biarch in the latter.
  That's another 6 MB.
- the missing tiff functionality. That affects both R_X11.so and cairo.so, and 
add up to about 1.5MB.

And the 18-20MB difference compress down to 14MB.

I don't know whether it actually offers any speed advantage, but I'd probably 
suggest stay away from
the official mavericks builds, just because of missing functionality. It is 
missing from all of R 3.1.0, 3.1.1, and 3.1.2.

The next thing I am doing is building the replacement for the cairo.dll's in 
the offical R windows binaries.
Just watch out in the next few days in the same directory.

-- not R-devel related below this point --

I have finished with snpMatrix 1.19.0.20 5 days ago. Some of you may notice the 
documentations
are already out - 19 months about 400 commit since 1.19.0.19, it comes with a 
snpStats compatibility
mode; when that mode is on, about 1/3 of its internals are swapped to their 
snpStats-equivalent
versions. Initially synchronized to snpStats x.x.x.8 - and I already mentioned 
that it is because of another
GLM related bug, found on top of x.x.x.7. Sigh.

snpMatrix 1.19.0.20 and snpStats x.x.x.8 are now really just waiting for me to 
finish with the cairo
stuff (for R 3.1.x). The impatient can just read the new vignettes.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel