Tuesday, September 29, 2009

OPL

The OPL paper groups patterns into a hierarchy, targeted at the level of abstraction, and therefore the proposed target audience of the pattern.  As is alluded to, however, many developers must be "tall and skinny" in today's world where appropriate frameworks are not available.  This organization may prove more effective as time progresses, and more relevant frameworks emerge.

As for the granularity of the patterns, I think it would be premature to start to generate a detailed encyclopedia of parallel patterns, as the applicability of patterns at a pragmatic and proactive level hasn't yet been addressed. OPL forms a good categorization of these patterns from which further refinement can be tackled.

I think that parallelism in general has been overlooked by application-level programmers for years for a number of reasons, some relating to skill, but many relating to business pressures.  Often times very aggressive release deadlines coupled with extensive feature sets, taken in conjunction with uncertainty about the future of the software lead to a mentality about software architecture that I would paraphrase as the following (perhaps to be called the pragmatic and overworked programmer's manifesto):
I have nowhere near enough time to build this system "right".  In fact, I'm not sure that I really know what "right" is anymore, given the eternal chain of short-deadline projects that I've worked on over my professional career.  I've developed my skills to build systems at a breakneck pace, giving little thought to the overall performance or long term viability of the application's architecture.  Since programmer time is expensive compared to the ever cheaper machine time, management doesn't want me to spend any time "optimizing" something that they feel they can just "throw more hardware at".  Furthermore, no one really knows if this software is going to see version 2.0.  If I don't get version 1.0 out the door, we certainly won't, and perhaps regardless of my best intentions, this program may fail to meet the users needs, or the users may not have had these needs to the extent to make this system viable in the first place. Oh well, if it's a success, we can always go back and "make it right"...or not...who wants to mess with code that's "good enough".  Until a competitor comes along that shows the users that this type of software can be way faster than our's, the users will generally learn to accept the performance that this software offers, so why waste time parallelizing it?
 The problem with the above manifesto is that although time-to-market can make or break a business, lack of scalability can do the same.  If the software succeeds, by the time the programmer goes back to "make it right", they'll have users beating down their door for more features.  In the end, if they really *have* to optimize through parallelization, they'll likely find a hack of a solution, which doesn't work in the abstract case, but causes few enough issues to suffice.  This will make the application brittle to future changes.

It's my opinion that as frameworks evolve, and programming languages are made more expressive and declarative, more parallelism will be implicit.  At some point, these frameworks for parallelism and overall application architecture will become powerful and easy enough where a break-even point will be reached for programmers to either implement the system in a break-neck, no time to think about architecture manner, and  a paradigm where most of the functionality falls out of having the appropriate architecture.  At that point, we'll start to see a migration towards parallel frameworks.

Parallelism has become a more recent problem as Moore's law has stopped applying principally to clock speeds, and moved towards concurrent power.  All of a sudden, developers who were banking on the next generation of clock-speed-faster machines to make their single-threaded software run faster have been left out in the cold to wonder about how they can retrofit parallelism--not an easy task for a complex system.

No comments:

Post a Comment