E se vi dicessi che gran parte della potenza di calcolo che usiamo oggi viene sprecata in ‘trucchetti’ che non riusciamo nemmeno a vedere? In un’epoca in cui le GPU e le NPU sono diventate scatole nere impenetrabili, dove il software lancia comandi e spera che lo scheduler faccia il suo lavoro, spunta fuori un progetto che urla ‘trasparenza’ a squarciagola: OpenTPU.

Immaginate un mondo senza le solite astrazioni che rendono il debugging un incubo. OpenTPU non è il solito acceleratore che cerca di nasconderti la complessità sotto un tappeto di cache intelligenti e predittori di salto. Qui la filosofia è radicale: non c’è cache, non c’è scheduling nascosto. Ogni singolo spostamento di dati dalla DRAM ai registri è un’istruzione esplicita. Se un kernel è lento, non puoi dare la colpa a un ‘algoritmo di gestione della memoria’ che ha deciso di fare i capricci; sai esattamente quale istruzione sta mangiando i tuoi cicli di clock.

Il cuore del progetto è una combinazione geniale tra Python e SystemVerilog. Hai un linguaggio ad alto livello che sembra quasi uno script di PyTorch, ma che viene compilato in un set di istruzioni (ISA) ultra-semplice, composto da 8 parole a 32 bit. La cosa incredibile è che il simulatore e l’hardware reale (basato su una FPGA Kintex-7) sono speculari. Questo significa che quello che vedi girare sul tuo laptop è esattamente ciò che accade sulla scheda fisica.

E poi c’è ‘Lens’, il profiler. Invece di darti grafici astratti e poco chiari, Lens ti permette di riavvolgere il tempo e vedere esattamente cosa sta facendo ogni singola unità (la matrice, il vettore, il quantizzatore) in ogni singolo ciclo. È come avere una telecamera a rallentatore dentro i transistor.

Certo, non è una soluzione magica per far girare i modelli da mille miliardi di parametri sul vostro smartphone. È un progetto di nicchia, estremamente tecnico, che punta tutto sull’efficienza del calcolo ‘decoder-bound’ e sulla visibilità totale. Ma per chi si occupa di design hardware o di ottimizzazione estrema dei kernel, è una boccata d’ossigeno. In un panorama dove spesso siamo costretti ad accettare le decisioni dei grandi vendor senza poter mettere piede sotto il cofano, vedere un’architettura così nuda e cruda è un promemoria di quanto sia bello quando si può ancora controllare ogni singolo bit.

In breve: OpenTPU non cerca di superare Nvidia in forza bruta, ma cerca di superare la confusione moderna con la precisione chirurgica.

Source: OpenTPU – An open-source AI accelerator, developed by AI

Immaginate di aprire un’immagine su una connessione lenta e, invece di vedere un quadratone sgranato che gradualmente prende forma, di trovarvi davanti un intero video che scorre fluido, come se fosse un GIF, ma tutto dentro un singolo file .jpg. No, non è un glitch della Matrix e non avete esagerato con il caffè.

Recentemente è emersa una chicca tecnica che sta facendo impazzire i veri amanti del bit-manipulation. Il concetto alla base è sfruttare una caratteristica (spesso ignorata) dei JPEG progressivi. Normalmente, quando scaricate un JPEG progressivo, il browser vi mostra prima le componenti a bassa frequenza (quelle che danno l’idea generale) per poi aggiungere dettagli man mano che arrivano i dati. È un trick geniale per non far sembrare la navigazione un incubazione di un virus degli anni ’90.

L’idea folle dello sviluppatore è stata quella di usare questa caratteristica per il puro, sano trolling. Invece di usare le scansioni successive per migliorare la qualità della stessa immagine, perché non usarle per sovrascrivere i dati con immagini diverse? In pratica, concatenando più scansioni e manipolando i marker (quei famosi byte che dicono al decoder ‘ehi, qui inizia un nuovo pezzo’), si può creare un file che cambia immagine man mano che viene scaricato.

Il problema? I browser moderni non sono esattamente degli alleati della libertà creativa. Per evitare quello che sembra un attacco ‘zip bomb’ (un file che esplode in memoria saturando tutto), i decoder tipo Chrome o Firefox hanno un limite di scansioni che possono gestire prima di dire ‘basta, mi sono stancato’. Se superi una certa soglia, il rendering si interrompe. Per aggirare questo limite, l’autore ha dovuto fare un lavoro di precisione chirurgica, creando scansioni ‘DC-only’ che sono tecnicamente conformi allo standard ma che servono solo a iniettare nuovi frame senza creare artefatti fastidiosi.

Il risultato è una sorta di video ‘low-fi’ che dipende interamente dalla velocità della rete. Se la rete è lenta, il video va a scatti; se è veloce, è più fluido. Non ha alcuna utilità pratica (a parte far svoltare una serata tra amici nerd), ma è un promemoria magnifico di come, finché abbiamo accesso ai bit e ai byte, possiamo ancora trovare modi per scardinare le regole di un formato che pensavamo fosse ormai sepolto sotto strati di WebP e AVIF.

È pura ingegneria del caos. Ed è esattamente il tipo di follia che rende la tecnologia interessante, lontano dagli aggiornamenti noiosi e preconfezionati che ci vengono sbattuti in faccia ogni giorno dalle Big Tech.

Source: Regressive JPEGs

Quanto può durare un progetto software prima di diventare una leggenda metropolitana o un reperto archeologico? Se segui lo sviluppo della JVM, sai che Project Valhalla è stato per anni quel vago ricordo di qualcosa che ‘si diceva che sarebbe arrivato’. Beh, finalmente il Ragnarok è arrivato, ma non in modo apocalittato come sperato: Valhalla è ufficialmente parte del JDK 28.

Per chi non mastica bytecode a colazione, non lasciatevi spaventare dal nome norreno. In soldoni, Valhalla è l’operazione chirurgica per risolvere uno dei problemi storici della Java Virtual Machine: l’inefficienza della gestione degli oggetti. Fino ad oggi, la gestione della memoria in Java è stata un po’ come cercare di organizzare una libreria in un ufficio dove ogni libro è avvolto in una bolla di plastica gigante. Ogni oggetto è un’entità separata, con il suo overhead, sparpagliata nella heap, che costringe la CPU a fare jogging tra un indirizzo e l’altro. Un incubo per la cache L1 e L2 che farebbe piangere anche il più esperto degli ingegneri hardware.

Con l’arrivo di Valhalla, introduciamo i ‘value objects’. L’idea è quella di poter trattare i dati come semplici valori (tipo un int o un float), eliminando l’indirezione inutile e permettendo alla JVM di impacchettare le informazioni in modo contiguo nella memoria. È una manovra che trasforma il codice da un labirinto di puntatori a una struttura lineare, efficiente, che la CPU può leggere a velocità folle. In pratica, stiamo dando alla JVM le capacità di gestione della memoria che abbiamo sempre invidiato ai linguaggi più ‘low-level’.

Però, restiamo con i piedi per terra. Non è che domani mattina tutto il vostro legacy code andrà a mille all’ora come se aveste installato un modulo turbo. La notizia è ‘nuanced’, come dicono quelli che vogliono evitare di esporsi troppo. Il cambiamento è profondo e, come ogni grande riforma strutturale, porta con sé dei compromessi. Non è una bacchetta magica che risolve i bug di architettura, è uno strumento nuovo che richiede un nuovo modo di pensare alla modellazione dei dati.

Non è esattamente una notizia che cambierà la vita di chi sviluppa app web per il mercato locale o gestisce piccoli server in un garage in periferia, ma per chi scrive infrastrutture critiche, sistemi ad alta performance o motori di calcolo, questo è il momento di rimettersi al lavoro. La sfida non è più solo ‘far girare il codice’, ma farlo girare con la precisione di un orologio svizzero, senza sprecare ogni singolo ciclo di clock in indirection inutili.

Quindi, preparate i debugger e tenete pronti i test di benchmark. Il decennio di attesa è finito, e ora inizia il divertimento vero: capire se riusciremo a sfruttare questo nuovo potere senza mandare in crash l’intero ecosistema.

Source: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

Immagina di poter scrivere codice C su un computer degli anni ’80 senza nemmeno un byte di spazio extra. Pazzesco? Eppure, è esattamente ciò che ha realizzato SectorC, un compilatore C che entra in un singolo settore di disco (512 byte) e funziona su un IBM PC originale.

La storia di SectorC è un inno alla semplicità estrema. Creata da xorvoid, questa piccola meraviglia dimostra che, con un po’ di creatività, si possono ottenere risultati straordinari con risorse minimali. Ma come funziona? E soprattutto, perché qualcuno dovrebbe volerlo fare?

SectorC non è solo un esperimento tecnico: è una dichiarazione di principio. In un’epoca in cui i compilatori pesano gigabyte e richiedono interi server per funzionare, questo progetto ci ricorda che il vero potere del software sta nella sua capacità di fare molto con poco. E per noi smanettoni, è un invito a sperimentare, a rompere gli schemi e a trovare soluzioni creative anche nelle situazioni più impossibili.

Ma attenzione: non è tutto rose e fiori. SectorC è un progetto ad alto rischio di frustrazione. Senza error handling degno di questo nome, la compilazione è un viaggio nel caos in cui ogni bug è una sorpresa. Eppure, proprio questa mancanza di protezioni lo rende affascinante: è come guidare una macchina senza airbag, dove ogni errore è una lezione imparata a caro prezzo.

Per chi ama mettersi alla prova, SectorC offre un’opportunità unica: scrivere codice C che funziona su hardware vintage, esplorare le potenzialità dell’assembler inline e persino creare animazioni VGA o suonerie con il PC Speaker. Insomma, è un gioco per puristi, ma un gioco che insegna più di molti tutorial moderni.

In conclusione, SectorC è un progetto che sfida le convenzioni e ci ricorda che, a volte, il meglio si ottiene con il meno. Se sei uno smanettone, buttati: prova a compilare un programma con SectorC e scopri quanto puoi spingerti oltre.

Source: SectorC: A C Compiler in 512 bytes (2023)