Revolutions

Benchmarking Revolution R for data mining

The blog Heuristically Andrew puts Revolution R through its paces by running some benchmarks versus open-source R for data mining applications. The benchmarks set out to answer the following question:

I recently upgraded my notebook (where I often use R for data mining) and was faced with two questions: for the fastest speed for building models, do I use the R or Revolution R, and do I enable Hyper-Threading?

The post includes benchmark code for several computations in both R and Revolution R, with and without hyperthreading enabled, and the results are summarized in the following chart:

The height of each bar is execution time, so a smaller bar is better. First thing to notice is that using hyper-threading or not doesn't make a whole lot of difference. (In each group, compare bar 1 with bar 2, and bar 3 with bar 4: not much difference.) That's in line with my experience, too: while hyper-threading can make one processor appear as two processors to the operating system, I've never seen it improve the performance of computations that would normally consume nearly 100% of the processor anyway.

As shown by these benchmarks, Revolution R offers a nice performance boost for building tree models with the ctree function. This is a function from a user-written CRAN package (party), and I'd guess that the underlying code makes extensive use of native R operations like those in our R peformance benchmarks that benefit from the parallel MKL math library linked with Revolution R. (It's also possible that underlying C or C++ code calls level-2 BLAS functions directly, which would also benefit.) If a package doesn't make much use of such matrix operators (like the earth function for MARS models), you won't much of a speedup. 

The k function -- a simple, tight arithmetic loop that doesn't do any heavy lifting with matrices -- has is of the same class. It was interesting to see the benefits of the new compile function in R 2.13: the lk function is a byte-compiled version of k, and byte-compilation offers some nice benefits. Dirk Eddelbuettel ran some similar tests soon after R 2.13.0 was released. (Byte-compilation isn't currently available in Revolution R, which will upgrade to R 2.13 after the final 2.13.x patch is released by the Core Group.)

The post concludes:

I already used Revolution R on Amazon EC2, and for now, I plan to switch to Revolution R on Windows too. I’ll leave HTT enabled in case it helps other tasks.

If you'd like to do the same, you can purchase Revolution R Enterprise online, or download it for free if you're at an academic institution. Check out the post at the Heuristically Andrew blog for the full details and code of this interesting benchmarking exercise.

Heuristically Andrew: Benchmarking R, Revolution R, And HyperThreading For Data Mining

Using R for Map-Reduce applications in Hadoop

Data Scientist Antonio Piccolboni recently published this comparison of the various language and interfaces available for programming Big Data analysis tasks in the map-reduce framework. The interfaces he reviewed included:

• Java Hadoop (mature and efficient, but verbose and difficult to program)
• Cascading (brings an SQL-like flavor to Java programming with Hadoop)
• Pipes/C++ (a C++ interface to programming on Hadoop)
• Hive (a high-level SQL-like language for Hadoop, concise and expressive but limited in flexibility)
• Pig (a new high-level langauge for Hadoop)
• Rhipe (an R package for map-reduce programming with Hadoop)
• Dumbo (a Hadoop library for python)
• Cascalog (a powerful but obtuse lisp-based interface to Hadoop)

In the conclusion of the review, Antonio zeroes in on the Rhipe's R-based interface as "closest to what he was looking for":

... For a general purpose, moderately elegant, not necessarily most efficient, not necessarily mature language for exploration purposes, Rhipe seems to fit the bill pretty nicely. First, it is just a library, which means that one can continue to use the tools he’s familiar with. I found it particularly useful to run map-reduce jobs in the interpreter, inspecting the inputs and outputs of each, an invaluable debugging help — but no, you can not step into a mapper or reducer, I use counters instead to trace what’s going on in there. I also like that one can read and write sequence files with one call, to examine the output of previous jobs and decide what to do next. Additionally since R is a statistical language and Hadoop is the tool of choice for big data analytics, this seems like a natural fit.

Antonio has also written several in-depth blog posts about Rhipe, including examples of doing relational joins within the Hadoop framework, and on graph analysis in Hadoop (useful for social-network applications).

Dataspora Blog: Pigs, Bees, and Elephants: A Comparison of Eight MapReduce Languages

Parallel processing in R for Windows

The doSMP package (and its companion package, revoIPC), previously bundled only with Revolution R, is now available on CRAN for use with open source R under the GPL2 license.

In short, doSMP makes it easy to do SMP parallel processing on a Windows box with multiple processors. (It works on Mac and Linux too, but it's been relatively easy to do parallel processing on those systems for a while with doMC/multicore package combo. Windows, not so much.) Basically, you tell it how many processors you have, write a loop using the foreach function, and the iterations of the loop run in parallel, using multiple processors. For embarassingly parallel problems like simulations and optimizations and such, if you have 2 processors you can get close to halving the processing time; reduce it to near 25% with 4 processors, and so on. (Whether these are true, independent CPUs or cores within a processor matters a little, but not much.)

You can see some examples in the doSMP vignette, from which I adapted the following example. Suppose you want to bootstrap parameter estimates from a logistic regression using 1000 samples:

x <- iris[which(iris[, 5] != "setosa"), c(1, 5)]
trials <- 10000
chunkSize <- ceiling(trials/getDoParWorkers())
smpopts <- list(chunkSize = chunkSize)
r <- foreach(icount(trials), .combine = cbind, .options.smp = smpopts)
  %dopar% {
  ind <- sample(100, 100, replace = TRUE)
  result1 <- glm(x[ind, 2] ~ x[ind, 1], family = binomial(logit))
  coefficients(result1)
}

Created by Pretty R at inside-R.org

Note the use of foreach to run the bootstrap models in parallel. On a 4-core machine, you could reduce processing time from 104 seconds to 57 seconds compared to using a regular for loop. Not quite a fourfold reduction, but a significant reduction in time nonetheless. (Tip: if you're using Revolution R, you might want to try turning off MKL multithreading when using doSMP/foreach, to avoid contention between the small-grain threading of MKL, and the large-grain parallelism of foreach.)

I've written about foreach several times before (here, here and here for example) using other parallel backends like doMC and doSNOW. Now you can use those same examples on Windows with open-source R and the doSMP package.

doSMP package: Getting Started with doSMP and foreach

Setting up a parallel computing cluster for R with OpenSSH and doSNOW

Responding to yesterday's post which included an aside on using parallel processing for by-group computations in R, reader Christian Gunning mused about the possibility of using doSNOW on his network, with OpenSSH to manage the authentication:

I sit on a fast campus network and have at least 10 remote cores available that I could farm out for big jobs. the SSHcluster method would require minimal invasion on those machines -- just ability to execute ssh and Rscript on the remote machines -- not even login privileges are required!

Well, Christian developed that idea into a step-by-step guide for setting up a multi-node cluster for parallel programming using foreach and doSNOW. Check out the full guide (including both R and shell configuration code) at the link below.

Life In Code: snow and ssh -- secure inter-machine parallelism with R

 

Packages for By-Group Processing in R

Analyst and BI expert Steve Miller takes a look at the facilities in R for doing "by-group" processing of data. The task consisted of:

... read several text files, merge the results, reshape the intermediate data, calculate some new variables, take care of missing values, attend to meta data, execute a few predictive models and graph the results.

Then repeat the models and graphs for groups or sub-populations marked by distinct values of one or more dimension variables of interest.

The latter step is commonly referred to as “by-group processing.” SAS programmers will recognize by group processing with syntax that invokes a procedure on a sorted data set that looks something like:

proc reg data = dblahblah; by vblahblah;

Check out Steve's post for how he addressed this in R using the high-performance data.table package by Matthew Dowle (and as Steve suggests, a good place to get started is the example vignettes). 

I'd also add a recommendation for the plyr package which also offers tools to split up data sets by various criteria, and then do by-processing. Here, the plyr: divide and conquer guide is a good place to start. As an added bonus, you can also divide and conquer the computations by exploiting multiple nodes in parallel by engaging a parallel backend for the foreach function. (Note for Windows users: the doSMP backend from Revolution R is also available now on R-Forge and will be on CRAN soon, too.)

Information Management: By-Group Processing, the R data.table and the Power of Open Source

 

Run R in parallel on a Hadoop cluster with AWS in 15 minutes

If you're looking to apply massively parallel resources to an R problem, one of the most time-consuming aspects of the problem might not be the computations themselves, but the task of setting up the cluster in the first place. You can use Amazon Web Services to set up the cluster in the cloud, but even that take some time, especially if you haven't done it before.

Jeffrey Breen created his first AWS cluster this weekend, and in just 15 minutes had demonstrated how to use 5 nodes to generate and analyze a billion simulations in R. It was a toy example, sure -- estimating pi -- but it's a great example of how quickly you can set up a parallel computing environment using R. Jeffrey used JD Long's segue package, which works with the Hadoop Streaming service on AWS. The segue package is still in the experimental stage, but still: this is a great demonstration of applying cloud-based hardware to parallel problems in R.

Jeffrey Breen: Abusing Amazon’s Elastic MapReduce Hadoop service… easily, from R

Using R and Hadoop to analyze VOIP data

Last month, the newest member of Revolution's engineering team, Saptarshi Guha, gave a presentation at Hadoop World 2010 on using R and Hadoop to analyze 1.3 billion voice-over-IP packets to identify calls and measure call quality. Saptarshi, of course, is the author of RHIPE, which lets R programmers write map-reduce algorithms in the Hadoop framework without needing to learn Java. With R running on each Hadoop node, Saptarshi used R's data analysis functions (such as robust regression) to process almost 100 Gb of data in just a few minutes.

The slides for Saptarshi's talk are now available to view at the Hadoop World website (linked below), or you can download a PDF version (7.3Mb).

Hadoop World 2010: Voice over IP: Studying Traffice Characteristics for Quality of Service using R and Hadoop

 

Making sense of MapReduce

From guest blogger Joseph Rickert.

Last night I went to hear Ken Krugler of Bixolabs talk about Hadoop at the monthly meeting of the Software Developers Forum. Maybe because Ken is an unusually lucid speaker, or maybe because I just reached some sort of cumulative tipping point through the prep work of all those patient people who have tried to help me in the past; but finally, I think I get Hadoop and MapReduce.

First of all, it’s MapReduce and then Hadoop: not Hadoop with MapReduce. The way to think about Hadoop is that it is the open source choice for implementing MapReduce like algorithms. Hadoop may provide technical advantages over competitors (Twister, Greenplum and others) about which I am in no position to comment, but it is nevertheless only one of several MapReduce frameworks.

The second big “revelation” was the nature of MapReduce. When dealing with massive data, it is very likely that the size of the data to be processed is many orders of magnitude larger than size of the software required to process it. The revelation is: not only does it make sense to move the code to the data, but one ought also to do as much parallel processing as possible. Looked at this way, MapReduce is a variation of the flow based programming techniques developed by mainframe programmers in the 60’s and 70’s which were part of a tremendous effort to understanding parallel programming during that time period. In fact, the tuples of Linda spaces, the precursor of Network Spaces which forms the conceptual foundation Revolution’s parallel R programming package, ParallelR, is probably a direct ancestor of MapReduce’s key – value pairs. Furthermore, the buzz in the R community about Hadoop makes sense if one thinks about Hadoop as the open source way to implement sophisticated R based MapReduce algorithms. R should be an ideal choice for implementing parallel algorithms that work on independent chunks of data.

Guidelines for efficient R programming

R is designed to make it easy to clearly express statistical ideas in code, but when it come to writing code that runs as fast as possible, there are a few tips, tricks and caveats to be aware of. As part of the BioConductor conference this past summer, Martin Morgan prepared a tutorial on efficient R programming. (Patrick Abouyen presented the tutorial on the day.) The slides (PDF) include lots of handy guidelines, including:

• Common performance pitfalls, and solutions
• How to measure performance and memory use
• How to work with large data files (handy if you don't have RevoScaleR)
• How to use parallel computing to speed up "embarassingly parallel" jobs (for example, use foreach/doSMP)

There's also a collection of exercises (PDF) you can use to test out your efficient programming skills. Many of the examples come from the Genomics domain (as befits the BioConductor conference), but the advice is relevant to any R user.

BioConductor.org: BioC 2010 Course Materials (see section Efficient R Programming)

Update Sep 28: Corrected spelling of Patrick Abouyen.

Saptarshi Guha on Hadoop, R

Saptarshi Guha (author of the Rhipe package) joins the likes of Ebay, Yahoo, Twitter and Facebook and as one of just 37 presenters at the Hadoop World conference. (Revolution Analytics is proud to sponsor Saptarshi's presence at this event, which take place in New York on October 12.) He'll be talking about using R and Hadoop to analyze Voice-over-IP network data for Quality of Service, as explained in this abstract:

RHIPE is an R package that integrates the R environment for statistics and data analysis with the Hadoop distributed computing framework. With RHIPE, the user can store and compute with large and complex data sets using R functions and programming idioms. In this talk, I will demonstrate the use of RHIPE to analyze 190Gb of VoIP network data for QoS. The jitter between two consecutive packets is the deviation of the real inter-arrival time from theoretical. We show jitter follows desired properties and is negligible, which supports the assumption of the measured traffic being close to the offered traffic.

Saptarshi explains more about his talk, and his work with Hadoop and R, in this interview at the Cloudera blog.

Cloudera blog: Purdue University’s Saptarshi Guha Interviewed Regarding Hadoop, R and Hadoop World