R” integrated with Symphony

In my previous blog, I mentioned that Platform Symphony can be used in statistical computing. “R” is a programming language and software environment for statistical computing and graphics. The R language has become a de facto standard among statisticians for developing statistical software, and is widely used for statistical software development and data analysis. R is an implementation of the S programming language combined with lexical scoping semantics inspired by Scheme. Below is an example of how R can be used to speed calculations:



Sample code of R:

func <- function(x, y, z) { some operations }
data1 <- c(1:20000)
data2 <- c(20000:1)
result <- data1
for (i in 1:500)
{
iresult <- mapply(func, data1, data2, i) # Time-consuming operation
result <- result + iresult
}
Problem:

One of our customers was running that on single node and it took around 5 minutes to
complete on single core. Is there a way to parallelize the above code and make use of multiple cores to speed up the calculation?

Solution:

We integrated “R” with Symphony and ran the same script that took five minutes on single core, now took around 30 seconds on 10 cores. With Platform Symphony, one gets linear speedup and virtually unlimited scale.

Platform Symphony outside Financial Services

Although the majority of Platform Symphony’s customers are in the Financial Services sector, Platform Symphony’s core value propositions (faster, cheaper with more agility) also apply to a variety of industries outside of Financial Services.

For example, Platform Symphony is widely used for Monte Carlo simulations in finance. Those same methods has actually also been applied to fields as diverse as space exploration, oil exploration and predicting cost or schedule over-runs. Specific application areas that make use of Monte-Carlo simulation include:

• Reliability engineering (CAE)
• Bio-molecular simulations, computation chemistry (Pharma)
• Particle physics & big research (Government)

There are also other applications that can utilize the power of Platform Symphony--for example, statistical computing and numerical computing. In my next blog post, I’ll talk about how just how Symphony can be applied in statistical computing scenarios.

Platform Symphony for Financial Services

One of the principal applications for Platform Symphony is risk management. While risk management techniques vary by customer type, all financial services companies face the same basic challenge of modeling multiple scenarios describing different risk factors so as to maximize gains and minimize the potential for financial loss.

Here are some examples of problems financial services customers are typically trying to solve:

• Value at Risk (VaR) – end of day / intraday – Monte Carlo simulation based or based on historical market data
• Pricing model validation / back-testing
• Model changing risk intraday to drive hedging strategies
• Sensitivity analysis / “what-if” analysis
• Accurately measure risk to optimize capital reserves
• Counterparty credit risk analysis
• New product development
• Pre-trade limit checks
• Calculate key measures like CVA on a pre-deal basis
• Timely reporting to meet regulatory requirements
• New regulatory requirements driving increased need for HPC

In all of the above examples, customers parallelize the application(s) via APIs and tools provided by Symphony. Fine grained units of workload are submitted to Symphony. Symphony schedules those units of workload to the all of the available resources based on the configured policies.

HPC from A-Z (part 7) - G

G is for Gambling.

Whether you like to place the occasional bet or not, most of us would agree that online gambling and gaming is a big money industry. Not only can we now wager our money on more events than ever before (from the result of the Super Bowl or the elections to whether it will snow on Christmas Day), but the age of the internet is also fuelling an increasing demand for “live-in play” and virtual games like online poker.

As you can imagine, managing the real-time odds and the artificial intelligence required to support virtual gambling environments requires some serious computing power, not to mention the resources required to calculate all those odds. Firms like Sporting Index rely on HPC to give them the edge over competitors, letting them plan hundreds of moves ahead and crunch vast amounts of data to generate odds for all manner of wagers.

Think all that would be possible without HPC? Don’t bet on it.

Not to burst your bubble…

Probably everyone who has ever been in an HPC environment as a user has run into resource constraints. Limitations like hardware, licenses, memory, or maybe even GPUs on hybrid compute engines rank at the high end of the limitations most users face are facing today. The problem comes when you run into these limitations in the middle of running a job. What do you do then? “Hitting the stops,” so to speak, will often cause another procurement cycle and consume lots of resources in terms of analysis, internal meetings, planning, as well as the purchase and deployment phases before any additional real work can get completed.

Cloud computing, or in this case, cloud bursting offers an approach to mitigate the process and limitations that most HPC consumer corporations go through today. Certainly, using resources outside the firewall can have its own challenges for corporate users, but those aren’t the focus of this blog.

Assume for a moment that security, licensing, provisioning latency and data access are not a problem. Of course, they’re all major issues that need to be addressed to make a cloud solution usable, but bear with me. There are still some important questions that need to be answered:

• What are the appropriate conditions to start up and provision cloud infrastructure?
• What jobs should be sent to the cloud once that infrastructure is provisioned and which should stay local and wait?

This second question is the focus here. Often in science, the hardest part of solving a tough problem is stating the question properly. In this case, the question is nicely represented by the below inequality where each entity represents a factor of elapsed time. For cloud computing to be advantageous from a performance perspective,

(Data upload to cloud) + (Cloud Pend time) + (Cloud Run time) + (Data download from cloud) < (Local Pend time) + (Local Run time)

Such a statement allows us to draw a few conclusions about the conditions for when cloud bursting is advantageous for the HPC user:

• When local job pend time estimates for a job get very large
• When local elapsed run time is large -- A corollary to this condition is that if the job can be parallelized, but there are insufficient resources locally to run the job quickly, then cloud bursting the job may return results to the user sooner than allowing the job to run on insufficient resources locally.
• When the job’s data transfer requirements into and out of the cloud are small

Additionally to those conditions, we start to see where several of the real challenges are for a scheduler to make the right decision about which jobs get sent to the cloud and which don’t. For instance, most schedulers today do not consider the data volume associated with a job. But, in a cloud scenario, the data transfer times associated could be 2-50x the runtime for a job and not only dependent upon the file size, but the available transfer bandwidth. Schedulers will need to evolve on several levels to tackle this challenge:

• Allow users to indicate the files (both input and output) required for each job.
• Estimate pending and run time for disparate infrastructures
• Estimate the run time for jobs which run parallel

Be on the lookout for solutions from Platform Computing that start to address exactly these challenges.