Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

W dokumencie, który można pobrać z tej strony, możemy znaleźć wyniki i opis procedury badania efektywności energetycznej oprogramowania w zależności od używanej platformy językowej. Wyniki opracowania (jak sami autorzy przyznają) choć są bardzo konkretne, to można je interpretować na różne sposoby, co w dalszej części spróbujemy także uczynić. Główna tabela wyników przedstawia się następująco:

JęzykTypZużycie energii
Ccompiled1.00
Rustcompiled1.03
C++compiled1.34
Adacompiled1.70
Javavirtual machine1.98
Pascalcompiled2.14
Chapelcompiled2.18
Lispvirtual machine2.27
Ocamlcompiled2.40
Fortrancompiled2.52
Swiftcompiled2.79
Haskellcompiled3.10
C#virtual machine3.14
Gocompiled3.23
Dartinterpreted3.83
F#virtual machine4.13
JavaScriptinterpreted4.45
Racketvirtual machine7.91
TypeScriptinterpreted21.50
Hackinterpreted24.02
PHPinterpreted29.30
Erlangvirtual machine
42.23
Luainterpreted45.98
Jrubyinterpreted46.54
Rubyinterpreted69.91
Pythoninterpreted75.88
Perlinterpreted79.58

Wnioski wydają się oczywiste, także z punktu widzenia firmy Streamsoft. Dlaczego? Język C to bezdyskusyjny zwycięzca a pokrewny z nim C++ jest w ścisłej czołówce. W Streamsoft te dwa języki to podstawa. Nasze fundamenty, Linux, Windows, Postgres, Firebird, Chromium, wszystko to jest napisane w C lub C++. I to są bardzo dobre informacje. Kolejne dwie ważne dla nas platformy to Java i Pascal. Obie są bardzo wysoko w rankingu. Musimy jeszcze wspomnieć o Android’zie, a trzeba to zrobić w sytuacji coraz większej popularności mobilnych aplikacji w portfelach wszystkich produktów Streamsoft. Jak wiadomo Android == Linux && Java, a to daje także doskonały wynik. Należy także wspomnieć o C#, Dart i JavaScript, tu może nie mamy miejsc w czołówce, ale jest naprawdę przyzwoicie.

Jednym słowem, jeżeli używasz oprogramowania Streamsoft to dbasz o efektywność energetyczną (oczywiście w zakresie ERP) a co za tym idzie, dbasz o oszczędzanie energii i zasobów naturalnych. To tyle. Ale czy to wszystko? Spróbujmy pomyśleć w taki sposób:

„ … jestem programistą, piszę właśnie zapytanie SQL, będzie ono, u tysięcy klientów, tysiące razy w ciągu dnia, przesyłane do wykonania do serwera bazy danych, sporo, ale on (serwer DB) przecież jest napisany w C więc (rzut okiem na tabelkę powyżej), będzie dobrze. Będę je (to zapytanie SQL) wysyłał z Java’y, więc także nie będzie problemu. Nie muszę więc o tym myśleć … ziemia, nasze dzieci i ich dzieci są bezpieczne … „

O naiwny, można by powiedzieć przeglądając kod, który ten programista chciał zrzucić do repozytorium GIT’a. Zadanie programisty polegało na dostarczeniu metody ustalającej czy w systemie znajdują się przeszacowania ceny zakupu, dla pewnej konkretnej dostawy towaru. Pisząc implementację programista myślał tak:

„ …to proste, odczytam listę tych przeszacowań (SLECT * FROM przeszac WHERE .. ), i jak będzie pusta to zwracam False, a jak nie pusta to True, … to zadziała … „

Musimy przyznać, że rozwiązanie działa. Ale czy jest efektywne? Pytanie jest takie, po co czytać z bazy danych (tzn. z dysku, z pamięci) potencjalnie nie małą listę wierszy, przesyłać przez sieć, odbierać i deserializować w Java’ie, tylko po to aby sprawdzić list.size() == 0? To jakby czytać całą książkę aby dowiedzieć się ile ma stron. Najszybsze i najprostsze usprawnienie to np. (SELECT id_przeszac FROM przeszac WHERE … LIMIT 1) i już będzie dużo efektywniej, Oczywiście mamy świadomość, że istnieje wiele innych lepszych sposobów na optymalizację tego algorytmu, ale nie o tym mowa. Wniosek jest prosty:

używając wysoko-efektywnych energetycznie platform i narzędzi
można z łatwością tworzyć nieefektywne rozwiązania

Wciąż tak dużo zależy od nas. Wyobraźmy sobie, że autorzy narzędzia, którego używa programista, w wyniku wywołania zapytania SQL zwracają listę, ale taką która nie posiada metody

int size()

tzn. nie da się sprawdzić ile elementów ma wynik zapytania. Szok! Jak to, takie słabe API? A jednak autorzy uznali, że takie działanie nie ma sensu, bo najczęściej będzie używane do tworzenia nieefektywnych implementacji. Co ma zatem zrobić programista? Autorzy narzędzia dostarczyli metodę

boolean anyRow()

która zwraca True lub False gdy wynik zapytania jest pusty lub nie. Jak to jest zaimplementowane? Nie musimy wiedzieć. Jak ktoś wymyślił takie API to miał świadomość i prawdopodobnie zadbał o wszystko.

Podsumowując powyższe rozważania, pamiętajmy, dbanie o optymalizację algorytmów ma pozytywny wpływ na zużycie zasobów dostępnych na ziemi a także na zanieczyszczenie środowiska a samo używanie wysoko efektywnych platform nie zrobi za nas całej roboty. Czy ktoś tworząc oprogramowanie o tym myśli? Czy jest szansa aby to właśnie wysoka świadomość twórców i organizacji stymulowała takie myślenie? Ja uważam, że edukacja i uświadamianie to słuszna droga, trzeba to robić, ale nie pokładam w tym dużych oczekiwań. Uważam, że sprawę szybciej i sprawniej rozwiązuje ekonomia np. poprzez SaaS i Chmurę. W SaaS klient płaci za usługę pewną stałą ustaloną kwotę, proporcjonalną do skali tej usługi. Dostawca usługi ponosi koszty infrastruktury (a nie klient) oraz wytworzenia samej usługi (tworzy oprogramowanie). Zysk dla dostawcy to klasycznie przychody minus koszty, a skoro kosztem jest infrastruktura, którą dostarcza Chmura, gdzie opłaty zależą od zużycia tejże, to mamy prosty i bardzo mocny stymulant dla dostawcy usługi, do obniżania zużycia zasobów infrastruktury i w konsekwencji poszukiwania rozwiązań tańszych (optymalizacji oprogramowania) i mniej kosztownych energetycznie. Cała nadzieja w chęci generowania większych zysków. Cóż, kolejny raz „kapitalizm” może przyczynić się do ratowania świata :).

Na koniec, prośba, do wszystkich, tworząc kod, algorytmy, API czy cokolwiek, myślmy o ich złożoności i wydajności, także dlatego aby cytowany programista „ … nasze dzieci i ich dzieci są bezpieczne … ” nie mylił się zbyt mocno.