Oracle ha svelato il nuovo M7, un processore SPARC dotato di ben 32 core per un totale di 10 miliardi di transistor. Si tratta di un concentrato di potenza senza pari, che funzionerà in abbinamento a schede specifiche che IBM dovrebbe mostrare nei prossimi mesi.

Il die del nuovo M7 si compone di otto gruppi di core (cluster), ognuno composto a sua volta di quattro core SPARC. Completano il quadro 64 MB di cache L3 condivisa, capace di fornire un bandwidth aggregato che supera gli 1,6 TB al secondo.

Ogni quattro core abbiamo 256 KB di cache L2 4 way per le istruzioni, e altrettanti di cache L2 per i dati per ogni due core. Abbiamo poi 16 KB di cache L1 per le istruzioni e altrettanti per i dati, per ogni cluster di quattro core.

Il processore M7 è inoltre dotato di sette collegamenti dedicati (coerence links) che permettono di connettere otto di questi processori come se fossero uno solo. Inoltre "32 di questi chip", spiegano i portavoce dell'azienda, "si possono collegare in configurazione SMP. Potenzialmente un sistema con 32 chip avrà 1024 core, 8192 thread e 64 TB di RAM. Quanto alla frequenza di lavoro, non è ufficiale ma si è già detto che sarà superiore a 3,6 GHz.

Simon Sharwood di The Register sottolinea poi come "un'altra caratteristica rilevante è la capacità di decomprimere dati alla velocità di accesso alla memoria", che permetterà appunto di lavorare su questo tipo di dati direttamente in memoria. Un capacità che dovrebbe accelerare significativamente alcune applicazioni database.

Lo SPARC M7 avrà poi sedici canali di memoria distribuiti su quattro controller DDR4, quattro connessioni PCIe 3.0, e un raffinato sistema che legge i consumi ogni 250 nanosecondi (per ogni core) e adatta la potenza di conseguenza. L'efficienza dovrebbe quindi essere molto alta.

Per dare un senso delle proporzioni, Timothy Prickett Morgan fa notare che solo 20 anni fa un supercomputer aveva le caratteristiche e le prestazioni di questo processore. Ma è un paragone che regge solo se si guarda alla potenza bruta, perché 20 anni fa i processori non integravano meccanismi per la gestione del garbage Java, o per indirizzare allo stesso cluster i thread che condividono alcuni dati – in modo che siano fisicamente più vicini tra loro.