Wednesday, July 2, 2008
Why are dynamic languages so...static?
<Rant>
I'm frustrated by the glacial pace of evolution we see in the dynamic language space, specifically in the area of parallelism. This article on Ars Technica echoes what many of us have long suspected: the future is massively parallel. It was so obvious to me that the way to write parallel programs was not to deliberately assign certain types of tasks to certain cores that I was genuinely surprised at how wide-spread the practice was. We need to start expressing programs in such a way that they can be scaled to as many cores as there are available without developers having to manage the process. When you are dealing with 16, 32, 100+ cores it's no longer about making efficient parallelism easier. It about making it possible. Nobody's that good and if they tell you so they're lying.
There is no silver bullet and there are many tasks that just can't be done in parallel. However the key to democratizing parallel programming is to give developers a clean way to express algorithms as stateless programs (read: functional programming), and give them access to their language's parse tree.
Languages like LISP, ML, C#, VB.NET, and Perl 6 (if it is every released) expose the syntax tree to the developer allowing them to leverage the most important idea in computer science. Libraries can analyze this parse tree and rewrite it to run efficiently in a variety of different hardware scenarios.
Given that the multi-core future is bearing down on us it's only natural to assume that the various popular programming languages would be scrambling to add the necessary idioms to support parallelism.
Not so much.
Ruby's got some functional programming constructs, but no way of getting at the AST. Python was just redesigned from the ground up and there was a grand total of zero language features added to support parallelism. Javascript was just moved to 2.0 and is similarly lacking.
What's so criminal about this omission is that it is so easy to rectify. When you call "eval" an AST is created somewhere. It's simply a matter of exposing it before converting it into executable code.
I just wrote a rudimentary chess AI in C# 3.0. I achieved just short of 4x speed increase on my quad-core simply by adding a single line of code and referencing the new ParallelFX CTP. I challenge anyone to achive a similar level of code clarity and performance with the dynamic languages en vogue today.
</Rant>
Subscribe to:
Post Comments (Atom)
About Me
- Jafar Husain
- I'm a software developer who started programming at age 16 and never saw any reason to stop. I'm working on the Presentation Platform Controls team at Microsoft. My primary interests are functional programming, and Rich Internet Applications.
7 comments:
Unfortunately, there is no guarantee that clses will be in Java 7. It is all just speculation right now.
You need to distinguish between runtime and compile-time access to the AST. The idea behind Lisp is runtime access, but that means manipulating it using the base language itself - which is undecidable. It gives you a lot of leeway to auto-rewrite your program _yourself_ to make use of parallel hardware, but at the same time it takes away your compiler's ability to reason about your program to the same end. My guess is that's eventually going to be a nett loss, but the trade-offs are far from understood as yet.
Perl 6 will support parallel a bit. Junctions, threads, ... at least more than Perl 5.
Python 2.6 will introduce the "multiprocessing" module to aid parallelism in Python programs.
Lots of people want to get rid of the GIL, but it just isn't that easy. There are all sorts of considerations that need to be taken into account.
As you may have read, a fair while ago a couple of developers tried to remove the GIL by replacing it with fine-grained locking during DECREF/INCREF operations. This proved to have a huge impact on the performance of the interpreter.
From what I can understand (and I'm no expert - I might be entirely wrong), the only way to do away with the GIL entirely would be to bite the bullet and go with a full-blown GC implementation rather than the current ref-counted GC. That too will have its own special set of challenges: virtually all third party C-based extensions would need to be reworked and the pseudo-predictability of refcounts would be no more, to name but a few problems that spring to mind.
Ruby is headed in the GIL direction as well as of 1.9 (or at least it was last I heard). For now, we're unfortunately stuck with it. That is, until somebody knowledgeable enough with time and energy to burn steps up to the plate. Even then, it may work out to be unfeasible -- the devil is always in the details. :)
In Smalltalk has runtime access to the AST as well. Compiler and decompiler an an integral part of the language, and thus one can decompile any method or closure and do all the fancy stuff.
Alas, Squeak, the major open source Smalltalk does not support multicores (yet).
I smell some arrogance in your post.
I won't discuss if, for you, the idea of "clean way" is to access the language's AST. But at least you should realize that the guys dealing with the libraries that allow you to write ".asParalell" are dealing with a complex job.
But when I read your challenge I was only able to say: WTF?!.
First you don't show your big one line improvement. Is it the parallel for loop? But second and more important: You should challenge yourself to do it!
I challenge you to show US your claims.
Being more constructive. And using the example of the parallel for loop. I don't see the problem of building a library with functions to execute parallel tasks using "delegates".
Also having to change your code, you're not using the true power of AST manipulation. But what about an attribute for that for loop: "hey do this in parallel". You don't have to change the code you write, you just add a note to run that code branch in parallel.
Anyway, this doesn't eliminate hard work of analyzing and preparing algorithms that are easy to run in parallel. Do you know any tool to help on that? For now I'm using BrainPaper&Pencil.
情趣用品|情趣用品|情趣用品|情趣|情趣用品|情趣
Post a Comment