Heterogeneous System Architecture, meglio conosciuto come HSA, è un nuovo modo d'intendere i chip e la programmazione. Non più una CPU e una GPU distinte, ma sistemi che collaborano tra loro per svolgere al meglio un'attività. Se un determinato carico di lavoro ha al suo interno alcune istruzioni che girano meglio sulla CPU e altre che possono essere svolte più rapidamente dalla GPU, l'HSA è quell'infrastruttura che permette che il tutto si svolga al meglio, con il massimo dell'efficienza.
Ne parliamo perché la HSA Foundation ha fatto il punto della situazione, in previsione delle specifiche HSA che saranno completate metà 2014, ritardi permettendo. Nata nel 2012, la fondazione vede tante aziende coinvolte, tra cui AMD, Samsung, ARM e MediaTek. Tutte queste realtà tengono gruppi di lavoro che servono a definire la direzione da prendere e le specifiche dello standard. Nel campo dei computer tradizionali è AMD la massima esponente dell'HSA, e una generazione di APU dopo l'altra, lo sta facendo vedere. La caratteristica hUMA che vedremo nella futura APU Kaveri è un ottimo esempio.
La HSA Foundation però guarda anche i SoC, al mondo mobile. Non poteva essere altrimenti dato che è il mercato in maggior fermento, in cui vediamo un crescente numero di design caratterizzati da molti core, sia tradizionali - ARM, in questo caso - che grafici. Progetti di questo genere sono destinati per forza di cose a rendere CPU e GPU sempre più integrate, ma senza tutta la parte "software", a livello di librerie, API e non solo, c'è poco da fare.
HSA Foundation ci ha così parlato di HSAIL (HSA Intermediate Language), che cerca di unire mettere in comunicazione meglio GPU e CPU. Non è una API, ma è un intermediate translation language, cioè un linguaggio che fa da tramite, cosicché possa essere trasversale a diversi design. AMD, Imagination, Qualcomm e altri infatti non usano lo stesso tipo di GPU e quindi bisogna trovare un "terreno comune" che consenta a tutti di implementare l'HSA.
L'idea, per facilitare il compito agli sviluppatori, è che si possa scrivere codice in un linguaggio come C++, AMP, OpenCL, Java o Python, per poi compilarlo nel modo giusto così che giri il tutto giri senza badare alla GPU integrata nel sistema. Il vantaggio di HSAIL secondo AMD e i membri della fondazione è che non richiede ai programmatori di imparare nuovi linguaggi.
Inoltre apre alla possibilità di accelerare linguaggi come Java sulla GPU, anche se a tal proposito rimangono alcuni tasselli da mettere a punto, che saranno però applicati negli anni a venire. Si parte dalla libreria open source Aparapi, un runtime in grado di convertire bytecode Java in OpenCL e che supporta il calcolo parallelo sulle GPU o la gestione di thread sulle CPU multi-core.
Nell'immagine sopra potete vedere, da sinistra a destra, la progressione dell'integrazione di Aparapi fino ad arrivare all'obiettivo finale, che è quello d'inserire l'accelerazione eterogenea direttamente nella macchina virtuale Java, perché le caratteristiche e le funzioni principali del linguaggio Java sono naturalmente più diffuse rispetto alle librerie di terze parti.
A quel punto toccherà a Project Sumatra, un progetto di JDK sostenuto da AMD e Oracle che dovrebbe essere pronto per Java 9 nel 2015. Il futuro JDK permetterà agli sviluppatori di scrivere algoritmi per la parallelizzazione dei dati in Java ed eseguirli grazie alla GPU, in modo simile a quanto succede per la funzione Lambda di Java 8 e le CPU multi-core.