I just returned from an interesting full-day seminar on parallelizing applications using Intel's tool suite with the quite ambitous title "How to write bug free and performance optimized parallel (threaded ) applications ( Turning a serial into a parallel application)". A demonstration of the capabilities of Intel Parallel Studio was quite impressive.
Clever Tools
Let Parallel Studio analyze your C/C++ code to detect performance hotspots and parallelizable code fragments. Then use OpenMP and add #pragma directives to actually "annotate" your code with parallelization hints for the compiler:
#pragma omp parallel for reduction(+: sum) for (i = 0; i < 1000000; i++) { sum = CalcSum(i, sum); }
Pretty neat, isn't it? I found it quite surprising how far one can already get nowadays by just using clever tools for (semi-)automatic parallelization of applications. Still: Can you prove the above code does not cause semantic errors? Remove the "for reduction(+: sum)" from the above and you will get a random results.
Required: a radically new approach
Introducing technlogies like OpenMP (or the new .NET Parallel Programming libraries to mention a more recent one) doesn't help much to really improve the situation. It is like fixing your bathroom with duct tape. It works - but it is not a sustainable solution. In my opinion, going parallel - and thus make your code scalable, be it on multi-core or a service in the cloud - requires more than tools. Everyone, who has already written one piece of multithreaded code, also has already had to debug a concurrency issue. It doesn't matter, how good you are, how much or little experience you have.
Actors enter the future stage
What does it take to write better scalable and parallelizable code? The problem with parallel code is "shared state". Message Passing avoids this problem. The Actor Programming Model takes this even further. Systems like Erlang have a long history in successfully applying this totally different programming paradigm (at least totally different from today's mainstream only of course). Multicore processors and cloud computing revived this paradigm by increasing the need for parallel programming support. Microsoft's Axum and attempts like the "XCoordination Application Space" try to bring this paradigm to the masses on the .NET platform, Scala will likely be the next success on the Java platform (imho ironically by replacing the Java language on the JMV). I dare to predict, that lot of our programming future will be Actor-based. And the platform that makes implementing actors most convenient has good chances to become the next mainstream.
What are your thoughts on the future of programming? How will we handle challenges like debugging or orchestration of actor communication in this new world? Keen to hear your opinions and/or experiences!
3 comments:
To me, too, the actor model seems to have quite some potential to become some kind of multi-core "mainstream" programming paradigm.
Zoonon did it, Scala does it, Axum does it... and I´ll be implementing it in my next round of CCR wrappers, too: CCR Space, http://code.google.com/p/ccrspace/. Until TechEd Europe I hope to have actors in place - including transparent distribution.
So actors are cool - but I don´t want to be forced to switch to a new programming language to use them.
-Ralf
I probably don't want to learn a new language. But imho the relevant constructs must at least be part of the language in order to become mainstram.
How do you think about orchestrating the conversation flows between agents? How will debugging change in the world of agents?
@Erich: "Relevant constructs" being part of the language... well, sure that would help. Like extions methods or lambda expressions in C#.
I´m sure some such constructs will show up in C# 5.0 oder 6.0. But Axum and F# won´t gain widespread use just because of multi-core programming.
Orchestrating agents, though, is not a matter of language constructs in the first place. It´s a matter of concepts and paradigm. They can be expressed in other ways before becoming part of a language.
As for debugging: I find it overrated in general ;-) With a proper development approach you don´t need much debugging in general; and you don´t even want to start debugging multi-core code. Rather it´s a matter of instrumentation, I´d say.
-Ralf
Post a Comment