I dati sull’uso dell’energia possono dirci qualcosa sulla qualità dei nostri linguaggi di programmazione?

L’anno scorso un team di sei ricercatori portoghesi di tre diverse università ha deciso di indagare su questa domanda, pubblicando alla fine un documento intitolato “Energy Efficiency Across Programming Languages”. Hanno eseguito le soluzioni di 10 problemi di programmazione scritti in 27 linguaggi diversi, monitorando attentamente quanta elettricità usava ciascuno di essi – così come la velocità e l’uso della memoria.

In particolare, hanno usato 10 problemi dal Computer Language Benchmarks Game, un progetto di software libero per confrontare le prestazioni che include un set standard di semplici problemi algoritmici, così come una struttura per eseguire test. (Questo ci ha permesso di ottenere un set di programmi comparabile, rappresentativo ed esteso… insieme alle opzioni di compilazione/esecuzione e alle versioni del compilatore.”

Era importante eseguire una varietà di test di benchmark perché alla fine i risultati variavano a seconda di quale test veniva eseguito. Per esempio, nel complesso il linguaggio C è risultato essere il più veloce e anche il più efficiente dal punto di vista energetico. Ma nel test di benchmark che prevedeva la scansione di un database di DNA per una particolare sequenza genetica, Rust era il più efficiente dal punto di vista energetico – mentre il C arrivava terzo.

Anche all’interno dello stesso test, il “miglior” linguaggio dipende da quale sia il vostro criterio. Per quel test C è risultato essere solo il secondo linguaggio più veloce (di nuovo, piazzandosi dietro Rust). Ma Rust è sceso di ben nove posizioni se i risultati sono stati ordinati in base all’uso della memoria. E mentre Fortran era il secondo linguaggio più efficiente dal punto di vista energetico per questo test, è anche sceso di ben sei posizioni quando i risultati sono stati ordinati in base al tempo di esecuzione.

Un linguaggio più veloce non è sempre il più efficiente dal punto di vista energetico.

I ricercatori notano che hanno “seguito rigorosamente” le linee guida del progetto CLBG sulle versioni del compilatore e i migliori flag di ottimizzazione. Il consumo di energia è stato misurato utilizzando uno strumento di Intel – il Running Average Power Limit tool – con ogni programma eseguito non solo una volta, ma 10 volte, “per ridurre l’impatto delle partenze a freddo e gli effetti della cache, e per essere in grado di analizzare la coerenza delle misure ed evitare gli outlier”. (Per questo motivo, riferiscono che “i risultati misurati sono abbastanza coerenti”). Per una maggiore coerenza, tutti i test sono stati effettuati su un desktop con Linux Ubuntu Server 16.10 (kernel versione 4.8.0-22-generica), con 16GB di RAM e una CPU Haswell Intel Core i5-4460 da 3,20GHz.

Nel loro documento, i ricercatori richiamano alcuni risultati interessanti.

“Lisp, in media, consuma 2. 27x più energia (131,34%).27x più energia (131,34J) rispetto al C, mentre impiega 2,44x più tempo per l’esecuzione (4926,99ms), e 1,92x più memoria (126,64Mb) necessaria rispetto al Pascal.”

Hanno anche confrontato i risultati dei linguaggi compilati rispetto ai linguaggi interpretati (con una categoria separata per le lingue che girano su macchine virtuali). E il documento include anche un confronto separato dei diversi paradigmi di programmazione – inclusa la programmazione funzionale e imperativa, più la programmazione orientata agli oggetti e lo scripting.

Is Faster Greener?

Il documento ha preso in esame il presupposto comune che un programma più veloce userà sempre meno energia, sottolineando che non è semplice come la legge della fisica che dice E(nergy) = T(ime) x P(ower). Questo è in parte perché l’energia non viene consumata ad un tasso costante, i ricercatori notano, suggerendo che può avere un impatto sul lavoro di altri ricercatori che indagano se il tempo di esecuzione di un programma influenza il suo consumo energetico. (“Le conclusioni su questo problema divergono a volte…”) In uno dei loro test di riferimento, un programma Chapel ha impiegato il 55 per cento di tempo in meno per essere eseguito rispetto a un programma equivalente scritto in Pascal – e tuttavia quel programma Pascal ha usato il 10 per cento di energia in meno.

Così, mentre c’è ancora una credenza comune che il consumo di energia scende quando i programmi vengono eseguiti più velocemente, i ricercatori affermano inequivocabilmente che “un linguaggio più veloce non è sempre il più efficiente dal punto di vista energetico.”

Può essere una domanda difficile a cui rispondere, poiché il consumo di energia è influenzato da molti fattori (compresa la qualità del compilatore e quali librerie vengono utilizzate). Ma alla fine i ricercatori sono stati anche in grado di suddividere il consumo di energia in base al fatto che fosse consumato dalla CPU o dalla DRAM – concludendo che la maggior parte della potenza (circa l’88%) è stata consumata dalla CPU, in media, sia che il programma di riferimento fosse compilato, interpretato o eseguito su una macchina virtuale.

Interessante, i linguaggi interpretati hanno mostrato una variazione leggermente superiore, con la CPU che a volte consumava fino al 92.90 per cento della potenza o solo l’81,57 per cento.

Dopo aver studiato i loro risultati, i ricercatori hanno anche concluso che la relazione tra l’uso di picco della DRAM e il consumo di energia “è quasi inesistente”.”

La ricerca fornisce alcuni approfondimenti sulla domanda perenne: più veloce è più verde? Sì, è vero che “i primi cinque linguaggi più efficienti dal punto di vista energetico mantengono la loro posizione quando vengono ordinati in base al tempo di esecuzione e con differenze molto piccole sia nei valori di energia che di tempo.”

In effetti, per nove problemi di benchmark su 10, il punteggio massimo (sia per la velocità che per l’efficienza energetica) è venuto da uno dei primi tre linguaggi più veloci e più efficienti dal punto di vista energetico – il che non ha sorpreso i ricercatori. “È risaputo che questi tre linguaggi principali (C, C++ e Rust) sono noti per essere pesantemente ottimizzati ed efficienti per le prestazioni di esecuzione, come dimostrano anche i nostri dati.”

Ma non si vede lo stesso ordine quando si classificano gli altri 24 linguaggi in base al loro tempo di esecuzione come si fa quando si classifica per l’efficienza energetica. “Solo quattro lingue mantengono lo stesso rango di energia e tempo (OCaml, Haskel, Racket e Python), mentre le altre sono completamente mescolate.”

E anche nei singoli test di benchmark, ci sono casi in cui le lingue con prestazioni veloci non sono le più efficienti dal punto di vista energetico.

I pro delle lingue compilate

Ci sono stati altri risultati interessanti. I linguaggi compilati “tendono ad essere” i più efficienti dal punto di vista energetico e più veloci – e il loro documento può anche quantificare questa differenza con un numero. “In media, i linguaggi compilati hanno consumato 120J per eseguire le soluzioni, mentre per una macchina virtuale e i linguaggi interpretati questo valore era 576J e 2365J, rispettivamente.”

I ricercatori hanno anche applicato la stessa precisione quando hanno confrontato i tempi di esecuzione, concludendo che in media, “i linguaggi compilati hanno preso 5103ms, i linguaggi della macchina virtuale hanno preso 20623ms, e i linguaggi interpretati hanno preso 87614ms.”

Delle prime cinque lingue in entrambe le categorie, quattro di esse erano compilate. (L’eccezione? Java.)

	Energia consumata	Run-tempo
C	57J	2019 ms
Rust	59J	2103 ms
C++	77J	3155 ms
Ada	98J	3740 ms
Java	114J	3821 ms

I cinque linguaggi più lenti erano tutti interpretati: Lua, Python, Perl, Ruby e Typescript. E anche i cinque linguaggi che consumavano più energia erano interpretati: Perl, Python, Ruby, JRuby e Lua.

Ma allo stesso tempo, quando si manipolano le stringhe con le espressioni regolari, tre dei cinque linguaggi più efficienti dal punto di vista energetico risultano essere linguaggi interpretati (TypeScript, JavaScript e PHP), “anche se tendono a non essere molto efficienti dal punto di vista energetico in altri scenari.”

I linguaggi compilati hanno anche occupato i primi cinque posti per la minore quantità di spazio di memoria utilizzata.

Lingua	Spazio di memoria necessario
Pascal	66Mb
Go	69Mb
C	77Mb
Fortran	82Mb
C++	88Mb

“In media, i linguaggi compilati avevano bisogno di 125Mb, i linguaggi per macchine virtuali avevano bisogno di 285Mb, e gli interpretati avevano bisogno di 426Mb”, riferiscono i ricercatori. Nel frattempo, i linguaggi interpretati hanno rivendicato quattro dei cinque posti in basso, il che significa che hanno consumato il maggior spazio di memoria: JRuby, Dart, Lua e Perl. (Mentre Erlang non è un linguaggio interpretato, apparirebbe anche lui negli ultimi cinque, tra Dart e Lua).

“Se ordinati per il loro paradigma di programmazione, i linguaggi imperativi avevano bisogno di 116Mb, gli orientati agli oggetti 249Mb, i funzionali 251Mb, e infine lo scripting aveva bisogno di 421Mb.”

In effetti, quando si confrontano i diversi paradigmi, la programmazione imperativa è spesso in cima. I suoi programmi di riferimento hanno anche usato in media molta meno energia – e sono stati eseguiti molto più velocemente – rispetto ai programmi di riferimento per i paradigmi orientati agli oggetti, funzionali e di scripting.

	Energia consumata	Tempo di esecuzione
Imperativo	125J	5585ms
Object-Oriented	879J	32965ms
Functional	1367J	42740ms
Scripting	2320J	88322 ms

Ma ci sono molti fattori da considerare. “È chiaro che diversi paradigmi di programmazione e persino linguaggi all’interno dello stesso paradigma hanno un impatto completamente diverso sul consumo di energia, sul tempo e sulla memoria”, scrivono i ricercatori. Eppure, quale di questi è più importante dipenderà dal vostro scenario. (I compiti in background, per esempio, non hanno sempre bisogno del tempo di esecuzione più veloce..)

E alcune applicazioni richiedono la considerazione di due fattori – per esempio, il consumo di energia e il tempo di esecuzione. In questo caso, “C è la soluzione migliore, poiché è dominante in entrambi i singoli obiettivi”, scrivono i ricercatori. Se stai cercando di risparmiare tempo mentre usi meno memoria, C, Pascal e Go “sono equivalenti” – e lo stesso è vero se stai guardando tutte e tre le variabili (tempo, uso di energia e uso di memoria). Ma se si sta solo cercando di risparmiare energia usando meno memoria, le scelte migliori sono C o Pascal.

Alla fine del documento, i ricercatori aggiungono che per ulteriori studi, vorrebbero esaminare se l’uso totale della memoria nel tempo è meglio correlato all’energia consumata.

Stanno condividendo i loro dati online, suggerendo che rende più facile per i futuri ricercatori confrontare, per esempio, i linguaggi .NET o i linguaggi JVM. Per gli sviluppatori che lavorano con applicazioni mobili, sistemi Internet-of-Things, o altre applicazioni che attingono ad alimentazioni limitate, il consumo di energia è una preoccupazione importante.

Ma alla fine, lo studio potrebbe anche lasciare i programmatori con la cosa che odiano di più: l’ambiguità. I ricercatori riferiscono che se si sta cercando un unico miglior linguaggio di programmazione, “questa domanda non ha una risposta concreta e definitiva.

“Anche se il linguaggio più efficiente dal punto di vista energetico in ogni benchmark è quasi sempre il più veloce, il fatto è che non esiste un linguaggio che sia costantemente migliore degli altri”, concludono i ricercatori. “La situazione in cui un linguaggio sta per essere utilizzato è un aspetto fondamentale per determinare se quel linguaggio è l’opzione più efficiente dal punto di vista energetico.”

.