I’ve just come across an excellent article on eWeek titled Programming Superstars Eye Parallelism where some of the brightest computer scientists ever discuss on the Next Big Thing (TM).
James Gosling, creator of Java at Sun, Anders Hejlsberg, creator of Turbo Pascal at Borland and C# at Microsoft and Bertrand Meyer, creator of Eiffel reflect on “”What will you do with a 4,000-core machine?”
Multicore processors
Most of us buying computers now have dual-core processors like the Intel Core Duo I have on my MacBook. The same company has communicated on its Tera-Scale research program and has announced that 10-cores processors will be ready in two years. Intel is even experimenting with 80-cores processors…
Sun Microsystems already sells an 8-core processor with 4 hardware threads per core = 32 threads. It is, of course, the UltraSPARC T1 (Niagara) processor. It even has a successor called T2 which has 8 hardware threads per core i.e. 64 threads…
So the future is going to be massively multi-core.
The problem
Anders Hejlsberg says that “the models we have today for concurrency don’t work. Developers need to move an abstraction level up and he sees a resurgence of functional programming and its influences.” And the others agree.
Simply said, the way we program today (with C/C++/Java/C#/whatever) does not work on massively multi-core processors. This is because of state being shared among the cores and, hence, the necessity to use synchronization mechanisms a lot. The immediate consequence is that it becomes impossible to write programs which are free from deadlocks and starvation as the number of possible interleavings is massive. Exhaustive testing is impossible.
Functional programming to save the world
Joe Armstrong, the creator of Erlang, has spoken eloquently on why functional programming languages, which can be defined as languages without variables, are much more suitable to write concurrent (and parallel) applications than imperative languages that we all use today (like C/C++/Java/C#/etc)
Basically (and I quote),
No Mutable Data Structures = No Locks = Easy to parallelize!
Incidentally, this is one of the reason I’m teaching Concurrency and Parallelism: I so deeply want functional programming to succeed!
I have been using Erlang for a month now to teach concurrent programming and, in my opinion, my students have loved it (and I too!)
Conclusion
The future is concurrent and parallel. And, according to the best, the future is also functional (very interesting things are happening in research, for example, F# and Data Parallel Haskell). Erlang is already here and is beautiful (and powerful).
I knew those hours I spent learning Scheme when I was younger were going to be useful.
I’m happy.
Just businees making with all those cores and stuff
making money out of rich gamers in my opinion
damn am starting to hate technology … it moves kind of too fast >.
Sure, “rich gamers” were the early adopters of multi-threading and multi-core processors as they regularly have to buy new computers. But don’t forget that everyone now buys multi-cores.
Therefore, the big problem that all software developers are starting to have is how to leverage this processing power. Here I am talking about games but also about multimedia-manipulating applications (like Apple’s iLife and especially iMovie) and, eventually, the operating system itself.
People have been doing research in the field of concurrency and parallelism for decades now. And, now, for the first time, everyone has access to a parallel computer including you and me!
Expect lots and lots and lots of development in parallel hardware and parallel programming for the next ten years.
Technology does not move too fast. It moves as fast as research can :-)
:p Erlang is cool :p
doesn’t mean that all other functional programming language are cool (if they are, i prefer to abstract that away :p).
Wouldn’t be bad if Erlang is as you say it soo much time “the next big thing”. (After using it, and seeing the beauty and lazyness, in coding in Erlang, i would defnitely like it if Erlang saves the world :p).
I know this post doesn’t have much to do with the main topic, but i wanted to say something after i saw the comment on gamers.
the following deals a Desktop computer i have been seeking since a child.
hell i am not much of a gamer, but i have been trying since i was kid to have a PC that would boot up and load everything in just 2 seconds and It never hangs at anything and it is truely well responsive and I get my result as soon as i click something or type a command
Its been 9 years since i am seeking this computer, and it is still not found, am almost getting desperate that i will never see such a desktop computer. Sure i learnt how to tweak this this or that, but hell, i want my super fast toy, and i am a kid who will go crazy if he doesn’t get his toy!
okie i know there is progress, but that part of me which see or worry only about the final result is pissed off :p, technology, big words, no concrete progress to satisfy my hunger yet.
damned technology.
+$3|v3n
i ended in this class my default but am glad i did :)
erlang was a nice experience and i’ll definitely have a closer look during my spare time
So many cool languages to learn…
Anyway, I was wondering: does a language/program have to be purely functional in order to have an advantage when it comes to concurrency?
In fact, being purely functional means that there is no (shared) state. Hence no need to synchronize access to (shared) state.
Erlang is great in that respect. Joe Armstrong’s arguments are pretty convincing.
On the other hand, Java and friends will stay. So it’s also interesting to understand how the Java concurrency utilities also work…