ActionScript 3.0 Design Patterns

Decomposing a solution for multicore processing

I’ve been looking at a lot of materials on parallel programming attempting to sort out the issues involved. One of the big issues is granularity, and not only does granularity affect the way we think about design patterns, it also impacts algorithms. To make matters even more interesting, granularity is affected by the number of cores your computer has, and so not only is it important to consider the level of granularity for a general level of programming efficiency, it’s also important to consider the hardware.

I don’t want to re-visit the issue of first learning OOP and Design Patterns to get away from concerns of tweaking algorithms and extracting the last electron of speed, but let’s face it, not only are we tossed back into the algorithm business, but we’re programming down to the metal. So even if Adobe came along tomorrow and told us, ActionScript 3.0 is now totally hooked into multicore access, it’d be a while before we could spool up to the point where we could be anywhere near as efficient as we are now with single core programming. In some respects, Adobe has saved our bacon because while it’s getting ready to provide parallel programming for ActionScript, we have time to learn how to think about using multiple cores.

The Free Ride is Over

Sometimes a phrase is uttered and at some level I understand it, but I really don’t appreciate it.

Last year in a video on parallel programming, Ralph Johnson said, ‘The free ride is over’ and now I get it.

Learning OOP and design patterns has come close to guaranteeing that once you mastered them, your programs would become increasingly more effective (in getting them done and revised), more available to re-use, and for participation in team projects. They would also become more efficient over time because Moore’s law was hard at work doubling processor capability every two years or so. Using OOP and design patterns helped us effectively organize our code into neat programs and we didn’t have to think too much about algorithms and certainly not our processor. Programming had become wholly divorced from the hardware—along with the OS and brand and clock-speeds. Those things took care of themselves. That was the “free ride”—no changes in our programming behavior.

Now, we have to think about things like the number of cores in our stupid processors. Let’s hope we don’t have to worry too much about OOP and design patterns—if they stay relatively stable, we can now begin to focus on these multiple cores. The free ride is indeed over.

Granularity

The last time I thought about granularity, I was thinking about the number of child classes in a design pattern. That’s not what granularity is in parallel programming.

In parallel computing, granularity is a qualitative measure of the ratio of computation to communication. Blaise Barney, Lawrence Livermore National Laboratory

Fortunately, we’ve been using OOP, and so are clear on the concept of communication between objects. (If you’re still doing sequential programming, bump up to OOP, quick!) What the conversation is about the time that your processor(s) is working through an algorithm or data processing and the amount of time it’s communicating to the other objects about the computations. The polar types are:

1. Coarse: relatively large amounts of computational work are done between communication events
2. Fine: relatively small amounts of computational work are done between communication events

We need to begin this conversation. How coarse or fine should a program be? What criteria do we use? Is there a handy formula? Just leave OOP and design patterns alone for the time being. Treat them as immutable but essential; later on we can start tweaking them for parallel programming.

Domain Decomposition

Since we don’t have to think about what actually happens to our program—it’ll be handled by the OS and we cannot direct threads to cores anyway. We can pretend to do so, and that’s all that counts right now. In the next post on parallel programming (and on subsequent ones) I’d like to write some programs in ActionScript 3.0 that illustrate domain decomposition as a first step. This will involve taking a process and breaking it down into smaller parts and processing each one separately, and then joining the results. Not only will this be an example of targeting multiple cores, but it is a very clear illustration of what computational and communication processes look like. In the meantime, think about the new kind of thinking required to optimize a program where using more than a single processor is the only way to improve performance—the end of the free ride.

Related posts:

1. Parallel Programming on the Radar for Adobe