Performance

Digg This!

Page 1 of 2   next page »

With all the hype on the Web about grid computing and scaling out applications, I decided it was time to get my hands dirty.

What's grid computing you ask?

According to Wikipedia, "Grid computing is an emerging model that provides the ability to perform higher throughput computing by taking advantage of many networked computers to model a virtual computer architecture that is able to distribute process execution across a parallel infrastructure."

If you're more confused by that definition, don't worry. It's really just a way of using computing power from a bunch of computers connected to a network.

This, in essence, creates a virtual supercomputer.

At this point, I was searching for a project to work on that could help me understand and use a grid. After attending optionsScalper's presentation on "F# under an Application of Quantitative Finance," I had my answer. F# (say F Sharp) is a .NET meta-programming language developed by the Programming Principles and Tools Group at Microsoft Research in Cambridge, the same group that brought us .NET Generics.

Like OCaml, F# is excellent at writing tools for symbolic programming. Examples of this type of programming include static analysis, compilers, and other sophisticated analyses over structured data terms. Remember using Maple or Matlab? How about Mathematica? That's what writing F# is like. If F# is to be used to analyze various complex problems, then harnessing it to a virtual supercomputer seemed like a logical thing. Slated to learn two new technologies, I was hoping I hadn't bit off more than I could chew.

The Grid
The first thing I wanted to do was find out what was being done with grids in the .NET environment. I was quickly led to the Alchemi open source project at the University of Melbourne. Alchemi was conceived and designed in July 2002 by Akshay Luther while in the penultimate year of his software engineering degree. Now hosted on SourceForge, it looked like a great staring point. After downloading and examining the source (Alchemi-1.0.0-src.zip) I was impressed with how straightforward it was. Alchemi uses two key modules, the manager and the executer. Both can run as a desktop application or a service. The manager takes care of getting the desired process (job) up and running on the grid and ensuring its completion. The executor, on the other hand, is the workhorse of the framework; it runs on the nodes of the grid and does the bulk of the work. (Figure 1)

I started by installing the manager and executor on my development box along with firing up some of the samples that came with Alchemi: the Pi calculator, prime number generator, and fractal generator. All the samples ran perfectly, but only on one machine. Wanting to watch what was happening on the grid, I dug through the documentation and found the Alchemi SDK (Alchemi-1.0.0-sdk.zip), which includes a console application. This application lets you hook into the manager to monitor the grid jobs and their performance. (Figure 2)

I chose the Pi Calculator example to compare performance metrics. First I wanted to see how quickly the job would run with just the one executor on my system. According to the console application I had 3.407GHz available to execute the job, which makes sense on a P4 3.4Ghz system. The result is shown in Figure 3.

The next step was to install the executor on a handful of boxes and see how much faster the samples ran. For starters, I installed the executor on four other machines and watched the available power rise to 11.823GHz...not bad! With all five executors ready to run the Pi Calculator job in parallel, I fired it up and stood back. The time to complete the job fell from 27 seconds to 14 seconds. Impressed with the overall performance and ease of use, I decided to try getting some F# code running on the grid.

The Parallel Problem
One of the problems, or at least concerns, with grid computing is the change in thinking required to develop applications. Typically developers write code using a single thread, only using multithreading when performance is an issue.

For an application to run on a grid, everything has to be written as a thread. Additionally, these threads have to be able to handle pieces of an overall task. For example, say we wanted to create a simple job that counted from 1 to 100 with a one-second delay between each increment. On one machine, using one task this would take 100 seconds. If we broke the job into 10 threads and had each thread count from n to n+10, it would take 10 seconds to complete.

The difficulty is defining the problem in such a way that it can be broken into these parallel tasks.

Historically, problems that can be broken down nicely have been confined to the realm of mathematics and engineering. More recently companies like IBM, HP, Oracle, and Sun are making strides to make grid computing a viable solution in the business environment.

While still not mainstream, awareness, research, and tools like Alchemi can help bring grid computing to the business enterprise environment.

In Alchemi, parallel tasks are defined in the GThread abstract base class. As shown in Listing 1, the developer can, for the most part, design the thread as if it were to run locally.

After examining the Alchemi sample source, it was apparent that I had two roads I could go down: launch the F# as its own job using the classes provided by Alchemi or use C# to write a bootstrapper to load my F# functions. I chose to start with the bootstrapper method because I thought it would be the simplest way to get something working. My approach was to use the Pi calculator sample provided by Alchemi and rewrite the Plouffe-Bellard Pi calculation example in F#.

Fabrice Bellard and Pi
It's important to note that the algorithm I used is an implementation of Fabrice Bellard's 1997 Pi calculation algorithm. Based on the Taylor series, Bellard found Equation 1.

From Equation 1, Bellard used the work of Simon Plouffe and improved the algorithm to produce one whose running time is O(n^2). This work is published in his article "Computation of the n'th digit of pi in any base in O(n^2)." We'll use the algorithm from section 3 of Bellard's paper, Equation 2, as the algorithm for determining n'th digit of p in base B.

Since Bellard's equations are based on the work of Plouffe, I'll refer to them as Plouffe-Bellard for the remainder of this article.

The Plouffe-Bellard Pi calculation example that's provided with Alchemi is in Listing 2.

To get my application running on the Alchemi grid, I needed to:

1. Build a class that implements a parallel processing algorithm. This is done in the Plouffe-Bellard calculation class.
2. Create a class that's derived from GThread that uses our algorithm. This is done in the PiCalcGridThread class.
3. Put the threads on the grid using the Alchemi API. This is done in the PiCalculatorMain class.

In Listing 2, I show what the Plouffe-Bellard calculation class looks like so we can move on to step two. The PiCalcGridThread derives from GThread and is as in Listing 3.

In Listing 3 you can see that the constructor takes the start digit number and the number of digits as arguments. These arguments are the means by which we break the job of calculating Pi into smaller pieces. Putting the PiCalcGridThread class on the grid is done in the PiCalculatorMain class and looks like Listing 4.

In Listing 4, App is an instance of the Alchemi GApplication class. Since the example code provided with Alchemi does a nice job of getting the task up on the grid, we'll use it without modification.

Starting with F#
From this point I wanted to do the Plouffe-Bellard calculation using an F# library. It took me a while to get F# to play nicely in the Alchemi PiCalculator solution, but after I figured it out it boiled down to only a few steps.

1. Download and install the F# compiler.
2. Add a new F# project to the PiCalculator example solution.
3. Set the F# project output to DLL (pb.dll).
4. Add the files pb.fsi and pb.fs to the F# project.
5. Include pb.dll, mllib.dll and fslib.dll references in the PiCalculator project.

Next I wanted to get a bit of F# code written that would run on the grid. This was the hardest part of the project since thinking in F# is a bit like speaking in another language. Until you're immersed in it and understand the culture, a lot of things don't make sense.

The pb.fsi file defines the interface to your F# code. This is the mechanism that F# uses to interface to other chunks of code. It's the relatively simple file in Listing 5.

Page 1 of 2   next page »