Pot să ne spună ceva despre calitatea limbajelor noastre de programare datele privind consumul de energie?

Anul trecut, o echipă de șase cercetători din Portugalia, de la trei universități diferite, a decis să investigheze această întrebare, publicând în cele din urmă o lucrare intitulată „Energy Efficiency Across Programming Languages”. Aceștia au rulat soluțiile a 10 probleme de programare scrise în 27 de limbaje diferite, în timp ce monitorizau cu atenție câtă energie electrică folosea fiecare dintre ele – precum și viteza și utilizarea memoriei.

În mod specific, ei au folosit 10 probleme din Computer Language Benchmarks Game, un proiect de software gratuit pentru compararea performanțelor care include un set standard de probleme algoritmice simple, precum și un cadru pentru rularea testelor. (A fost cunoscut anterior sub numele de „The Great Computer Language Shootout.”) „Acest lucru ne-a permis să obținem un set comparabil, reprezentativ și extins de programe… împreună cu opțiunile de compilare/execuție și versiunile compilatorului.”

A fost important să se ruleze o varietate de teste de referință, deoarece, în cele din urmă, rezultatele lor variau în funcție de testul efectuat. De exemplu, în general, limbajul C s-a dovedit a fi cel mai rapid și, de asemenea, cel mai eficient din punct de vedere energetic. Dar în testul de referință care a implicat scanarea unei baze de date ADN pentru o anumită secvență genetică, Rust a fost cel mai eficient din punct de vedere energetic – în timp ce C s-a clasat pe locul al treilea.

Dar chiar și în cadrul aceluiași test, „cel mai bun” limbaj depinde de criteriul pe care îl folosiți. Pentru acel test, C s-a dovedit a fi, de asemenea, doar al doilea cel mai rapid limbaj (din nou, plasându-se după Rust). Dar Rust a coborât cu nouă poziții dacă rezultatele au fost sortate în funcție de utilizarea memoriei. Și în timp ce Fortran a fost al doilea cel mai eficient limbaj din punct de vedere energetic pentru acest test, acesta a pierdut, de asemenea, șase poziții atunci când rezultatele au fost în schimb ordonate în funcție de timpul de execuție.

Un limbaj mai rapid nu este întotdeauna cel mai eficient din punct de vedere energetic.

Cercetătorii notează că au „urmat cu strictețe” liniile directoare ale proiectului CLBG cu privire la versiunile de compilator și la cele mai bune indicatori de optimizare. Consumul de energie a fost măsurat cu ajutorul unui instrument de la Intel – instrumentul Running Average Power Limit – fiecare program fiind executat nu doar o singură dată, ci de 10 ori, „pentru a reduce impactul pornirilor la rece și al efectelor cache-ului și pentru a putea analiza consistența măsurătorilor și pentru a evita valorile aberante”. (Din acest motiv, ei raportează că „rezultatele măsurate sunt destul de consistente”). Pentru un plus de consistență, toate testele au fost efectuate pe un desktop care rulează Linux Ubuntu Server 16.10 (versiunea de kernel 4.8.0-22-generic), cu 16GB de memorie RAM și un procesor Haswell Intel Core i5-4460 la 3,20GHz.

În lucrarea lor, cercetătorii scot în evidență câteva rezultate interesante.

„Lisp, în medie, consumă 2.27x mai multă energie (131,34J) decât C, în timp ce are nevoie de 2,44x mai mult timp pentru a se executa (4926,99ms) și de 1,92x mai multă memorie (126,64Mb) necesară în comparație cu Pascal.”

Ei au comparat, de asemenea, rezultatele de la limbajele compilate față de cele interpretate (cu o categorie separată pentru limbajele care rulează pe mașini virtuale). Iar lucrarea include, de asemenea, o comparație separată a diferitelor paradigme de programare – incluzând atât programarea funcțională și imperativă, cât și programarea orientată pe obiecte și scripting.

Este mai rapid mai ecologic?

Lucrarea a analizat cu atenție presupunerea comună că un program mai rapid va folosi întotdeauna mai puțină energie, subliniind că nu este la fel de simplu ca legea fizicii care spune că E(nergie) = T(timp) x P(energie). Acest lucru se datorează în parte faptului că energia nu este consumată într-un ritm constant, notează cercetătorii, sugerând că acest lucru ar putea avea un impact asupra activității altor cercetători care investighează dacă timpul de execuție al unui program afectează consumul de energie al acestuia. („Concluziile cu privire la această problemă sunt uneori divergente…”) Într-unul dintre testele lor de referință, un program Chapel a avut nevoie de cu 55% mai puțin timp pentru a fi executat decât un program echivalent scris în Pascal – și totuși acel program Pascal a folosit cu 10% mai puțină energie.

Așa că, deși există încă o credință comună conform căreia consumul de energie scade atunci când programele rulează mai repede, cercetătorii afirmă fără echivoc că „un limbaj mai rapid nu este întotdeauna cel mai eficient din punct de vedere energetic.”

Poate fi o întrebare la care este greu de răspuns, deoarece consumul de energie este afectat de mulți factori (inclusiv calitatea compilatorului și ce biblioteci sunt folosite). Dar, în cele din urmă, cercetătorii au reușit chiar să defalce consumul de energie în funcție de faptul dacă era consumată de CPU sau de DRAM – concluzionând că majoritatea energiei (aproximativ 88%) era consumată de CPU, în medie, indiferent dacă programul de referință era compilat, interpretat sau rulat pe o mașină virtuală.

În mod interesant, limbajele interpretate au prezentat o variație ușor mai mare, CPU consumând uneori până la 92%.90 la sută din energie sau la fel de puțin ca 81,57 la sută.

După ce și-au studiat rezultatele, cercetătorii au concluzionat, de asemenea, că relația dintre utilizarea de vârf a DRAM și consumul de energie „este aproape inexistentă.”

Cercetarea oferă mai multe informații despre veșnica întrebare: este mai rapid mai verde? Da, este adevărat că „primele cinci cele mai eficiente limbaje din punct de vedere energetic își păstrează locul atunci când sunt ordonate în funcție de timpul de execuție și cu diferențe foarte mici atât în ceea ce privește valorile de energie, cât și în ceea ce privește timpul.”

De fapt, pentru nouă din 10 probleme de referință, cel mai bun scor (atât pentru viteză, cât și pentru eficiență energetică) a provenit de la unul dintre primele trei cele mai rapide și mai eficiente limbaje din punct de vedere energetic în general – ceea ce nu i-a surprins pe cercetători. „Este cunoscut faptul că aceste trei limbaje de top (C, C++ și Rust) sunt cunoscute ca fiind puternic optimizate și eficiente în ceea ce privește performanța de execuție, așa cum arată și datele noastre.”

Dar nu vedeți aceeași ordine atunci când clasificați celelalte 24 de limbaje în funcție de timpul de execuție ca atunci când le clasificați în funcție de eficiența energetică. „Doar patru limbaje păstrează același rang în ceea ce privește energia și timpul de execuție (OCaml, Haskel, Racket și Python), în timp ce restul sunt complet amestecate.”

Și chiar și în cazul testelor de referință individuale, există cazuri în care limbajele cu performanțe rapide nu sunt cele mai eficiente din punct de vedere energetic.

Profilul limbajelor compilate

Au existat și alte rezultate interesante. Limbajele compilate „tind să fie” cele mai eficiente din punct de vedere energetic și cele care rulează cel mai rapid – iar lucrarea lor poate chiar să cuantifice această diferență cu un număr. „În medie, limbajele compilate au consumat 120J pentru a executa soluțiile, în timp ce pentru o mașină virtuală și limbajele interpretate această valoare a fost de 576J și, respectiv, 2365J.”

Cercetătorii au aplicat aceeași precizie și atunci când au comparat timpii de execuție, concluzionând că, în medie, „limbajele compilate au avut nevoie de 5103ms, limbajele pentru mașini virtuale au avut nevoie de 20623ms, iar limbajele interpretate au avut nevoie de 87614ms.”

Dintre primele cinci limbaje din ambele categorii, patru dintre ele au fost compilate. (Excepția? Java.)

.

	Energie consumată	Run-time
C	57J	2019 ms
Rust	59J	2103 ms
C++	77J	3155 ms
Ada	98J	3740 ms
Java	114J	3821 ms

Cele mai lente cinci limbaje au fost toate interpretate: Lua, Python, Perl, Perl, Ruby și Typescript. Iar cele cinci limbaje care au consumat cea mai multă energie au fost, de asemenea, interpretate: Perl, Python, Ruby, JRuby și Lua.

Dar, în același timp, atunci când se manipulează șiruri de caractere cu expresii regulate, trei dintre cele cinci limbaje cele mai eficiente din punct de vedere energetic se dovedesc a fi limbaje interpretate (TypeScript, JavaScript și PHP), „deși tind să nu fie foarte eficiente din punct de vedere energetic în alte scenarii.”

Limbajele compilate au ocupat, de asemenea, primele cinci locuri pentru cea mai mică cantitate de spațiu de memorie utilizat.

.

Limbajul	Spațiu de memorie necesar
Pascal	66Mb
Go	69Mb
C	77Mb
Fortran	82Mb
C++	88Mb

„În medie, limbajele compilate au avut nevoie de 125Mb, limbajele pentru mașini virtuale au avut nevoie de 285Mb, iar cele interpretate au avut nevoie de 426Mb”, raportează cercetătorii. Între timp, limbajele interpretate au ocupat patru din cele cinci locuri de jos, ceea ce înseamnă că au consumat cel mai mult spațiu de memorie: JRuby, Dart, Lua și Perl. (Deși Erlang nu este un limbaj interpretat, acesta ar apărea, de asemenea, în ultimele cinci, între Dart și Lua).

„Dacă sunt sortate după paradigma lor de programare, limbajele imperative au avut nevoie de 116Mb, cele orientate pe obiecte de 249Mb, cele funcționale de 251Mb și, în cele din urmă, cele de scripting au avut nevoie de 421Mb.”

De fapt, atunci când se compară diferitele paradigme, programarea imperativă a ieșit deseori pe primul loc. De asemenea, programele sale de referință au folosit în medie mult mai puțină energie – și au rulat mult mai repede – decât programele de referință pentru paradigmele orientate pe obiecte, funcționale și de scripting.

.

	Energie consumată	Timp de execuție
Imperativ	125J	5585ms
Obiect-Oriented	879J	32965ms
Functional	1367J	42740ms
Scripting	2320J	88322 ms

Dar există o mulțime de factori de luat în considerare. „Este clar că diferitele paradigme de programare și chiar limbajele din cadrul aceleiași paradigme au un impact complet diferit asupra consumului de energie, a timpului și a memoriei”, scriu cercetătorii. Totuși, care dintre acestea este cel mai important va depinde de scenariul dumneavoastră. (Sarcinile de fundal, de exemplu, nu au întotdeauna nevoie de cel mai rapid timp de execuție..)

Și unele aplicații necesită luarea în considerare a doi factori – de exemplu, consumul de energie și timpul de execuție. În acest caz, „C este cea mai bună soluție, deoarece este dominant în ambele obiective unice”, scriu cercetătorii. Dacă încercați să economisiți timp și, în același timp, să utilizați mai puțină memorie, C, Pascal și Go „sunt echivalente” – și același lucru este valabil dacă urmăriți toate cele trei variabile (timp, consum de energie și utilizare a memoriei). Dar dacă încercați doar să economisiți energie în timp ce folosiți mai puțină memorie, cele mai bune alegeri sunt C sau Pascal.

La finalul lucrării, cercetătorii adaugă că, pentru un studiu ulterior, ar dori să examineze dacă utilizarea totală a memoriei în timp se corelează mai bine cu energia consumată.

Ei își împărtășesc datele online, sugerând că le va fi mai ușor viitorilor cercetători să compare, de exemplu, limbajele .NET sau limbajele JVM. Pentru dezvoltatorii care lucrează cu aplicații mobile, sisteme Internet-of-Things sau alte aplicații care se bazează pe surse de alimentare limitate, consumul de energie este o preocupare majoră.

Dar, în cele din urmă, studiul ar putea, de asemenea, să-i lase pe programatori cu lucrul pe care îl urăsc cel mai mult: ambiguitatea. Cercetătorii raportează că, dacă sunteți în căutarea unui singur cel mai bun limbaj de programare, „această întrebare nu are un răspuns concret și final.”

„Deși cel mai eficient limbaj din punct de vedere energetic în fiecare punct de referință este aproape întotdeauna cel mai rapid, adevărul este că nu există un limbaj care să fie în mod constant mai bun decât celelalte”, concluzionează cercetătorii. „Situația în care va fi utilizat un limbaj este un aspect esențial pentru a determina dacă acel limbaj este cea mai eficientă opțiune din punct de vedere energetic.”

.