« Webinar April 28: Effective Graphs with Microsoft R Open | Main | A segmented model of CRAN package growth »

April 26, 2016


Feed You can follow this conversation by subscribing to the comment feed for this post.

The only difference between official R and MRO is Intel's MKL? Then one can simply stay with the official R implementation and use any of the optimized BLAS/LAPACK alternatives (Atlas, OpenBLAS, etc.). You can even use Intel's MKL with base R: https://software.intel.com/en-us/articles/using-intel-mkl-with-r

You should add in your table, next to "base R" (with the reference BLAS implementation), an extra columns with "base R + ATLAS", "base R + OpenBLAS" or "base R + MKL".

That may be the reason why the official product descriptions tend to be "high level without many details". Seriously, guys, can't you explain more in depth the product you're distributing?

I'm an amateur with R. However, like almost all on the planet, I have long experience with Microsoft. That company is not innovative and has displayed no inclination to change. I think that Sergi has an extremely good point. My first response is to worry that users will start to glom onto MS products and the reservoir of innovative talent I associate with R and the CRAN will shrink. I'd like to also know from all you older wiser R'ers, is an open source alternative to MRS available?

Thanks all.

Hi Sergi, there's lots more detail on MRO available, at its homepage of mran.microsoft.com. A good place to start is the About Microsoft R Open page.

Anyone of course is welcome to build R with MKL or any other multithreaded BLAS. If you've tried to do it though, you'll know it can be a very tricky process. One of the goals of MRO is to provide the community with an easy-to-install binary distribution of multi-threaded R.

Hi Larry, I have to respectfully disagree with your statement that Microsoft "is not innovative and has displayed no inclination to change". I've been with Microsoft for a year now, and I've been very pleasantly surprised by the innovation Microsoft has been doing with R. (See my R at Microsoft talk for some examples.) As for change, speaking with the old-timers its very clear that Microsoft is a very different company than it used to be. The support for open source projects and practices is one very clear example.

Hi David, from the comfort of my debian distribution, where switching between BLAS implementations is just a simple call to update-alternatives, I see your point and apreciate Microsoft provides a working R binary distribution linked to the MKL.

Still, the comparison table under "Why should I use MRO or MRS instead of R?" is not fair and could be misleading.

From About Microsoft R Open, after clearing all verbosity, I can only read MRO is just the R implementation from the r-project plus a third party optimized BLAS and the checkpoint package. Is it what you call innovation? Wait, the R+D guys in Oracle had the very same idea!

Anyways, wouldn't be fair from my side if I didn't point out that other products from Microsoft may still be great.

A science scientist's perspective on MRO:

I do science with non-generic data, ranging from water quality and toxicology with below-detection-limits to very large rasters and vector spatial data. Thus, I use a large number of domain-specific packages, including a handful not on CRAN or r-forge or Bioconductor, and some computations that require cpu-weeks, or, more accurately, core-weeks.
I've run MRO 3.2.2 alongside R 3.2.3 for several months on both win7 and win10. [I haven't loaded MRO on linux because I see no need for it there, and I'm not about to try to get packages using cuda GPU cores working under MRO. I have productive work to do.]

I was skeptical, but I like MRO, and will continue to run it alongside CRAN R. No, MRO doesn't do anything I can't do by other means, but the simple binary installer with a BLAS that uses multiple cores for some computations is convenient, especially for recommending to colleagues running R on Windows who aren't going to build R from binaries. My preferred configurations for largish (spatial) datasets are PostgreSQL + R, or SQLite + R, but the first is prohibited on my work machine and the latter required an individual exemption from IT. IT in government & corporate settings are _much_ more likely to approve MRO than the alternatives.

Contra the above assertion, there are several packages that don't work with MRO. The big use-case where I work is RODBC: we're stuck with 32-bit MS office on 64-bit win7, and most colleagues can't install 64-bit ODBC drivers for Access. Yes that's a dumb constraint (and my life would be better without Access), but that's life as a government scientist.

I view MRS as a plausible replacement & upgrade for MS SQL Server Reporting Services. Our lead database contractor asserted that SSRS could do everything we need with our data. I politely gave him WQ data needing seasonal Mann-Kendall tests, bird point counts with imperfect detection needing hierarchical models of detection & occupancy, and adaptive cluster sampling data needing bootstrapping, and a couple of complex figures from ggplot2. He conceded my point, and opened remote ODBC access to the repository databases. But now, if they license MRS, the required analyses (to say nothing of solid graphs) can be done server-side when it makes sense and client-side in R when the bandwidth is there to ship the data.

So I completely agree with Sergi that MRO isn't particularly "innovative", and add R inside PostgreSQL to Oracle, SAP/HANA and other prior equivalents to MRS. But MRO is useful. I don't see MRO ever pulling developers away from CRAN R to write MRO-specific packages (except for the Revolutions folks who have MRS-specific tools as their business model). As long as MS supports the (corporate) R consortium, I see MRO/MRS & Microsoft's acquisition of RevolutionAnalytics as a (minor) positive.

My next test will be the lag between R 3.3 on CRAN (tomorrow) and an update to MRO from 3.2.2. I'm fine with not tracking the 3rd digit versions, but I will be happy if Microsoft's resources let the Revolution folks keep MRO much closer to the current R versions than they could before the MS acquisition.

update: I see MRO is now 3.2.4, so that's a good sign in terms of keeping relatively current and in sync with CRAN R versions, which is important when I have to install new non-CRAN packages only available for the latest version...

The comments to this entry are closed.

Search Revolutions Blog

Got comments or suggestions for the blog editor?
Email David Smith.
Follow revodavid on Twitter Follow David on Twitter: @revodavid
Get this blog via email with Blogtrottr