Recently Erlang is gaining a lot of popularity, probably due to the publishing of the Programming Erlang book from the Pragmatic Programmer. In this article about the Erlang future, Joe Armstrong explaing why Erlang Concurrency Oriented Programming will be much more important from now on, since we’re moving to a multi core processing era!
Nobody can predict the future, but I’m going to make a few informed guesses.
Let’s suppose Intel is right: let’s suppose that the Keifer project succeeds. If this happens, then 32 core processors will appear on the market as soon as 2009/2010.
This comes as no surprise; Sun already ships the Niagara with 8 cores running 4 hyperthreads per core (which is equivalent to 32 cores).
This is a development that makes Erlang programmers very happy. They have been waiting 20 years for this to happen, and now it’s payback time.
Here’s the good news for Erlang programmers:
Your Erlang program should just run N times faster on an N core processor
What’s all this fuss about Erlang?
Questo claim è ridicolo. E’ ben noto che lo speedup che si ottiene aumentando il numero di processori è sempre *meno* che lineare, e dipende dall’algoritmo; non certo dal linguaggio di programmazione. Ora non sarò certo io a dire che un linguaggio di programmazione tecnicamente valido, con una implementazione tecnicamente valida, non conta nulla…. anzi! Ben vengano i multi-core, e ben venga Erlang che ci permette di sfruttarli al meglio. Ma non creiamo aspettative assurde!
Matteo, sono daccordo che il claim è un po’ “sensazionalista”, però secondo me Joe indendeva dire che Erlang ti “costringe” in un certo senso a sviluppare applicazioni concorrenti in un modo tale che poi risulta facile per la VM distribuire i processi concorrenti su piu’ processori fisici. IMHO la differenza principale fra i processi Erlang e, per esempio, i thread in Java sta nel fatto che i primi possono comunicare solo tramite messaggi e non condividono dati o oggetti, al contrario dei secondi. Questo permette un maggiore isolamento fra i processi e una migliore scalabilità data dall’architettura share-nothing… ![]()
No, non sono d’accordo.
Il fatto che i processi non condividano memoria è conveniente per lo sviluppatore che è meno soggetto a race condition; ma non è direttamente legato a un maggiore speedup. Anzi, ci sono algoritmi paralleli che scalano meglio proprio quando hai la memoria condivisa. E’ molto più *veloce* modificare una variabile condivisa che non passare un messaggio.
Your program won’t run N times faster on a N core machine unless you parallelize your program and split it (carefully) up into distinct processes. If done wrong, the message passing overhead could even slow your programs down. Erlang is no silver bullet! It doesn’t help you in this decision. It only makes it much more easy and more convenient to employ concurrency.