Codice compatto e software efficiente dal punto di vista energetico

All'alba dei computer, quando i chip dei microprocessori erano appena stati inventati, gli studenti di ingegneria spesso avevano il loro primo contatto con la programmazione seria su macchine come il minicomputer DEC PDP-11. Oltre a cercare di scrivere programmi che girassero correttamente sul PDP-11, gli studenti dell'epoca dovevano anche rendere il loro codice compatto. Per esasperare un docente di quei primi corsi di computer, era sufficiente presentare programmi con 20 righe di codice assembly, quando ne avrebbero potuto occupare anche solo 15. Ovviamente, la ragione della sua costernazione dipendeva dal fatto che la memoria era molto costosa. Il PDP-11 aveva normalmente una memoria di lettura/scrittura di sole 4096 parole di 16 bit, costituita da nuclei magnetici 22 mil a cui si accedeva tramite fili.

Un computer PDP-11 costruito da Digital Equipment Corporation (DEC). (Immagine per gentile concessione di flickr)

Un rapido balzo fino ai nostri giorni ci mostra che nei corsi di programmazione si sottolinea ancora l'importanza della compattezza del codice. Ma ci sono forti segnali che il requisito di codice compatto potrebbe accompagnarsi alla necessità di software che riduca al minimo il consumo di energia.

L'efficienza energetica dei codici informatici era un tempo un argomento di nicchia. Interessava soprattutto i programmatori di piccoli sistemi embedded dove la dissipazione di potenza di una MCU doveva essere contenuta per massimizzare la vita della batteria a bottone che forniva l'alimentazione. Ora, l'efficienza energetica del software sta diventando un tema di attualità generale. È sempre più comune vedere gli utenti di smartphone che evitano applicazioni che pesano molto sulla CPU solo per prolungare un po' l'autonomia della batteria. Anche i sistemi basati su cloud stanno prestando attenzione all'efficienza energetica del software a causa del relativo impatto sulle emissioni di carbonio dei data center.

Di primo acchito, si potrebbe pensare che un codice compatto sia di per sé efficiente dal punto di vista energetico. In effetti, questa regola empirica può essere vera, ma non sempre. Inoltre, l'efficienza energetica di un programma per computer dipende generalmente dal linguaggio in cui è scritto. I linguaggi compilati sono più efficienti dal punto di vista energetico dei linguaggi interpretati o di quelli su cui si basano le macchine virtuali. Ma ci possono essere grandi differenze nell'efficienza energetica anche tra linguaggi compilati che sembrano simili.

Grazie al lavoro svolto da alcuni ricercatori in Portogallo (https://dl.acm.org/doi/10.1145/3136014.3136031), è possibile approfondire come l'energia, il tempo e l'uso della memoria siano legati alla programmazione efficiente dal punto di vista energetico. Sono state analizzate le prestazioni relative all'efficienza energetica di 27 linguaggi software. Per farlo, sono stati usati compilatori, interpreti e macchine virtuali all'avanguardia. I ricercatori hanno poi esaminato cosa è successo quando hanno eseguito 13 diversi programmi usati per confrontare come algoritmi ampiamente utilizzati possono essere implementati in vari linguaggi di programmazione molto diffusi.

Ad esempio, un programma di benchmark ha misurato il tempo necessario per calcolare l'interazione tra più particelle in un sistema. Un altro ha allocato e deallocato molti alberi binari. Un terzo ha aggiornato una tabella hash e l'ha usata per contare specifiche sequenze di nucleotidi del DNA.

I ricercatori fanno notare che c'è un malinteso comune secondo cui il consumo di energia nel software è proporzionale al tempo di esecuzione, la velocità dà sempre risultati migliori. Quindi, riducendo il tempo di esecuzione di un programma, si ridurrebbe proporzionalmente il suo consumo energetico. Ma la relazione non è sempre semplice perché l'energia dissipata è il prodotto della potenza utilizzata e della durata. Quindi un programma più veloce potrebbe non essere più efficiente dal punto di vista energetico se consuma più energia durante la sua esecuzione.

Di conseguenza, i ricercatori hanno trovato diversi casi in cui il risultato relativo al consumo energetico di un linguaggio di programmazione era diverso da quello del suo tempo di esecuzione. Ad esempio, in un benchmark che coinvolge la generazione e la scrittura di sequenze casuali di DNA, Fortran è risultato essere il secondo linguaggio più efficiente dal punto di vista energetico, anche se è arrivato all'ottavo posto per il tempo di esecuzione. E quando si calcolano gli alberi binari, il consumo di energia dei linguaggi Pascal e Chapel era per entrambi in una forchetta del 10%, anche se Chapel richiede circa il 55% di tempo in meno per l'esecuzione.

Alcune delle conclusioni dei ricercatori non sono sorprendenti. Un risultato: il linguaggio C è nel complesso il più veloce e il più efficiente dal punto di vista energetico (57 J, 2019 msec in media per l'esecuzione). Dopo C, i primi quattro linguaggi che richiedono meno energia e tempo per eseguire i benchmark sono risultati essere Rust (59 J, 2103 msec), C++ (77 J, 3155 msec), Ada (98 J, 3740 msec) e Java (114 J, 3821 msec). E come ci si potrebbe aspettare, i linguaggi compilati erano molto più efficienti dal punto di vista energetico dei linguaggi interpretati o della macchina virtuale. I programmi compilati hanno consumato una media di 120 J per eseguire le soluzioni, mentre le macchine virtuali e i linguaggi interpretati hanno assorbito rispettivamente 5760 J e 2365 J.

Non sorprende, quindi, che gli ultimi cinque linguaggi per efficienza energetica e tempo di esecuzione siano stati tutti quelli interpretati: Perl (4604 J), Python (4390 J), Ruby (4045 J), JRuby (2693 J), and Lua (2660 J) per l'energia; Lua (16.7416 msec), Python (14.5178 msec), Perl (13.2856 msec), Ruby (119.832 msec) e TypeScript (93.292 msec) per il tempo.

I ricercatori hanno anche individuato dove va la maggior parte dell'energia dissipata. La CPU è sempre responsabile della maggior parte dell'energia consumata. In media, la CPU consuma quasi il 90% dell'energia e la DRAM che consuma il resto, indipendentemente dal fatto che il linguaggio sia compilato, interpretato o virtuale.

In conclusione, i ricercatori portoghesi affermano che è relativamente facile decidere il miglior linguaggio software se gli sviluppatori si preoccupano solo del tempo di esecuzione e del consumo di energia. Ma la scelta non è automatica se occorre tenere conto anche dell'uso della memoria.

Dunque, c'è una buona notizia per il pianeta: è possibile ottimizzare il software per l'efficienza energetica. Ci sono invece cattive notizie per gli studenti che imparano a programmare: possono rischiare un'occhiataccia dal docente non solo per aver consegnato un programma non sufficientemente compatto, ma anche per uno energivoro.

Informazioni su questo autore

Image of Lee Teschler

Lee Teschler is the Executive Editor of the Design World network of websites, online resources and print publications. Leland (Lee) Teschler worked at Penton Media for 37 years, starting in 1977 as a Staff Editor for Machine Design, and worked his way up to Chief Editor of the publication in 2006. Prior to that, he had been a communications engineer for the federal government. Teschler holds a B. S. in Engineering and a B. S. in Electrical Engineering from the University of Michigan, and an MBA from Cleveland State University.

More posts by Lee Teschler
 TechForum

Have questions or comments? Continue the conversation on TechForum, DigiKey's online community and technical resource.

Visit TechForum