Video: distributed rendering

A good development framework can make software development a joy--unencumbered by the banalities of software development, you can spend your time on the interesting and productive elements of programming. I know I'm waxing poetic a bit, but I'm really excited by what I just saw.

Yesterday, we gave a project to our newest employee, Pandelis, in order to have him familiarize himself with our development framework. We asked him to create a distributed rendering demonstration. We gave him POVRay, a free rendering tool. I also gave him the application we frequently demonstrate with--distributed Mandelbrot (you may have seen this video, which shows that demonstration).

This morning, he showed me this:



In a few hours' time, he took the "wrap and adapt" approach: threw a .NET class around the data, had that class invoke the renderer, and he was done. No modifications to the POVRay source code. No extra work preinstalling anything on the nodes. No extra code to handle serialization, node failure, etc.

As a total bonus (and complete coincidence), I had a sales call with a company that does a ton of graphics work today. Pandelis quickly made an installation (Visual Studio makes simple MSIs so easy to deal with, btw), and I literally ran the MSI, did one practice render, then demo'd it to the potential customer. He was very impressed.

Great job, Pandelis!

Speaking of distributed rendering, why does it take so long for my video to be available after I upload it? Google, do you need some help with your distributed processing? ;-)

Updated 2008/01/02: Fixed a link.

Technorati tags: grid computing, digipede, povray

New Papers: Using Digipede with Matlab, Java

O

ver at the Digipede Community site I posted two papers yesterday. These are fairly technical documents that give step-by-step details on how to use the Digipede Network with some popular technologies.

The first paper explains how to integrate MATLAB M code into a Digipede Worker; it's a fairly simple process thanks to MATLAB Builder for .NET (and we have several customers doing this in production today). Later, we'll release some more touch-points between Digipede and MATLAB: distributing an executable compiled with the MATLAB Compiler, submitting a Digipede job from within MATLAB code, and using Digipede with the MATLAB Distributed Computing Toolbox.

The second paper explains how to use the Digipede Network with Java. Now, it's possible to invoke COM from within Java if you really want to, so technically it has always been possible to launch and monitor jobs. However, our .NET users know that the real power in the Digipede Network is the distribution and execution of objects. Well, thanks to our partners at JNBridge, you can now take advantage of our powerful object execution model natively from within Java--you can distribute and execute Java objects on your .NET grid. That is powerful stuff. Robert Anderson put this together; check it out.

Technorati tags: .net, digipede, jnbridge, matlab

Outlook! In a flash!

T

his morning my Outlook client greeted me with the following behavior:
See that? The login screen was flashing repeatedly--appearing and disappearing in less than a second, then doing it again a few seconds later.

A system restart seems to have corrected it.

Anyone seen this before?

CCS and Digipede: More Differences

L

ast week I posted about the differences between Windows Compute Cluster Server 2003 and the Digipede Network--the post generated a lot more traffic than I would have guessed. Apparently, many people have been wondering how our products differ. I said I'd follow up with more details, so here goes.

Developer focus. In summary, CCS includes tools for scientific developers, the Digipede Network includes tools for enterprise .NET developers. For more details, see my previous post.

What does it run on? The biggest difference between our product and theirs is that, at its heart, CCS is an operating system (Windows Server 2003 Compute Cluster Edition). It runs on bare iron. The Digipede Network is a grid computing framework that runs on top of the operating system and on top of the .NET Framework as well. We're two floors up from CCS.

Mind your bitness! Compute Cluster Edition is built on Server 2003 x64--it only runs on 64-bit hardware. The Digipede Network runs on top of Server 2003, XP, Vista, and Server 2000--32- or 64 bit editions.

Microsoft technologies manage your machines, Digipede manages your grid. Microsoft makes tools that make it easier to manage large numbers of machines (MMC, MOM, etc). These tools are designed to help you manage computers. The Digipede Network doesn't help an administrator manage machines, it helps an administrator manage a grid. Which users can submit to which machines? What times are the desktops running grid jobs? What priority are the overnight batch runs? These are the things that the Digipede Network takes care of.

Homogeneity and heterogeneity. A cluster is nearly always a tightly coupled group of homogeneous machines: identical hardware, identical operating systems, all linked (often with a high bandwidth backplane). A grid, on the other hand, usually has a heterogeneous blend of machines: different OSs, different hardware, different connectivity.

Dedicated vs. shared. Clusters are nearly always what we refer to as "dedicated" hardware: the machines in the cluster are used purely for computation. However, grids can have any combination of dedicated hardware and "shared" hardware--that is, hardware that is used for computation on the grid but may also be used for other purposes: file servers, app servers, even desktops. Some of our customers use all dedicated hardware, but a fair number are supplementing their dedicated hardware by "cycle scavenging" from other resources in their enterprise (the white paper I linked to recently details one customer's experience with cycle scavenging).

Grid.Contains(Cluster) = true. As a side effect of the previous two points, you may realize that a grid can contain one (or many) clusters. Many of our customers have clusters as a part of their grid. Some jobs may run only on the cluster, but by using the cluster as a part of the grid, they have one comprehensive tool that has information about all of their work.

Final analysis: two great tastes that taste great together. This is the point I make over and over: these are very complementary products. The Digipede Network runs on top of CCS, extending it both in terms of capabilities (adding .NET and enterprise features) and in terms of capacity (by running loosely coupled and 32-bit jobs on other machines, ensuring that your cluster is available for those tightly coupled MPI jobs).

Technorati tags: grid computing, cluster computing, digipede, ccs

Digipede Network and CCS: What's the Dif?

One of the questions I get frequently from potential customers is "How is the Digipede Network different from Windows Compute Cluster Server?" I've spent the last 16 months or so reciting the same answer over and over again; when John Powers suggested I write a blog entry about it, I was (frankly) surprised I hadn't already.

But, searching through my del.icio.us tags in the sidebar, I see that I haven't. So here goes. This will take a couple of posts; in this one, I'll concentrate on my favorite part of the answer: how the Digipede Network differs from CCS from the developer's perspective.

Let's start with why CCS exists in the first place: in order to compete in the scientific and technical computing space, Microsoft knew they had to revamp their OS.

Windows Compute Cluster Edition is basically Windows Server 2003 x64 Edition. Microsoft took Server 2003, and added support for the type of hardware frequently seen in clusters (high-bandwidth networking like Infiniband, for example), and additional support for Remote Direct Memory Access (necessary for MPI implementations).

Next, they added in the Compute Cluster Pack. CCP is a set of tools that sits on top of the OS and provides additional software support for technical computing: specifically, an MPI stack, a cluster job scheduler, and a set of management tools.

In other words, CCP sits on top of CCE to make the OS into a tool usable for scientific and technical computing. CCS (Compute Cluster Server) is simply CCE and CCP together.

Ok, that's the Microsoft product line. How does Digipede fit in?

Well, while CCP has plenty of tools for the scientific developer, it has almost nothing for the enterprise developer. If you're developing in .NET, it doesn't translate naturally to a cluster paradigm--in order to work with CCP, you'd have to compile your .NET down to a command-line executable, and do all of your data passing either in files or on the command line.

The Digipede Network, however, can put your CCE nodes at the disposal of a .NET developer. Without restructuring your application, without moving to a command-line paradigm, without deploying your EXE to the different nodes. By automatically deploying .NET assemblies (and related files), then distributing and executing .NET objects natively, the Digipede Network adds a layer of .NET support onto CCE.

We handle the .NET parts of things. They handle the OS. Want 64 new nodes on your grid? Buy a cluster of CCE nodes. You'll save a boatload of dough over the Windows Server 2003 license costs, and you'll get good deployment tools. Throw Digipede Agents on those nodes, and suddenly you've got a high-powered, .NET supercomputer on your hands.

Want to see the difference between CCS and CCS + Digipede? Watch these two MSDN webcasts. In the first, Ming Xu and Sanjay Kulkarni from Microsoft put a calculation on a CCS cluster behind a spreadsheet.

In the second, I do the same kind of thing, but I use the Digipede Network on top of CCS.

The difference? In the first demo in that webcast, Ming and Sanjay want to put some .NET logic behind a spreadsheet. They had to write a Web Service that the UDF in Excel talks to, then deploy that Web Service to the head node on the cluster. When that Web Service is called, it communicates with the CCS job scheduler to start a job. They wrote a command line executable that actually did the analysis, deployed that EXE ona file share, then had his CCS job invoke that command line executable. That command line executable in turn writes to stdout, and stdout from each task is redirected into a file on the file share. The web service polls the job scheduler to see when the job completes, waits for the job to finish, collected the results from the command line executable by opening each file, then returns the results to the UDF (which, you recall, had originally invoked the web service).

Whew! That's a lot of moving parts. It uses technologies common to technical and scientific computing (e.g., using command line executables, handling data passing using command lines and files on a share), but perhaps not as familiar to enterprise developers working in Excel.

In the second demo in this webcast, I implement a similar pattern, but I do it behind Excel Services (the same thing can happen behind Excel). The big difference is that it's much, much simpler. My User Defined Function in Excel Services simply passes .NET objects to the Digipede Network. Those objects are automatically distributed around the cluster, executed, and returned to the UDF. There are many fewer moving parts. I didn't have to predeploy or prestage my executables or DLLs, and I didn't have to mess with web services, command lines, command line EXEs, or getting data into and out of files.

To be clear, I am definitely not slamming CCS--it's a very good product, and it's making inroads in exactly the market it was aimed at: scientific and technical computing. What we've done is what good partners do: extend that product so it can be used by in another way entirely: as a plank in a grid computing platform.

More later on other differences between CCE (the OS) and the Digipede Network (the grid computing platform).

Update 2008-01-03: See my follow-up post for more differences...

Technorati tags: grid computing, digipede, ccs

Cool Grid White Paper

Many of our customers are what you might think of as typical grid computing customers: finance, government, digital content creation, storm simulation. These are the applications that people typically think of when they think about grid computing.

But we have many customers far outside of the typical grid computing realm. These are people who have .NET applications that need speed and scale, and are using grid computing to solve their problems. The breadth of these applications is amazing--people use .NET to do a lot of interesting things.

One of those interesting customers is Trekk Cross Media. Trekk is a marketing and communications company that can tap into some great tech expertise to create fantastic solutions. Jeff Stewart, their VP of Technical Services, recently gave a talk and presented a paper at the ESRI International User Conference. The paper shows how they used grid computing (the Digipede Network, of course) to dramatically increase the throughput of their custom mapping application.

Great job, Jeff!

Check it out here.

Technorati tags: grid computing, digipede