Just Because

So, I feel like I should write something. I don't know why, but I do. There isn't a lot going on these days for me to write about...I saw American Gangster and No Country for Old Men. Both were good movies. American Gangster makes me sad mostly because Ridley Scott just seems like he's trying to win an award these days instead of making quality cinema. No Country for Old Men was brilliant. Saying more about either would be doing you all a disservice, either because I'd be spoiling Old Country for you or because I'd be wasting your time telling you things you could have guessed about American Gangster with only minimal knowledge.

Seeing as I'm starting to get a vague idea of who reads this thing, I'm even more torn as to what to write, as there isn't a whole lot of interest overlap. This being the case, I'm going to ramble a bit about something that's been running through my mind since about 2 a.m. this morning that only a couple of you will understand: Concurrency in Object Oriented Design.

This is one of those entries that's going to be edited, heavily, when I come back and read it in a few days and realize how incomprehensible it all is. Keep with me for now if you care...

So, first of all, thank God that my High Performance Computing class is over. Starting to understand how to write procedural code in parallel was well worth the time and effort, but I think that bigger things are on the horizon. Primarily, I don't think that parallelization is going to be the primary route taken in writing applications to take advantage of multi-core processors.

Why do I think this? Well, mostly because I don't see anybody giving up their objects anytime soon. As much as I'm starting to appreciate functional programming, I still love Object Oriented design. It's just so much easier to perceive interactions between elements of a software system when you're dividing them up logically from the get go, that the time penalty is well worth it. The problem here is that it's difficult to parallelize an Object Oriented system because you've got such a strongly heterogeneous mixture of operations going on in any given interaction between objects. Certainly, if you're performing simulations where you have large aggregate groups of similar objects interacting with each other over either several iterations or under slightly different circumstances, you can break up this problem...but if you've got several dozen different types of Objects, all having their interaction being controlled by some central, generally procedural method, you're going to have to combine flat parallelism over looping constructs all over the place with functional decomposition of different object-set interactions with god knows what other types of algorithmic tomfoolery to "optimize" your problem.

This just doesn't seem worth it.

I've recently been doing a bit of reading on a language called Erlang. Erlang is rooted in the concept of "concurrency oriented design". Now, when most people think of concurrent operations, they think of multi-threading. When most people think of multi-threading, they think of shared memory accesses, critical sections, and notoriously instable and unreliable performance. Erlang sheds all of this.

Instead, Erlang structures programs around "processes". Not OS processes, light-weight processes managed by the Erlang RTE, each with its own unique memory and variables, all communicating with each other through asynchronous message passing. Having not done any actual programming in Erlang (a deficiency that will be rectified soon), I don't honestly understand yet how programs are structured around these processes, but I see a LOT of potential in this.

Imagine, a combination of Objects and Erlang style processes. You build an Object, and gets scheduled to run as its own process on one of the cores or nodes of your system. Each object exists as a unique process in this way, waking up and doing work on its core when requested, and sending that data back to whatever other Object requested its services, and going back to sleep. It doesn't sound a lot different from Object Oriented design as we know it, it just scales objects and their computations across a system. Obviously, we would need to write interactions between objects in a less traditionally procedural manner. "Controllers" in the traditional sense would certainly see a massive overhaul. Right now, it seems to me that Object Oriented programs are essentially procedural programs with a lot of the mess filtered out into objects and the remaining mess existing in the controller, managing their serial interaction, but any step towards truly efficient parallelization would require as much.

I've lost my train of thought for now. Maybe when I come back to make sure the above statements are actually understandable, I'll be able to remember what I wanted to say. For now, though, I'll just ask, would this concept of Objects existing and communicating concurrently, largely independent of a serialized controller be the fastest way of spreading code across multiple processing elements? No, probably not. But, if you're really looking for speed, why are you looking at O-O in the first place? I honestly can't think of anything right now that has the potential to be as easy to understand in design terms, easy to extend across and arbitrary number of processing elements (distributed or symmetric), and as potentially robust as this solution. It's something to think about and hope for in the future.