Nie wiem jak wy, ale od zawsze mam problem z produktami „eko”. Za każdym razem kiedy mam z nimi styczność, to zastanawiam się czy w ten sposób ktoś nie chce wyciągnąć ode mnie więcej pieniędzy. Kilka dni temu usłyszałem o, dla mnie nowym, trendzie czy idei – green coding. Nawet nie wiem czy warto tłumaczyć ten termin na polski. Zielone kodowanie? Ekologiczne programowanie?
Postanowiłem zgłębić ten temat czy to aby napewno nie jest kolejny buzz-word, który tylko fajnie brzmi i można tym tylko komuś zaimponować (lub rozśmieszyć).
Skąd dowiedziałem się o green codingu? Czas w którym powstaje ten wpis, to okolice Dnia Ziemi, który przypada na 22 kwietnia. Oznacza to, że tego dnia prowadzone są specjalne wydarzenia, których celem jest promowanie postaw proekologicznych w społeczeństwie.
O co chodzi z Green Coding?
Niektórzy już mogą się domyślać powyższym wstępnie. Green Coding to idea tworzenia kodu programistycznego w taki sposób by zużywał jak najmniej energii. Jednak sam kod, to nie wszystko. Dobrze jest też zaimplementować rozwiązania behawioralne czy takie w jaki sposób korzysta z naszej aplikacji użytkownik. Niby mało istotna sprawa, ale jak się dłużej nad tym zastanowimy, to istnieje korelacja pomiędzy scenariuszem użytkownika a ilością kody jaką trzeba stworzyć.
Czy przypadkiem nie chodzi tutaj o odpowiednią jakość kodu, optymalny kod, wydajne algorytmy? No jasne, że tak. Jeżeli kod jest dobrze napisany, to jego efektem ubocznym może być mniejszy zużycie prądu.
W tym miejscu powinieneś zainteresować się tematem notacji Big-O (jeśli jeszcze nie wiesz co to jest). To tylko jedna z rzeczy o której trzeba pamiętać pisząc swój kod.
Aby można było mówić o byciu „Green Software Engineer”, aplikacja którą tworzysz powinna być:
- energooszczędna,
- efektywna energetycznie – czyli nasz program nie powinien pobierać dodatkowej energii by działać efektywniej,
- wydajna (sprzętowo),
- zoptymalizowana – nie powinna wysyłać i pobierać nadmiarowych danych oraz działać szybko i sprawnie.
Naukowcy pochylili się nad problemem energooszczędności języków programowania
Okazuje się, że już kilka lat temu naukowcy pochylili się nad tym problemem. Sprawdzili, które języki są bardziej zielone od innych. Czyli, które zużywają mniej energii elektrycznej.
Do badania wykorzystano 10 znanych problemów programistycznych, które zostały rozwiązane w 27 językach. Ponadto mierzono czas i zużycie pamięci.
Wyniki okazały się całkiem ciekawe. Okazało się, że językami które spełniają najwięcej „zielonych” kryteriów są kompilowane.
Średnio, kompilowane języki zużywały 120 J [dżuli] na wykonanie rozwiązań, podczas gdy języki uruchamiane przez maszyny wirtualne i interpretery osiągały wyniki na poziomie 576 J i 2365 J.
Ujednolicona tabela TOP5 najefektywniejszych języków programowania przedstawia się następująco:
| Zużyta energia | Run-time | |
|---|---|---|
| C | 57J | 2019 ms |
| Rust | 59J | 2103 ms |
| C++ | 77J | 3155 ms |
| Ada | 98J | 3740 ms |
| Java | 114J | 3821 ms |
Po więcej szczegółów odsyła na thenewstack.io, gdzie wyniki badań zostały opisane trochę bardziej obszernie. Aha, JavaScript, język w którym programuję na codzień, wypadał w środku stawki.
Nie wiem jak wy, ale dla mnie to trochę wygląda jak dorabianie większej filozofii do czegoś co powinien robić każdy programista. A co powinien robić? Starać się tworzyć najbardziej wydajne oprogramowanie.
Widzę to tak, że ten green coding może się lepiej sprzedawać, bo wiecie, bycie eko i przyjaznym środowisku jest teraz bardzo modne. Wiele firm chce się chwalić, że robi coś „ważnego”.
Przykłady Green Coding
Co do przykładów, to będę miał ich kilka.
Pierwszy jaki można podać, to ten związany z YouTube. Nie wiem czy pamiętacie, ale jeszcze kilka lat temu YouTube miał całkiem poważny problem z grzaniem się telefonów z iOS. Wystarczyło oglądać filmy w tym serwisie i plecki iPhone’ów zaczęło się strasznie grzać. Problem został nagłośniony i programiści rozwiązali problem.
Takim akademickim przykładem może być porównanie algorytmów sortowania. Jest kilka sposobów by sortować dane, ale nie każdy z nich jest optymalny. Polecam zobaczyć poniższe wideo, które porównuje różne metody sortowania.
Gdyby ktoś chciał zgłębić wiedzę na temat tech ruchu, to mogę odesłać do innych źródeł:
1 komentarz
Wprawdzie artykuł sprzed roku, ale myślę, że nadal wart skomentowania. Co więcej, do tej pory jakoś nikt się nie zainteresował tematem. A szkoda, bo temat zmniejszenia zużycia energii przez (jakiekolwiek) urządzenia jest dość ważny. W szczególności te produkowane masowo, w których znajduje się „jakiś” mikroprocesor i współpracujące z nim peryferia. Co więcej, jak słusznie wskazuje Autor, programista też ma tu coś do powiedzenia, choć zapewne mniej niż projektant układów scalonych czy producent modułów elektronicznych zawierających te układy przylutowane do PCB.
Rozumiem Autora i jego ambiwalentne odczucia co do produktów z przedrostkiem „eko-” lub „green” w nazwie. To niestety jest wina ludzi propagujących przesadną reklamę wielu towarów, co (na ogół) skutkuje u odbiorcy co najmniej podejrzliwością wobec tak zachwalanych dóbr. Z nadużywaniem takich określeń wobec towarów które nie zawsze są „eko” lub „green” spotykamy się już od wielu lat, więc na ogół jesteśmy na to wyczuleni.
Przechodząc jednak do tematu artykułu, oczywiście zgadzam się całkowicie ze stwierdzeniem, że kluczową kwestią są algorytmy. Z tym, że jak wiadomo, były i są one głównie optymalizowane pod kątem szybkości wykonania obliczeń (operacji) przez procesor. Kwestie zużycie energii są tak naprawdę badane od niedawna, co prawdopodobnie ma związek ze wzrastającą liczbą używanych urządzeń mobilnych czy urządzeń IoT. Jeszcze 15 lat temu było ich bardzo mało, a 30 lat temu to były głównie kalkulatory kieszonkowe. Jednak nie tylko one zużywają energię elektryczną. Mamy przecież urządzenia stacjonarne, które też pożerają niemało energii: konsole do gier, komputery typu desktop, serwery czy wreszcie e-kioski i e-tablice na dworcach i lotniskach, w urzędach, restauracjach i sklepach wielkopowierzchniowych.
Wyniki badań na których Autor oparł swój artykuł, są mi znane od kilku lat (pierwszy raz zetknąłem się z nim w 2019 roku). Autor niniejszego artykułu oczywiście podał odnośnik do bloga z którego zaczerpnął informacje w temacie „zużycie energii a język programowania”. Niestety w felietonie anglojęzycznym jest podany tylko tytuł pierwotnego artykułu. Dla porządku dodam, że artykuł oryginalny jest zdeponowany w bazie „ACM” pod DOI: „https://doi.org/10.1145/3136014.3136031”. Ponieważ wydawca żąda opłaty (a większość dużych wydawców publikacji naukowych to robi), to oryginalni autorzy (badacze) udostępnili swój artykuł pod URL: „https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf”.
W początkowej części Autor pisze, że:
„Czy przypadkiem nie chodzi tutaj o odpowiednią jakość kodu, optymalny kod, wydajne algorytmy? No jasne, że tak. Jeżeli kod jest dobrze napisany, to jego efektem ubocznym może być mniejszy zużycie prądu. W tym miejscu powinieneś zainteresować się tematem notacji Big-O .[..].”
Całkowicie się z tym zgadzam. To jest ta część procesu tworzenia oprogramowania, nad którą programista ma kontrolę.
W dalszej części artykułu Autor podaje fragment wyników badań związanych ze zużyciem energii przez urządzenie testowe w trakcie wykonywania programu testowego, napisanego w 5 przytoczonych językach programowania. Po tym fragmencie Autor stwierdza:
„Nie wiem jak wy, ale dla mnie to trochę wygląda jak dorabianie większej filozofii do czegoś co powinien robić każdy programista. A co powinien robić? Starać się tworzyć najbardziej wydajne oprogramowanie.”
W zasadzie to jest prawda. Jednak co trzeba zrobić, żeby „utworzyć najbardziej wydajne oprogramowanie”? W jaki sposób to osiągnąć? Jak wiemy to jest bardzo szeroki i złożony temat. Tak naprawdę na tym zasadza się cała sztuka tworzenia oprogramowania. Podczas tworzenia oprogramowania trafiamy bowiem na sytuacje, które zależą od programisty jak i te, które od niego nie zależą.
Spróbujmy „wgryźć” się nieco w treść oryginalnego artykułu – okazuje się, że badaczom chodziło o zmierzenie zużycia RAM, czasu CPU i energii przy określonych założeniach:
1. używamy tego samego komputera do uruchamiania wszystkich testów (to jest oczywiste),
2. każdy uruchamiany program testowy ma takie same warunki działania jak inne, tj. żaden inny proces niż to jest konieczne przy pomiarze, nie ingeruje w pracę komputera (to też jest oczywiste),
3. piszemy kod każdego programu testowego tak, żeby każdy z nich korzystał tego samego algorytmu (to też wydaje się oczywiste).
W takich warunkach otrzymane wyniki pomiarów powinny (przynajmniej teoretycznie) wykazać różnice w zużyciu: RAM, czasu procesora oraz energii (tego właśnie dotyczy komentowany artykuł) związane wyłącznie z cechami posiadanymi przez języki programowania.
Czy zatem Autor niniejszego krytycznego spojrzenia ma rację, nieufnie odnosząc się do tematu „zielonego kodowania”, czy nie ma racji? Okazuje się, że wbrew pozorom odpowiedź nie jest prosta i jednoznaczna. Czyli, Autor ma sporo racji, ale też do pewnego stopnia rację mają badacze. Trzeba sobie zdać sprawę z pewnych niuansów związanych z tymi badaniami. Spróbuję to wyjaśnić.
Otóż, dość kontrowersyjnym jest założenie, że: „jeśli napiszemy kod każdego programu testowego tak, żeby każdy z nich korzystał z tego samego algorytmu, to z pomiarów dostaniemy tylko to, co wynika z różnicy w językach” (tj. z cech samego języka). Autorzy badań podają, że użyli następującego komputera (strona 259, fragment tuż nad sekcją 2.3) :
„All studies were conducted on a desktop with the following specifications: Linux Ubuntu Server 16.10 operating system, kernel version 4.8.0-22-generic, with 16GB of RAM, a Haswell Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz”
Podają także nazwy algorytmów oraz listę języków użytych do przygotowania programów testowych. Niestety badacze nie podali konkretnych kompilatorów/interpreterów oraz bibliotek jakich użyli. Weźmy na początek języki podane w Tabeli 2 z oryginalnego artykułu, sklasyfikowane jako imperatywne: Ada, C, C++, F#, Fortran, Go, Ocaml, Pascal, Rust (pomijam tu kwestie klasyfikacji, bo to nie jest związane z tematem). Ponieważ zastosowano system Linux, to można się domyślać jakich narzędzi używano (np. dla C i C++ byłby to kompilator GCC). Otóż jak napiszemy w każdym z nich program używając tego samego algorytmu, a potem skompilujemy napisany kod źródłowy, to dostaniemy wyniki które pokażą nie tylko różnice pomiędzy językami ale też różnice w jakości kompilatorów (zastosowane algorytmy, implementacje, optymalizacje, itd.). A jak wiemy kompilator GCC na przestrzeni lat był najczęściej ulepszany (pierwsza wersja GCC dla C to rok 1987). Kompilator Pascal, którego użyto to Free Pascal, który jest rozwijany od 2000 roku. Z kolei kompilator Rust jest dostępny od 2010. Zatem programiści kompilatorów tych dwóch języków nie mieli tyle czasu aby wprowadzić ulepszenia w tych kompilatorach w porównaniu do C. Ponadto te zespoły programistów są mniej liczne niż tych zajmujących się np. GCC. I mają o wiele mniejsze wsparcie finansowe lub żadne. GCC jest w wspierane przez kilka dużych korporacji, bo one z niego korzystają – taniej jest wydać trochę pieniędzy na istniejące rozwiązanie niż tworzyć od nowa swoje rozwiązanie za dużo większe pieniądze (jak wiemy zarządy korporacji patrzą tylko na bieżące zyski i koszty, rzadko interesuje ich długofalowe analizowanie promowanych rozwiązań). Podobnie jest z pozostałymi językami. Czyli na wyniki testów wpływają nie tylko różnice pomiędzy językami ale też nakład pracy włożony w rozwój kompilatora, coś co nie jest cechą języka programowania, tylko zbiorem szczegółów związanych z budową narzędzia.
W przypadku języków sklasyfikowanych jako obiektowe (Tabela 2: Ada, C++, C#, Chapel, Dart , F#, Java, JavaScript, Ocaml, Perl, PHP, Python, Racket, Rust, Smalltalk, Swift, TypeScript;), trzeba by sprawdzić dokładnie kody źródłowe, na przykład pod kątem stosowania (bądź nie stosowania) obiektów. Przykładowo w C++ można napisać program z użyciem klas albo całkowicie bez ich użycia. To może mieć przełożenie na wyniki pomiarów. Mogą to być niewielkie, ale wyraźne różnice. Ponadto ponownie dochodzi tu ten sam problem wpływu optymalizacji. Ponadto w podanych badaniach zastosowany kod źródłowy testów dla języka Pascal wymaga weryfikacji, bowiem pod tą nazwą powszechnie jest rozumiany zarówno Pascal proceduralny jak i Object Pascal (obiektowy). Kompilator Free Pascal obsługuje oba (podobnie jak GCC, który obsługuje zarówno C jak i C++). Podobne niuanse mogą zachodzić w przypadku innych języków.
W przypadku języków, których kod źródłowy jest skompilowany do kodu pośredniego (bajtowego), oczywistym jest, że wypadną one gorzej od wyżej wymienionych. A jeszcze gorzej wypadną języki interpretowane. Wyniki zużycia energii będą wypadkową zarówno cech języka jak też szczegółów implementacji oraz optymalizacji maszyny wirtualnej (np. C#, Java) lub interpretera (np. JavaScript, PHP, Python, Ruby).
To jest dość intuicyjne i w zasadzie „z grubsza” było do przewidzenia przez badaniem. Samo badanie pokazało tylko ile te różnice dokładnie wynoszą. Niestety w badaniu nie udało się pokazać różnic wynikających wyłącznie z cech samego języka (składnia, itd.), ponieważ nie da się oddzielić wpływu cech języka od wpływu narzędzi (kompilator, VM, interpreter) na zużycie energii. Co gorsza, ten sam program testowy, oparty na tym samym algorytmie może być różnie napisany (szczegóły implementacyjne) – im kod źródłowy bardziej złożony, tym więcej jego wariantów można utworzyć. Pytanie czy w programach testowych zawsze stosowano kod maksymalnie wydajny? Zważywszy na liczbę: badanych języków programowania, programów testowych oraz autorów wykonujących badania, kod prawdopodobnie nie zawsze był maksymalnie wydajny. Autorzy niestety nie podali skąd pochodzą kody źródłowe: czy sami je napisali, czy je zaczerpnęli z jakiejś bazy kodu. Można się domyślić, że źródłem prawdopodobnie jest serwis Rosetta Code. Oczywistym jest, że przejrzenie takiej ilości kodu w tylu językach wymagałoby sporo czasu (to jest możliwe), przy założeniu, że takie osoby znają naprawdę biegle każdy z tych badanych języków (to jest raczej mało prawdopodobne).
Wyniki tych badań są oczywiście interesujące, użyteczne i ważne, ale trzeba w ich analizie uwzględnić istniejące czynniki uboczne. Przeprowadzone dotychczas badania są raczej punktem startowym do analizy problemu zużycia energii z kontekście zastosowanego języka programowania.
Autor wspomniał, że na co dzień używa języka JavaScript. Z wyników pomiarów dowiadujemy się, że wypada on „tak sobie” (tj. poza połową, wg Tabeli 4 w oryginalnym artykule). Oczywiście jak je porównamy z innymi językami interpretowanymi (np. Perl, PHP, Python Ruby), to JavaScript wypada najlepiej. I znowu to nie jest zaskakujące, ponieważ jest on używany w przeglądarkach WWW, więc z tego względu jego interpreter jest mocno zoptymalizowany w porównaniu do pozostałych. Ale sesji przeglądarek WWW uruchamia się dziennie na świecie miliardy. Zatem powoduje to spore zużycie energii. Czy zatem trzeba to zmienić? Cóż, jakiś język skryptowy w przeglądarkach WWW być musi (z oczywistych powodów). Problemem bardziej jest to, że JavaScript jest:
1. stosowany w celach do jakich nie był projektowany, tj. aplikacje po stronie serwera czy namiastki programów typu desktop (Electron, itp.),
2. nadużywany na stronach WWW.
W przypadku serwerów WWW nie ma się co oszukiwać, że pozostałe języki interpretowane będą bardziej energooszczędne niż JavaScript. Zatem jeśli aplikacje po stronie serwera mają być niezwykle oszczędne, to teoretycznie trzeba by zastosować język kompilowany do kodu maszynowego. Jednak pisanie serwisu WWW dajmy na to w C++ (że już nie wspomnę o C) to jest „droga przez mękę” – wymaga to dużo czasu, cierpliwości, itd. Można zatrudnić programistę-speca, ale koszty utworzenia takiego serwisu byłyby z kolei za wysokie a serwis były prawdopodobnie tworzony za długo. Pozostaje jeszcze jedno wyjście – że jakaś firma stworzy bibliotekę na tyle rozbudowaną, przemyślaną i uniwersalną, że opłaci się użycie C++ do utworzenia serwisów WWW. Na razie nie ma takiego ogólnie uznanego rozwiązania (i nie widać żadnych oznak, żeby tak miało się stać).
Co do strony klienta (czyli przeglądarki WWW), to problemem jest nie tyle użycie skryptów JavaScript, ile ich ilość dołączona do każdej strony WWW. Trudno jednak w tym przypadku winić narzędzie (tj. język programowania, interpreter), gdy rzeczywistymi winowajcami mogą być osoby tworzące serwis WWW (programiści) albo osoby wymuszające na tychże programistach użycie przesadnie dużej liczby skryptów w serwisie WWW.
Oczywiście, problem zużycia energii przez urządzenia wyposażone w procesor, jest ważny. Należy go analizować. Ale kwestię oszczędności energii na pewno trzeba badać szerzej, bardziej kompleksowo.