Język Python jest lepszy niż język C! A może jest odwrotnie? (cz. 2 / 2)

40_got
Wróćmy teraz do naszych czasów i przedyskutujmy, co myśli się o tym, jak ludzie postrzegają aktualny stan języków Python i C. Oczywiście procesory stały się większe i szybsze, a do tego mamy procesory wielordzeniowe i tym podobne – ale tutaj robimy „duży obraz”. W ramach tego możemy zauważyć, że – ogólnie rzecz biorąc – asembler jest zwykle używany tylko w najmniejszych mikrokontrolerach, które zawierają tylko niewielkie ilości pamięci (rys. 2).

To z kolei prowadzi to do faktu, że język C jest często opisywany, jako język niskiego poziomu. Określenie „niski poziom” może wydawać się nieco lekceważące, ale – w informatyce – w rzeczywistości odnosi się do języka programowania, który zapewnia niewielką lub żadną abstrakcję z podstawowej architektury sprzętowej komputera. Dla porównania, często mówi się, że Python jest językiem wysokiego poziomu, co oznacza, że jest on pobierany z najmniejszych szczegółów systemu podstawowego.
Co więcej, oczywiście prawdą jest, że model języka C dla wskaźników i pamięci i tym podobnych mapuje się ściśle na typowe architektury procesorów. Prawdą jest również to, że – mimo że obsługuje operacje bitowe – czysty Python nie pozwala natywnie wykonywać takich czynności, jak podglądanie i pokrywanie rejestrów mikrokontrolera MCU i lokalizacji pamięci. Co więcej,  jeśli używasz Pythona na mikrokontrolerze, pojawi się również warstwa abstrakcji sprzętu (HAL – hardware abstraction layer), która dostarcza interfejs pozwalający aplikacji napisanej w Pythonie na bezpośrednią komunikację z podstawowym sprzętem.
Jeden z przykładów wykorzystania Pythona w systemach wbudowanych można znaleźć w modułach RF firmy Synapse Wireless, które są wykorzystywane do wdrażania bezprzewodowych sieci o małej mocy. Wdrożenie to stanowi również doskonałą podstawę do porównania z odpowiednikami opartymi na języku C.
W przypadku stosu bezprzewodowego ZigBee zaimplementowanego w języku C, gdzie dowolne aplikacje będą zazwyczaj implementowane na przykład w języku C, sam stos może z łatwością zajmować ~100KB pamięci Flash, a następnie trzeba wziąć pod uwagę dodatkową pamięć wymaganą dla aplikacji (bardziej zaawansowane aplikacje będą wymagały droższych mikrokontrolerów 256KB).
Zazwyczaj będziesz musiał skompilować stos oparty na języku C w połączeniu z aplikacją opartą również na C w jednym pliku wykonywalnym, który następnie musisz załadować do swojego węzła bezprzewodowego.
Ponadto tutaj wystąpi konieczność ponownej kompilacji aplikacji ze stosem dla każdego docelowego mikrokontrolera.
Dla porównania, stos Synapse, który – podobnie jak ZigBee – znajduje się na wierzchu warstw kontroli fizycznej i kontroli dostępu do mediów IEEE 802.15.4, zużywa tylko ~55KB pamięci Flash, w tym maszynę wirtualną Python (VM). Oznacza to, że jeśli zdecydujesz się na niedrogi mikrokontroler ze 128KB pamięci, w przypadku aplikacji opartych na Pythonie będziesz miał nadal 73KB pamięci.
A mówiąc o tych aplikacjach opartych na Pythonie, są one interpretowane jako kod bajtowy, który działa na maszynie wirtualnej Pythona.
Ponieważ każdy kod bajtowy odpowiada od 1 do 10 kodom maszynowych – uśrednijmy to na 5 – oznacza to, że 73KB pamięci aplikacji jest w rzeczywistości odpowiednikiem 73 × 5 = 365KB. Co więcej, ta sama aplikacja kodu bajtowego będzie działać na dowolnym docelowym mikrokontrolerze, który używa stosu Synapse.
Kontynuując moje przemyślenia, zapytałem również mojego przyjaciela Davida Ewinga, co sądzi o dyskusji konfrontującej język C i język Python. David jest dyrektorem technicznym Synapse Wireless i, w przeciwieństwie do ciebie, jest doświadczonym programistą. Dawid odpowiedział:
Języki C i Python są fantastycznymi językami i bardzo je kocham. Istnieje oczywiście wiele różnic technicznych, składniowych i semantycznych – typowanie statyczne i dynamiczne, kompilacja kontra interpretacja itd. – ale istotą tego wszystkiego jest:
– C to skompilowany język „close to the metal” (w informatyce to nazwa wersji beta niskopoziomowego interfejsu programistycznego opracowanego przez ATI, obecnie AMD Graphics Product Group, mającego na celu włączanie przetwarzania GPGPU). To „uniwersalny asembler”. Jest czysty i elegancki. Mój ulubiony cytat o C pochodzi z mojej 30-letniej książki K&R: „C nie jest dużym językiem i nie może być dobrze opisany przez dużą książkę”.
– Python, dzięki „dynamicznemu typowaniu”, zmniejsza „przypadkową złożoność”. Python jest interpretowany (lub kompilowany „w locie” – JIT), więc możesz mieć głupie błędy, które nie zostaną wykryte do czasu wykonania.
Jednak kompilatory nie zawsze ujawniają poważne nietrywialne błędy. W takich przypadkach pomoże tylko testowanie; rozwiązanie musi być dokładnie testowane, niezależnie od języka implementacji.
David mówił dalej:
Jeśli problem można rozwiązać w Pythonie, można go rozwiązać także w C; ale nie zawsze jest odwrotnie. Jeśli jednak problem można rozwiązać w Pythonie to:
– rozwiązanie (kod źródłowy) będzie prostsze w Pythonie niż odpowiedni kod w C,
– kod będzie bardziej „czytelny”.
– co ważniejsze, będzie bardziej „zapisywalny” (jest to często pomijana jakość!).
Ze względu na wyżej wymienione cechy, rozwiązanie będzie miało mniej błędów i może zostać opracowane znacznie szybciej, a to są prawdziwe argumenty przemawiające za wyborem Pythona zamiast C dla wielu zadań.
Jestem jak David (poza tym, że noszę o wiele lepsze hawajskie koszule), ponieważ doceniam zalety obu języków. Lubię na przykład sprytne rzeczy, które można zrobić ze wskaźnikami w języku C, ale także doceniam bardziej intuicyjną, łatwą w użyciu składnię Pythona.
Więc, który język jest najlepszy dla aplikacji wbudowanych?
Trudno mi odpowiedzieć. W dużej mierze zależy to od tego, co chcesz (co potrzebujesz) uzyskać z aplikacji. Domyślasz się, co chcę powiedzieć dalej, nieprawda? I co o tym sądzisz? Generalnie, który język preferujesz: język C czy Python, a w przypadku aplikacji wbudowanych? A gdybyśmy poszerzyli zakres pytania, czy jest inny język, którego wolisz używać w przestrzeni wbudowanej?

Autor: Max Maxfield

Komentarze z Facebooka

Komentarze obecnie - OFF.