manTicore
Marco segnala in questo post l'apertura di uno spazio sul portale MSDN dedicato al parallel computing.
Leggendo al volo la home mi ha colpito un termine: ManyCore Shift.
Che di per sè non ha nulla di particolare come nome, se non la somiglianza con Manticore. Con la T in mezzo.
Le cose, come vedremo, si riuniscono in un punto comune (l'argomento, che è gestione della concorrenza) divergendo però in partenza in maniera netta, a partire proprio dall'etimologia del nome.
Manycore: Many = Molti, Core = ... core :-)
Manticore ha invece un'origine ben più antica: il manticore è una creatura dal corpo di leone e dalla testa d'uomo, ferocissima e leggendariamente abitante le foreste dell'Asia (al solito, WikiPedia). Eccone una rappresentazione:
Cosa c'entra con il parallel computing ?
Nulla, al di là del fatto che Manticore è il nome scelto per un progetto (portato avanti dall'università di Chicago) volto alla definizione di un linguaggio di programmazione.
Nuovo membro della numerosa famiglia discendente da ML, Manticore propone la concorrenza come requisito chiave per lo sviluppo di sistemi in grado di sfruttare le nuove architetture hardware.
Non è questa la sua pecualirità (giacchè l'obiettivo sembra condiviso da più parti), quanto il fatto che il supporto alla concorrenza sia fornito a diversi livelli di astrazione.
Si va da un supporto "gratuito" da parte del runtime (che genera codice intrinsecamente eseguibile-eseguito su thread differenti) all'esposizione di keyword e costrutti sintattici capaci di influenzare questi comportamenti (compiler hints).
Di più, viene fornito un meccanismo di gestione esplicita dei thread basato su message passing.
[Message Passing. Merita discorso a parte. In 2 parole, la comunicazione di dati fra thread avviene senza condivisione di stato (shared data) al fine di eliminare la necessità di lock mantenendo, tuttavia, l'integrità delle informazioni (n.b.: lock = il peggior nemico della scalabilità sui multicore)]
Alcuni punti di contatto con ParallelFX, di fatto, emergono.
Partendo dagli "hint" al compilatore ed al runtime (Parallel.For, AsParallel di PLINQ...).
Ed arrivando alla gestione esplicita dei thread con un approccio più funzionale possibile. Cosa evidentemente naturale in linguaggi ML-based, e direzione attuale nell'evoluzione di un linguaggio imperativo come C#.
Insomma, il fermento è parecchio.
Da un lato i linguaggi e le piattaforme "mainstream" devono evolversi per non avere di fronte un limite di scalabilità insormontabile.
Però dall'altra parte linguaggi ed approcci "di nicchia" devono trovare il modo per offrire il supporto e l'utilizzabilità che, di fatto, credo ancora non abbiano.
Interessante è, però, notare come proveniendo da lati diametralmente opposti si giunga a punti di incontro.
Rimanendo nel mondo .NET, secondo me un punto chiave sarà l'influenza che F# potrà avere sull'architettura interna del runtime. In altri termini, staremo a vedere che succede quando (e se) quelle che sono, attualmente, feature del linguaggio saranno integrate a livello di VM.