logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Czy stare komputery były lepsze od SBC i płytek rozwojowych?

Urgon 09 Mar 2023 10:44 2856 25
  • Czy stare komputery były lepsze od SBC i płytek rozwojowych?
    O komputerach jednopłytkowych już raz pisałem. Generalnie nie mam o nich zbyt dobrej opinii, i zdarza mi się często wytykać ich wady. Do tego mocno mnie fascynuje historia techniki, w tym komputerów właśnie. Mam pewne doświadczenie zarówno ze współczesnymi platformami, jak NodeMCU, Raspberry Pi czy Arduino, czy współczesną metodą programowania ich z użyciem C++ dla Arduino i Pythona dla RPi. NodeMCU programowałem z pomocą języków Lua i bodaj Forth. Programowałem też w C, liznąłem troszkę COBOLa, używałem nagiego DOSa i pisałem kod w BASIC i LOGO. Kilka programów skrobnąłem też w Delphi (ktoś to pamięta?) i w Pascalu. Miałem ambitny plan zbudowania sprzętowej emulacji Odry 1305 z użyciem układów CPLD oraz programowej emulacji PDP-8 na PIC24. Tak że myślę, iż mogę odpowiedzieć na pytanie, czy stare komputery były lepsze od współczesnych platform rozwojowych i SBC?


    Nie lubię Arduino

    I to jest jak najbardziej prawda. Arduino to platforma, która miała dać łatwy dostęp do programowania elektroniki ludziom, którzy nie znają się ani na elektronice, ani na programowaniu. I, szczerze pisząc, nie ma w tym nic złego. Ba, Arduino realizuje ten cel świetnie. Zwłaszcza jego liczne klony, które nie mają cen z kosmosu. Nie lubię Arduino dlatego, że jego użytkownicy zasadniczo stoją w miejscu. Ludzie uczą się Arduino, używają gotowych kawałków kodu i przyjaznych funkcji nie opanowując tego, co kryje się pod spodem. Arduino jest zbyt przyjazne i nie uczy dobrych nawyków programistycznych. Co gorsza, zachęca ludzi do realizacji na tej platformie projektów, które nie powinny być na niej realizowane. Jak na przykład projekt otwartego ECU - modułu sterującego silnikiem spalinowym w ekstremalnie trudnych warunkach. Arduino nie jest zaprojektowane do pracy w takich warunkach, nawet Atmel o tym pisał.

    Drugim problemem, równie poważnym, jest nastawienie samych użytkowników Arduino - zawsze i wszędzie bronią swojej platformy nie widząc jej problemów i ograniczeń. Nie ma też kwartału, by Arduino nie próbowało wypuścić kolejnego Arduino-killera, który jest nie tylko drogi, ale też nie oferuje niczego, czego konkurencja już nie zrobiła. A i konkurencja też sobie nie radzi w tej grze.


    Raspberry Pi (i inne)

    Komputery jednopłytkowe to pewne kuriozum. Obiecywały funkcjonalność komputera stacjonarnego sprzed kilku lat w małym rozmiarze i z możliwością używania w różnych projektach. Moje doświadczenia, gdy miałem awarię komputera stacjonarnego, okazały się kompletnym rozczarowaniem. Przeglądanie Internetu czy oglądanie YouTube było kompletnie niemożliwe. Myślałby kto, że cztery rdzenie i 2GB RAMu wystarczą, zwłaszcza że ponoć jest nawet jakieś bieda-GPU w środku. Może jakbym kupił jakiś SBC oparty o architekturę X86-64, a nie ARM, najlepiej z 4-8GB RAMu i innym nośnikiem systemu, niż karta microSD, to coś by się ugrało. Ale to już kosztuje tyle, co budżetowy laptop czy komputer stacjonarny bez wodotrysków. Tanie SBC nie nadają się do niczego, co można nazwać zwykłym użytkowaniem komputera. I to nie jest ich wina, tylko tego, jak obecnie funkcjonuje Internet i jak wiele wymaga się od przeglądarek. Firefox z czterema otwartymi kartami "zjada mi" teraz prawie 2GB pamięci.

    Zatem do czego nadaje się takie Raspberry Pi?

    Wbrew pozorom potrafi sporo, jeśli jesteśmy specyficzni. O używaniu na codzień zamiast komputera można zapomnieć - za mało mocy, za mało pamięci. Ale możemy z RPi zrobić emulator starych konsol i platform arcade z systemem RetroPie. Chcemy oglądać strumienie video z Internetu lub słuchać internetowego radia, jest na to odpowiednia wersja systemu, już skonfigurowana pod prostą nawigację i dająca dostęp do wielu bezpłatnych kanałów z całego świata. Dostępnych konfiguracji i dodatkowych modułów jest ogromny, w końcu system operacyjny jest na bazie Debiana.

    Wielkim plusem i powodem dominacji RPi jest bardzo dobra dokumentacja i duże wsparcie użytkowników. Bez problemu każdy może kontrolować piny IO na płytce, łatwo łączyć się z urządzeniami po WiFi, postawić i skonfigurować serwer MQTT do domowej automatyzacji i serwer HTTP z automatycznie generowaną stroną internetową pozwalającą na wgląd w bieżący stan i w statystyki. Klejem to wszystko zlepiającym jest Linux (którego kocham nienawidzić) i Python (choć są alternatywy). Jest to dobry i ciekawy start w informatykę bliską sprzętowi, zwłaszcza jak zaczniemy do tego dokładać moduły na ESP8266 i ESP32, jak NodeMCU, czy inne rozwiązania kompatybilne z platformą.

    Świat nie kończy się tylko na Raspberry Pi. Po pojawieniu się słynnej "poziomki" nastąpił prawdziwy wysyp takich komputerów jednopłytkowych. 99% z nich jest kompletnie bezużyteczne, bo nie mają ani działającego oprogramowania, ani dokumentacji, i w większości zrobiono je z tych samych komponentów, z których robi się najtańsze tablety i smartfony z Chin. Dlatego właśnie nie ma miesiąca na Elektrodzie, by w newsach nie pojawiły się przynajmniej trzy takie komputery. Warto do nich podchodzić z dużą dozą sceptycyzmu, i sprawdzić poziom wsparcia, zanim wybierze się jakąś alternatywę do RPi.


    Jednopłytkowi bracia mniejsi

    Między Arduino, a czymś w stylu Raspberry Pi istnieje cały mikroświat mikrokontrolerów ośmio-, szesnasto- i trzydziestodwubitowych. Najpopularniejsze używają układów STM32 albo ESP8266 czy ESP32. Znajdziemy tu też zestawy rozwojowe na bazie układów LPC czy PIC24/dsPIC i PIC32. Oferta jest naprawdę bogata. Ale skutkiem ubocznym jest niewielka popularność mniej znanych rozwiązań. Kto z Was ma ChipKITa? Kto z Was programował układy LPC albo egzotykę od Renesas?

    Ogrom opcji, ceny różne, dokumentacja od bardzo dobrej do szczątkowej. Czasem dostaniemy IDE i generator kodu, a czasami dostaniemy tylko garść narzędzi ze szczątkową dokumentacją i wątpliwymi przykładami. Potężne platformy potrafią być ograniczone przez dziwne decyzje projektowe na poziomie sprzętu i oprogramowania, przez co rozwiązania Arduino-podobne są pożądane na początku poznawania nowej platformy. Ważne, by pamiętać, że prawdziwą moc danej platformy można okiełznać sięgając w jej wnętrzności i opanowując niskopoziomową obsługę peryferiów i komponentów danego systemu.

    Przykład z życia: potrzebowałem generować strumień losowych bitów w układzie o dużych ograniczeniach RAMu. Domyślna funkcja RAND() w XC8 była zwyczajnie za duża. Napisałem więc własną, używającą nieco mniejszych liczb. W innym programie musiałem znaleźć rozwiązanie, jak emulować EEPROM w mikrokontrolerze bez EEPROMu. Nauczyło mnie to, jak deklarować stałe pod konkretnym adresem i jak przebiega proces samoprogramowania.

    Warto też pamiętać, iż platforma nie ma znaczenia. Ba, język programowania to też sprawa wtórna. Liczy się zdolność czytania dokumentacji i pisania sensownych algorytmów. Wiecie, jaka jest najgorsza płytka rozwojowa? Jest to ta, która leży w kącie i zbiera kurz. I piszę to jako winny tego grzechu. Mea culpa...


    Dawniej to było... w miarę okej

    Na początku był Altair 8800 i IMSAI 8080, czyli pierwsze naprawdę popularne komputery dla hobbystów. Nie dość, że były dość kosztowne, to jeszcze wymagały dużej wiedzy z zakresu elektroniki i programowania, oraz zamiłowania do pstrykania przełącznikami. To przez te komputery, zwłaszcza Atlaira powstały firmy Apple i Microsoft, ta druga stworzyła BASIC dla procesora 8080, i ta wersja pojawiła się w wielu późniejszych komputerach. Lata 80-te to rozpowszechnienie się na zachodzie komputerów ośmiobitowych. Królem był Commodore C64, czyli najlepiej się sprzedający komputer tamtej ery. Oferował 64kb pamięci RAM, dedykowane układy audio i video i bardzo dobry interpreter BASICa. Niejeden twórca gier zaczynał swoją karierę od pisania ich właśnie w BASICu na C64. Jeśli jednak mieszkał w UK, to prędzej używał BBC Micro albo ZX Spectrum. BASIC to język dość prosty, z prostym zadaniem: nauczyć początkujących podstaw programowania. To było Arduino lat 80-tych. I też uczył złych nawyków, jak używanie skoków GOTO. Ale dostęp do bardziej zaawansowanych funkcji komputera nie odbywał się przez przyjazne polecenia BASICa - tu już trzeba było czytać i modyfikować komórki pamięci poleceniami PEEK i POKE lub ich odpowiednikami dla innych komputerów. Ba, podręczniki nie tylko tego nie ukrywały, ale wręcz detalicznie opisywały działanie poszczególnych komórek pamięci. Programiści uczący się na Atari, Commodore czy ZX Spectrum dość szybko odkrywali, że prawdziwą moc z każdej platformy daje dopiero Assembler i programowanie blisko sprzętu. Inaczej po prostu nie dało się manipulować sprite'ami, czy generować dźwięku. Ważnym aspektem też była demoscena na platformach ośmiobitowych, gdzie programiści i hakerzy robili rzeczy, o których nawet projektantom tych komputerów się nie śniło.

    Warto też wspomnieć o tym, że ośmiobitowe komputery miały też udokumentowany i przeznaczony do dowolnych zastosowań port rozszerzeń. Eksponował on linie danych i adresowe mikroprocesora, co pozwalało zarówno firmom, jak i zwykłym użytkownikom na dołączanie rozszerzeń, dodatkowych modułów czy nawet cartridgy zawierających programy zapisane w pamięciach ROM. Pozwala to na dużo więcej, niż porty w Arduino czy Raspberry Pi. Choćby na dołożenie więcej RAMu komputerom, które miały 4-16kB.

    Największą wadą tych starych komputerów było ładowanie programów. Sam komputer włącza się w mniej niż sekundę, ale jeśli program nie jest zapisany w pamięci (E)EPROM, to jego wczytywanie może trwać 5-10 minut. Współczesne SBC mają problem odwrotny: uruchamianie trwa od 20 sekund do 2-3 minut, ale wczytanie programu z karty microSD trwa ułamki sekundy i można ten proces zautomatyzować. Arduino i inne zestawy oparte o mikrokontrolery startują w ciągu ułamków milisekundy, program ładuje się raz. Niektóre platformy, jak Arduino czy ChipKIT, mają wbudowany bootloader. ESP8266 i ESP-32 mają to realizowane sprzętowo, i płytki w stylu NodeMCU nie potrzebują niczego, a do gołych modułów wystarczy przelotka USB<>UART. "Gołe" mikrokontrolery mogą potrzebować programatora, ale te nie są aż tak drogie. Plus, są i gotowe bootloadery, w które można te mikrokontrolery wyposażyć.


    Python - BASIC XXI wieku

    Przez ponad dekadę już podstawowym edukacyjnym językiem programowania dla początkujących stał się Python. Jest to język interpretowany, co oznacza że kompilacja następuje "po kawałku" w chwili wykonywania kodu. Działa to podobnie do BASICa, z tą jednak różnicą, iż Python oferuje rzeczy w BASICu niespotykane, jak programowanie obiektowe. To dość nowoczesny język z wieloma gotowymi bibliotekami, ale przez swoją naturę jest raczej powolny. To cecha wielu języków interpretowanych, które pod względem prędkości zawsze przegrywają z językami kompilowanymi. Między programistą Pythona, a programistą BASICa jest jedna, zasadnicza różnica: gdy brakło nocy i możliwości BASICowi, programista sięgał po Assembler, albo na PC po C czy Pascala, albo inny język kompilowany. Gdy programiście Pythona braknie mocy, kupuje potężniejszy komputer/serwer. A wystarczyłoby przerzucić się na C# czy Javę.

    Jednym z aspektów Pythona, który osobiście mnie denerwuje jest fakt, iż ten język używa tabulatora jako elementu składni. Przyczyną takiego rozwiązania jest fakt, iż dzięki temu narzucane jest właściwe formatowanie programu. Osobiście preferuję używanie nawiasów klamrowych albo słów kluczowych, jak w C czy Pascalu. Jak ktoś ma problem z brakiem ładnych wcięć, to powinien używać normalnego IDE zamiast notatnika. Serio, to takie proste. Każdy język programowania używający pustych znaków jako elementu składni to zły język.

    Używałem kilku dużych aplikacji napisanych w Pythonie, i każda z nich miała jeden problem: była wolna i zasobożerna. Przykład: bCNC, program do sterowania frezarkami CNC opartymi o Arduino. Renderowanie ścieżki, po jakiej będzie poruszał się frez trwa długo, i nie jest pełne, bo narzucono odgórny limit liczby kroków - Python sobie zwyczajnie nie radzi. Ba, dodanie opcjonalnych, zoptymalizowanych i napisanych w C++ bibliotek SciPy i NumPy niewiele pomaga - przy renderowaniu dużych plików gcode bCNC zwyczajnie się wieszał. Dużo starszy program, Mach3, napisany w bodaj Pascalu czy Delphi, nie miał takich problemów. Renderowanie może trochę potrwać, ale zdecydowanie mniej niż w przypadku bCNC, i nigdy przy tym mi się nie zawiesił.

    Niestety, Pythona ze względu na prostotę użycia wciska się wszędzie, od backendów wielu serwerów po skomplikowane zadania związane z nauczaniem maszynowym i sieciami neuronowymi. Dlaczego tak się stało? Bo do Pythona jest bibliotek tona. I to jedyna przyczyna. Teraz pomyślcie o tym, że ChatGPT został napisany w Pythonie i jego nauczanie wymagało superkomputera, który był swego czasu w Top100, jak wydajniej i szybciej by pracował, gdyby te algorytmy napisano w C++ albo w Rust. Ba, nawet Go, język stworzony z myślą o przetwarzaniu równoległym, w większości standardowych benchmarków jest 10-60 razy szybszy. ChatGPT jest pisany w Pythonie, bo byłoby za dużo zachodu z przepisaniem go na bardziej optymalny język, zwłaszcza język kompilowany. za to 5-10krotny skok wydajności by ten "zachód" teraz usprawiedliwił, gdyby komuś się chciało to zrobić.

    Jednym z miejsc, gdzie Python się zadomowił na stałe są komputery jednopłytkowe, w tym Raspberry Pi. Od lat trwają też prace nad implementacją Pythona dla mikrokontrolerów, ale wyniki są mieszane. Python przez swoją wewnętrzną budowę i sposób działania zwyczajnie jest zasobożerny i słabo sobie radzi na platformach z dużymi ograniczeniami zasobów. Dlatego właśnie NodeMCU na ESP8266 używa języka Lua.

    Jedyne, do czego zdarzało mi się użyć języka Python, to było kilka prostych skryptów by coś policzyć iteracyjnie, tj. przechodząc przez wszystkie wartości w zakresach dla trzech zmiennych. Skrypt potrzebował kilkunastu sekund by przeliczyć wartości i wyświetlić wybrane przypadki z ponad 16 milionów.


    PEBCAC

    Czy zatem stare komputery były lepsze od współczesnych platform rozwojowych?

    Odpowiedź brzmi: czasami, ale z innych powodów, niż myślicie.

    Współczesne platformy, jak Raspberry Pi i podobne, czy płytki oparte o mikrokontrolery ARM oferują potężne moce obliczeniowe i ogromny przyrost wydajności względem tego, co potrafiły Commodore C64 czy ZX Spectrum. Nawet typowe mikrokontrolery ośmiobitowe mają szybsze zegary i wykonują więcej operacji na sekundę, niż poczciwe procesory MOS 6502 czy Zilog Z80. Ograniczenia starych komputerów wymuszały na programistach dogłębne poznanie architektur i implementacji, oraz wykorzystanie ich do cna. Przykładem niech będzie demoscena, gdzie pisze się specjalne programy robiące rzeczy na pozór niemożliwe na danej platformie. Użyteczność jest mała, bo gdy poczciwy C64 renderuje grafikę 3D z prostą animacją i odtwarzaniem rozbudowanej ścieżki dźwiękowej, nie ma czasu na nic innego. Zatem pod względem surowej mocy obliczeniowej nawet Arduino wygrywa ze starym ośmiobitowcem, ale stary ośmiobitowiec wygrywa możliwościami swoich peryferiów i wyeksponowanymi szynami danych i adresową, co pozwala mu na więcej.

    Problemem współczesnych platform nie jest sprzęt, lecz użytkownicy i programiści. Dlaczego Raspberry Pi 3 dławiło mi się, gdy próbowałem użyć go jako tymczasowego komputera stacjonarnego? Ano dlatego, że używał Linuxa i przeglądarki napisanych z myślą o komputerach opartych o procesory Intela i AMD. Architektura ARM jest od nich zupełnie inna. Dla przykładu procesor ARM Cortex A53 ma mniej niż sto instrukcji, wliczając ich warianty. Dla porównania znalazłem listę 336 instrukcji dla IA-32 czyli zestawu instrukcji dla procesorów Intela, przy czym autor tej listy odliczył duplikaty (związane z kompatybilnością wsteczną) i różne warianty. Co ta różnica oznacza w praktyce? To proste, jeśli weźmiemy system operacyjny i oprogramowanie pisane z myślą o komputerach osobistych, a potem skompilujemy go na platformę, gdzie wielu zaawansowanych instrukcji brak (zwłaszcza tych związanych z operacjami na dużych zbiorach danych), to nagle okazuje się, że jedną instrukcję procesora Intel czy AMD kompilator zastępuje dziesiątkami, lub setkami instrukcji procesora ARM. Jedyną, rozsądną metodą na uzyskanie dużej wydajności jest przepisać absolutnie wszystko pod architekturę ARM. Jest to bardzo trudne. Nie wspominając o tajemnicy handlowej producenta układu. Dlatego platforma RPi i jej podobne mają ogromny problem z akceleracją grafiki 3D (kiepskie sterowniki bez dostępu do kodu źródłowego), i często muszą realizować to programowo.

    Dodajmy do tego drugi problem, tym razem po stronie użytkowników: używanie niewłaściwych narzędzi, opieranie się na gotowych bibliotekach, które niekoniecznie muszą być dobrze napisane i rozwiązywanie błahych problemów z optymalizacją przez użycie mocniejszego i szybszego układu. Amerykanie mówią: "Gdy jedynym narzędziem, jakie masz jest młotek, wszystko zaczyna wyglądać jak gwoździe". I to jest problem dość poważny, niezwiązany z platformą, lecz znajdujący się między komputerem, a krzesłem. Stare komputery zmuszały programistów do myślenia i szukania optymalizacji. Ba, były one sprzedawane jako platformy edukacyjne, a nie tylko jako maszynki do gier. Dlatego w zestawie był podręcznik użytkownika, którego większość była poświęcona tajnikom programowania i samej platformy. Tego właśnie brakuje współczesnym platformom, które dążą do upraszczania wszystkiego.

    Dlatego proponuję wszystkim przywiązanym do Pythona i Arduino, by otworzyli skrzynki narzędziowe i poszukali czegoś więcej, niż młotki. Warto się uczyć czegoś nowego, bo im więcej wiemy, tym łatwiej ta nauka nam idzie i tym łatwiej idzie nam rozwiązywanie problemów. Jasne, to wymaga wysiłku i samozaparcia, ale takie jest życie.


    Języki programowania, które warto znać

    Skoro piszę, że trzeba uczyć się innych języków, to wypadałoby napisać, które z nich polecam. Pamiętajcie, że to tylko moja opinia, i nie oczekuję, że będziecie się z nią zgadzać. Ba, jeśli się nie zgadzacie, napiszcie, dlaczego i jakie są Wasze propozycje.

    Aha, nauka każdego kolejnego języka przychodzi łatwiej, bo w praktyce większość z nich ma wspólne korzenie i podstawy.

    C/C++

    Języki polecane przeze mnie głównie dla tych, co myślą o programowaniu mikrokontrolerów. Przez dekady C i C++ były językami do pisania systemów operacyjnych, aplikacji i sterowników. Obecnie używane są również do programowania mikrokontrolerów. Arduino używa C++ z pewnymi rozszerzeniami specyficznymi dla tej platformy. Dla ośmiobitowych i szesnastobitowych mikrokontrolerów Microchip ma kompilatory używające C, dla 32-bitowych dostępne są kompilatory C++ oparte o GCC.

    Warto opanować C/C++, ale trzeba to robić odpowiednio. Mikrokontrolery nie mają za dużo zasobów, dlatego odpowiednim stylem będzie programowanie funkcjonalne. Odchodzi się już od programowania obiektowego, a dla mikrokontrolerów ten styl może być zbyt zasobożerny, zwłaszcza że jedynym sposobem, by sprawdzić co kompilator robi z tymi obiektami, klasami i metodami, jest sprawdzenie pośredniego kodu w Assemblerze.

    Trzy ważne uwagi (nie tylko do pisania w C/C++):

    1. Funkcje nie powinny zajmować więcej, niż jeden ekran tekstu. Długie funkcje warto rozbić na mniejsze kawałki. Kompilator to i tak poskłada.
    2. Nazwy funkcji, obiektów, metod, klas, zmiennych i stałych powinny być sensowe i czytelne. Dobre IDE i tak zadba o autouzupełnianie długich nazw.
    3. Warto nabrać dobrych nawyków komentowania każdej funkcji, zmiennej czy stałej. Wbrew mitom kod nie jest swoją własną dokumentacją. Gdyby był, języki programowania nie miałyby funkcji dodawania komentarzy.

    Assembler

    Warto wiedzieć, co to jest i jak wygląda, i podejrzeć kawałki kodu by się z nim oswoić. Ale nie ma sensu uczenie się Assemblera i używanie go, nawet dla małych mikrokontrolerów. Tylko raz musiałem po niego sięgać, jak pisałem kod pozwalający na samoprogramowanie się mikrokontrolera - nie było gotowej funkcji w XC8, a sekwencja poleceń była czasowo krytyczna. Kod skopiowałem z noty katalogowej układu jako wstawkę.

    Java

    Przed Pythonem jednym ze wszędobylskich języków była Java. Java wciąż pozostaje jednym z topowych najpopularniejszych języków programowania. Java była czymś między Pythonem, a C++/C#. Jest wydajna jak języki kompilowane i bezproblemowo wieloplatformowa jak Python. Jak to zrobiono? Prosto: Java kompiluje się do strumienia bitowego, który jest wykonywany na wirtualnej maszynie. Otrzymujemy karę wydajności, ale jest ona niewspółmiernie mniejsza niż w przypadku Pythona. O potędze Javy niech świadczy fakt, iż w latach dwutysięcznych jedno z polskich studiów wydało dwie gry komputerowe napisane w Javie: Chrome i Xpand Rally. Dziesięć lat później powstała inna gra, która zdobyła niewielką popularność w pewnych kręgach. Nosi tytuł Minecraft. Słyszeliście o niej może?

    O wszędobylstwie Javy niech świadczy fakt, iż każdy smartfon i telefon komórkowy z ostatnich dwóch dekad z groszami ma ją na pokładzie, i to najczęściej w dwóch różnych wariantach. Każda karta SIM ma okrojoną wirtualną maszynę wykonującą różne małe programy, zgrupowane jako "Usługi Operatora". Drugi silnik to ten, który odpowiada za aplikacje i gry napisane w Javie dla telefonów i smartfonów sprzed dekady lub dwóch. Android wspiera Javę, i nawet iOS może z niej korzystać, choć w opinii developerów to trochę skomplikowane wyzwanie.

    Dlatego, moim zdaniem, Java jest lepsza od Pythona, i każdy tworzący programy dla platform w rodzaju Raspberry Pi czy na komputery PC powinien używać Javy zamiast tej powolnej alternatywy. Opcjonalnie sprawdzi się też C++ albo Rust.

    Tercet egzotyczny: Lua, Python, Go i Rust

    Język skryptowy używany przez NodeMCU. Znajdziemy go też w modzie ComputerCraft do gry Minecraft. Warto go poznać choćby dla łatwego używania ESP8266.

    Sporo marudziłem na Pythona, ale mimo wszystko warto się z tym językiem zapoznać. Wiele programów używa go jako języka skryptowego i do pisania wtyczek, ponadto może się przydać do pisania drobnych, prostych skryptów czy małych programów. Ale nie piszcie na nim nic większego, niż 500-1000 linijek kodu. Naprawdę nie warto. To nie jest język do ciężkich i wymagających zadań.

    Go, to język uczący przetwarzania równoległego. Nie jest trudny, choć ma swoje drobne dziwactwa. Myślę, że mógłby zastąpić Pythona w wielu bieżących zastosowaniach oferując przy tym lepszą wydajność w zadaniach wielowątkowych. Dlatego warto go poznać choćby przez rzucenie okiem na podręcznik.

    Rust to nowy język programowania z nastawieniem na bezpieczeństwo, wydajność i przetwarzanie równoległe. Rust dostępny jest też dla różnych rodzin mikrokontrolerów, głównie ARM i MIPS. Inne mogą wymagać stworzenia własnej implementacji, co nie jest zadaniem dla początkujących. Początkowo Rust miał być językiem do pisania systemów operacyjnych i sterowników, ale obecnie można z nim robić dużo więcej. Warto się go nauczyć właśnie ze względu na powoli rosnącą popularność, wysoką wydajność i możliwość pracy wielowątkowej.


    A może po staremu?


    Jeśli pragniecie doświadczyć radości i smutków używania starego komputera do programowania, to są dwie sensowne drogi. Kupno starego komputera nie jest żadną z nich. Dlaczego? Z powodu wyjątkowo wysokiej ceny i licznych problemów sprzętowych. Zobaczcie sobie na kanał YT 8-Bit Guy, i obejrzyjcie kilka przykładowych filmów z remontów starych komputerów, by zobaczyć, jak to wygląda.

    Pierwsze sensowne rozwiązanie to użycie emulatorów. Każdy zabytkowy komputer ma ich kilka. Można raczej zapomnieć o dostępie do sprzętowych interfejsów, ale i tak można zrobić wiele, w tym napisać własną grę.

    Drugą opcją są komputery z serii MicroMite, oparte o mikrokontrolery PIC32 i ARM. Tu już znajdziemy sprzętowe interfejsy do wykorzystania, a program pisany jest w dialekcie BASICa, jak na starym komputerze. Imć 8-Bit Guy pracuje też nad sprzętową emulacją starych komputerów z wykorzystaniem nowych komponentów, co też będzie ciekawą opcją na przyszłość. Oczywiście,. to nie są tanie rzeczy, a ceny spokojnie przekraczają koszt przeciętnego SBC czy zestawu rozwojowego, ale i tak będzie taniej.

    Możecie też spróbować samodzielnie stworzyć retrokomputer. Niekoniecznie replikę czy emulację, ale coś swojego. Jak na przykład Big Mess O' Wires. Byłoby ciekawie zobaczyć, co czytelnicy Elektrody są w stanie wymyślić.


    A Wy jak myślicie? Lepsze są stare komputery czy współczesne platformy? Czego sami używacie, a czego chcielibyście spróbować? Zapraszam do dyskusji.

    Fajne? Ranking DIY
    O autorze
    Urgon
    Poziom 38  
    Offline 
  • #2 20477250
    Szyszkownik Kilkujadek
    Poziom 37  
    Bardzo ciekawy artykuł. Momentami kontrowersyjny, ale mam nadzieję że wywoła merytoryczną dyskusję.

    Sam jestem ciekaw czy w bliskiej przyszłości nie nastąpi regres do starszych platform.

    @Urgon a na czym byś postawił np. Home Assistant? Ma działać non stop, więc wymagany mały pobór prądu.
  • #3 20477305
    Urgon
    Poziom 38  
    AVE...

    To zależy, jaki poziom funkcjonalności chcesz mieć. Alexa po stronie urządzenia klienckiego to prosty SBC na ARM z układem WiFi i relatywnie prostą aplikacją, która przesyła dźwięk do farmy serwerów, która realizuje funkcję rozpoznawania mowy i dekodowania poleceń. Klient dostaje polecenia i je przekazuje dalej, czasem przez prosty system text-to-speech.

    Jeśli jednak chcesz mieć tylko kilka z góry zdefiniowanych poleceń, to możesz to zrobić nawet na ośmiobitowym mikrokontrolerze używając ukrytych łańcuchów Markowa. Microchip ma do tego bibliotekę i narzędzie do generowania nowych komend, ale chyba wciąż płatne. Inną drogą jest zostać z SBC, co nie pobierze więcej, jak 15W, i użyć systemu pracującego offline, choć pewnie będziesz musiał wytrenować model dla języka polskiego. Rzucałem na to okiem jako opcję do dyktowania artykułów, zamiast pisania...
  • #4 20478072
    pawelr98
    Poziom 39  
    Urgon napisał:
    Nosi tytuł Minecraft. Słyszeliście o niej może?


    Słyszałem, grałem (i to obficie, będąc w szkole średniej) i powiedzieć można tylko jedno, tragedia.
    Podstawowy problem, praca na jednym wątku i niesamowite wręcz problemy z kompatybilnością.

    Podstawowy problem ze starymi platformami, praca na szynie równoległej i związany z tym nakład pracy żeby uzyskać odpowiednie efekty.
  • #5 20478158
    lemgo
    Poziom 14  
    Trochę bzdury.

    Python jest kompilowany do kodu pośredniego. A Java jest kompilowana do kodu pośredniego. Oczywiście oba są inne, ale sam proces przebiega z grubsza podobnie. Proces dla obu języków jest bardzo dobrze udokumentowany.
    Kompilator Pythona ani kompilator Javy nie przeprowadza na tym etapie (w zasadzie) żadnych optymalizacji.

    Java potem, w runtime wykonuje optymalizację kodu. Najpierw kompilatorem C1 (jeśli konkretny fragment kodu wykona się bodaj 2.000 razy), potem kompilatorem C2 (po 15.000 wykonań), stale monitoruje wykonanie kodu i czasem kod deoptymalizuje i ponownie optymalizuje na podstawie zebranych danych. Z grubsza, bo na przykład maszyna ART na Androidzie robi to ciut inaczej.

    W pythonie można nawet ten kod pośredni samemu wygenerować, obejrzeć poszczególne instrukcje, popatrzeć na AST (Abstract Syntax Tree), bądź nawet zmodyfikować w trakcie wykonywania (są stosowne narzędzia w języku)
    W javie zresztą też (mniej więcej)

    Koncepcja pythona była taka, żeby zrobić narzędzie do sprawnego pisania skryptu/programu, nawet dużego. A potem kluczowe fragmenty napisać w C++ czy nawet w Fortranie. SciPy, numpy, pandas, open nlp (nie jestem pewny), tensroflow, pytorch są napisane w C++ (SciPy chyba najpierw było w fortranie) i mają bindingi do pythona. Wydajnościowo to są potwory, niektóre z nich prowadzą obliczenia na GPU (kartach graficznych), a python pozwala szybko je okiełznać

    ChatGPT chyba nie opublikował danych ile z jego kodu jest napisane w C++

    ---

    A i jeszcze: z tym Linuxem i procesorami Intela to autor trochę popłynął.

    Po pierwsze - nie jest tak, że jedną instrukcję Intela trzeba zastąpić setkami(!) instrukcji ARMa. Kompilator (C bądź C++) niczego nie zastępuje, emisja kodu i optymalizacje są robione pod konkretny procesor.

    A Linux i ARM? No cóż. Na samym spodzie każdego smartfona z Androidem (oraz telewizora z Tizenem) stoi poczciwy Linux, z jego Linuxowym kernelem i na ARMowej platformie daje radę.
  • #6 20478957
    Mlody_Zdolny
    Poziom 30  
    lemgo napisał:
    Trochę bzdury.

    Python jest kompilowany do kodu pośredniego. A Java jest kompilowana do kodu pośredniego.

    Intencje pewnie miałeś dobre ale też wyszły trochę bzdury :)
    Ogólnie to zgadzam się i mam podobne odczucia, @Urgon płynnie przechodzi od Basica z czasów ośmiobitowców do ChatGPT, co przypomina raczej pogaduszki u kosmetyczki niż analizę obecnego zaawansowania w świecie software.
  • #7 20478997
    khoam
    Poziom 42  
    Mlody_Zdolny napisał:
    płynnie przechodzi od Basica z czasów ośmiobitowców do ChatGPT, co przypomina raczej pogaduszki u kosmetyczki niż analizę obecnego zaawansowania w świecie software.

    W 100% zgadzam się z tym stwierdzeniem. Poziom niekompetencji autora tego artykułu wręcz poraża.
  • #8 20479070
    elektryku5
    Poziom 39  
    Urgon napisał:
    Może jakbym kupił jakiś SBC oparty o architekturę X86-64, a nie ARM, najlepiej z 4-8GB RAMu i innym nośnikiem systemu, niż karta microSD, to coś by się ugrało. Ale to już kosztuje tyle, co budżetowy laptop czy komputer stacjonarny bez wodotrysków.


    Używany terminal sieciowy to koszt mniejszy niż obecnie RPi, a możliwości dużo większe (o ile ktoś nie potrzebuje GPIO).
  • #9 20479119
    Urgon
    Poziom 38  
    AVE...

    pawelr98 napisał:
    Urgon napisał:
    Nosi tytuł Minecraft. Słyszeliście o niej może?


    Słyszałem, grałem (i to obficie, będąc w szkole średniej) i powiedzieć można tylko jedno, tragedia.

    Obacz zatem bardziej współczesną wersję. Wiele poprawiono, i nawet po dodaniu dziesiątków modów gra działa wcale nieźle na współczesnym sprzęcie.

    pawelr98 napisał:
    Podstawowy problem, praca na jednym wątku i niesamowite wręcz problemy z kompatybilnością.

    Z pracą jednowątkową to prawda, ale to dlatego, że Java powstawała wtedy, gdy większość procesorów była jednordzeniowa i jednowątkowa. Co do problemów z kompatybilnością, to też się spotkałem z takimi opiniami - 15-20 lat temu. Jak teraz jest, to nie wiem, ale chyba trochę lepiej, biorąc pod uwagę, że od lat jest w topce najpopularniejszych języków programowania.

    pawelr98 napisał:
    Podstawowy problem ze starymi platformami, praca na szynie równoległej i związany z tym nakład pracy żeby uzyskać odpowiednie efekty.

    Głupoty mawiasz. Praca z szynami równoległymi pozwala na transfer informacji w jednym cyklu zegara, dlatego wewnętrznie wszystkie mikrokontrolery mają budowę równoległą. Wszystkie komponenty zarówno w tych starych komputerach, jak i we współczesnych maszynach są zaprojektowane do pracy równoległej - vide gniazda pamięci RAM i interfejsy PCI i PCI-E. Na potrzeby interfejsów szeregowych są dedykowane konwertery w formie wewnętrznych struktur w chipsetach lub specjalizowanych układów scalonych.

    Rozumiem jednak, że w dobie I2C, SPI, UART, CAN i USB interfejsy równoległe mogą wydawać się toporne i trudne, a prowadzenie ścieżek na PCB stanowi drobne wyzwanie. Ale historycznie i współcześnie forma równoległa jest zwyczajnie szybsza i wydajniejsza.


    lemgo napisał:
    Trochę bzdury.

    Nawzajem.

    lemgo napisał:
    Python jest kompilowany do kodu pośredniego. A Java jest kompilowana do kodu pośredniego. Oczywiście oba są inne, ale sam proces przebiega z grubsza podobnie. Proces dla obu języków jest bardzo dobrze udokumentowany.

    Python jest językiem interpretowanym, bo kompilacja JIT działa inaczej w jego przypadku, niż w przypadku Javy. Java kompiluje swój kod do strumienia binarnego wykonywanego na wirtualnej maszynie Javy (JVM), a przez inną budowę samego języka, robi to bardziej optymalnie i zmniejszą ilością "śmieci".

    lemgo napisał:
    Kompilator Pythona ani kompilator Javy nie przeprowadza na tym etapie (w zasadzie) żadnych optymalizacji.

    Ekhm...

    Cytat:
    The JVMs JIT compiler is one of the fascinating mechanisms on the Java platform. It optimizes your code for performance, without giving away its readability. Not only that, beyond the “static” optimization methods of inlining, it also makes decisions based on the way that the code performs in practice.

    Przy okazji Python w testach jest wolniejszy nie tylko od wszystkich języków kompilowanych, ale też od Javy i JavaScript. I ja sobie tego nie wymyślam.

    lemgo napisał:
    Java potem, w runtime wykonuje optymalizację kodu. Najpierw kompilatorem C1 (jeśli konkretny fragment kodu wykona się bodaj 2.000 razy), potem kompilatorem C2 (po 15.000 wykonań), stale monitoruje wykonanie kodu i czasem kod deoptymalizuje i ponownie optymalizuje na podstawie zebranych danych. Z grubsza, bo na przykład maszyna ART na Androidzie robi to ciut inaczej.

    Czyli sam potwierdzasz, że jednak optymalizacja ma miejsce. BTW, Python chyba tego nie robi, prawda?

    lemgo napisał:
    W pythonie można nawet ten kod pośredni samemu wygenerować, obejrzeć poszczególne instrukcje, popatrzeć na AST (Abstract Syntax Tree), bądź nawet zmodyfikować w trakcie wykonywania (są stosowne narzędzia w języku)
    W javie zresztą też (mniej więcej)

    Tego akurat nie wiedziałem. Czy ktoś z tego w ogóle korzysta? Myślę, że raczej tylko bardzo zaawansowani programiści i developerzy.

    lemgo napisał:
    Koncepcja pythona była taka, żeby zrobić narzędzie do sprawnego pisania skryptu/programu, nawet dużego. A potem kluczowe fragmenty napisać w C++ czy nawet w Fortranie.

    I jako język skryptowy Python jest dobry, choć trochę wolny. Problem w tym, że nikt potem nie przepisuje go na C++, Fortrana czy cokolwiek innego. Są narzędzia konwertujące kod, ale z tego co widziałem to nie są tak dobre, jak napisanie całości od zera.

    lemgo napisał:
    SciPy, numpy, pandas, open nlp (nie jestem pewny), tensroflow, pytorch są napisane w C++ (SciPy chyba najpierw było w fortranie) i mają bindingi do pythona. Wydajnościowo to są potwory, niektóre z nich prowadzą obliczenia na GPU (kartach graficznych), a python pozwala szybko je okiełznać

    Wspomniałem o SciPy i NumPy przy bCNC. Dały nieduży skok wydajności, bo reszta tej aplikacji wciąż używa Pythona.

    lemgo napisał:
    ChatGPT chyba nie opublikował danych ile z jego kodu jest napisane w C++

    Chwalą się, że całość jest napisana w Pythonie. Jasne, na pewno są tam biblioteki pisane w C++ czy w innych językach, ale to nie oni je pisali. Piszesz, że SciPy i NumPy to potwory wydajności. Jak bardzo wydajny byłby ChatGPT napisany w całości w C++, albo w Rust czy innym języku dostosowanym do pracy wielowątkowej?

    lemgo napisał:
    A i jeszcze: z tym Linuxem i procesorami Intela to autor trochę popłynął.

    W nienawiści i pogardzie do Linuxa wychowany byłem...

    lemgo napisał:
    Po pierwsze - nie jest tak, że jedną instrukcję Intela trzeba zastąpić setkami(!) instrukcji ARMa. Kompilator (C bądź C++) niczego nie zastępuje, emisja kodu i optymalizacje są robione pod konkretny procesor.

    Okej, ale procesory ARM nie mają tych fajnych operacji, które posiadają procesory X86 od czasów Pentium MMX, czyli właśnie MMX. To jest wąskie gardło. Drugim jest problem ze sterownikami GPU, które są zamknięte (i chyba pisane na kolanie, z tego co "na necie gadajo"). Dlatego nie da się za bardzo odpalić jutuba na RPi 3, a przeglądarka ledwo działa - strony ładują się czasem minutami. I to właśnie te funkcje MMX zajmujące jedną instrukcję dla układów Intela czy AMD trzeba zamieniać na szereg mniejszych instrukcji ARM. Platforma jako codzienny komputer zwyczajnie nie ma prawa działać, nie teraz, gdy akceleracja GPU jest potrzebna do przeglądarki. Taka jest natura rzeczy.

    lemgo napisał:
    A Linux i ARM? No cóż. Na samym spodzie każdego smartfona z Androidem (oraz telewizora z Tizenem) stoi poczciwy Linux, z jego Linuxowym kernelem i na ARMowej platformie daje radę.

    Tak, bo dokonano szeregu modyfikacji pozwalających na odzyskanie wydajności. Plus, producenci smartfonów i tabletów mają dużo łatwiejszy dostęp do sterowników i ich dokumentacji, z czego skwapliwie korzystają. Korporacje nie mają problemu by podpisać NDA, podczas gdy developerzy ze świata OpenSource się tym wręcz brzydzą. I dlatego też RPi i podobne platformy dostają skompilowany sterownik wielkości dorodnego ziemniaka i niepełną dokumentację - producent boi się ujawnienia detali, bo też go obowiązują umowy NDA.


    @Elektryku5

    To problem okołopandemicznej posuchy na rynku komponentów elektronicznych. Jednak tempa produkcji RPi-killerów to nie zmniejszyło. Swego czasu myślałem o takim terminalu, ale i tak mam za dużo "gratów" i muszę się części pozbyć...
  • #10 20479130
    tronics
    Poziom 38  
    OrangePi 5 też dużo nie kosztuje, a możliwości ma ogromne. Zresztą jak ktoś ma RPi 4 1GB to jest w stanie przy odrobinie umiejętności przerobić prosto na 8GB i sprzedać z niezłą przebitką ;) Ale może do rzeczy.

    Cytat:
    Dlatego właśnie nie ma miesiąca na Elektrodzie, by w newsach nie pojawiły się przynajmniej trzy takie komputery. Warto do nich podchodzić z dużą dozą sceptycyzmu, i sprawdzić poziom wsparcia, zanim wybierze się jakąś alternatywę do RPi.

    Po pierwsze popularne przez lata były 3 rodziny układów (poza broadcom) - amlogic, rockchip i allwinner. Peryferia i GPIO były - od strony samego systemu - obsługiwane identycznie jak te w Raspberry. To, że Raspberry przychodziło z bibliotekami typu WiringPi i zilionem różnych przykładów to odrębna sprawa. Jeśli się korzystało z SPI czy I2C bezpośrednio pod systemem to zasadniczo żadnej większej różnicy nie było. Ale i do takich wynalazków ostatecznie dorabiano libsy, które miały zapewnić w miarę rozsądne wsparcie (np. WiringOP dla OrangePi). Jeśli chodzi o coś innego niż machanie pinami, np. obliczenia - to tutaj alternatywne systemy z reguły wysuwały się na prowadzenie. Tak samo jeśli chodzi o bogactwo różnych złącz. Jedyna konkretna zaleta RPi to solidne wsparcie producenta oraz zgrane środowisko użytkowników. Jak ktoś wie co robi to zrobi to na dowolnym "klonie" Raspberry. A jak ktoś nie wie to zawsze będzie uwiązany do jedynie słusznej marki z przykładami, które tylko na niej będą poprawnie działać. Nie inaczej jest z Arduino, ale tutaj akurat jednak zewnętrzne wpływy alternatywnych h/w mają się dość dobrze. Upgrade z 8bit na 32bitowe ARMy można było zrobić na oficjalne SAM albo na mniej oficjalne STM32 i trzeba się było zmierzyć z podobnymi problemami braku pełnej kompatybilności z młodszym bratem. I znów - jak ktoś wie co robi to sobie poradzi i z SAM, i z STM, i z ESP, i z nRF i z jakąkolwiek inną platformą która będzie miała swój "core". Nawet jeśli nadal nie ogarnie samego sprzętu z owych MCU/SoC niskopoziomowo. Na tym polega warstwa abstrakcji. Ta warstwa którą w dawnych komputerach ukrywano pod postacią np. Basica.
  • #11 20479149
    Mlody_Zdolny
    Poziom 30  
    Urgon napisał:
    Z pracą jednowątkową to prawda, ale to dlatego, że Java powstawała wtedy, gdy większość procesorów była jednordzeniowa i jednowątkowa.

    Java od wersji 1.0 posiada obsługę wielowątkowości, patrz interfejs Runnable i klasa Thread. To, że jakiś program jest jednowątkowy, wynika z pracy programistów.
    I nie mieszaj wielowątkowości z multiprocesorowością, bo to dwie różne, aczkolwiek pokrewne w pewnym sensie pojęcia.
  • #12 20479155
    elektryku5
    Poziom 39  
    tronics napisał:
    Jak ktoś wie co robi to zrobi to na dowolnym "klonie" Raspberry.


    I tak i nie, bo jak wsparcie danego SoC w kernelu jest znikome, to trzeba się trochę nasiedzieć nad własną kompilacją.
    Niektóre moduły kernela z nowszymi wydaniami potrafią być bardziej popsute niż w starszych, co oczywiście nie ułatwia zadania.

    Także co zaoszczędzimy na zakupie mało znanej płytki, możemy z nawiązkom stracić na doprowadzenie jej do działania, no chyba że ktoś SBC stosuje w produkcji urządzeń, wtedy może mieć to sens.
  • #13 20479487
    khoam
    Poziom 42  
    Urgon napisał:
    Tak, bo dokonano szeregu modyfikacji pozwalających na odzyskanie wydajności. Plus, producenci smartfonów i tabletów mają dużo łatwiejszy dostęp do sterowników i ich dokumentacji, z czego skwapliwie korzystają. Korporacje nie mają problemu by podpisać NDA, podczas gdy developerzy ze świata OpenSource się tym wręcz brzydzą. I dlatego też RPi i podobne platformy dostają skompilowany sterownik wielkości dorodnego ziemniaka i niepełną dokumentację - producent boi się ujawnienia detali, bo też go obowiązują umowy NDA.

    Kompletna bzdura. Cały kernel linuxowy, również w wersji dla ARM i RPI jest w OpenSource, Mogę sobie samodzielnie skonfigurować i zbudować kernel np. dla RPI. Oczywiście buduję go wtedy na innej maszynie używając cross-kompilatora, bo jest po prostu znacznie szybciej i ze względu na ilość potrzebnej pamięci RAM zwykle wręcz niezbędne. Wszystkie sterowniki (w wersji źródłowej) dla RPI są już w stosownym repozytorium linuxa. To nie window$ dla "opornych", którzy trzymają się jedynej i słusznej kompilacji producenta.

    Dodano po 7 [minuty]:

    Urgon napisał:
    Arduino używa C++ z pewnymi rozszerzeniami specyficznymi dla tej platformy.

    Arduino Core nie używa żadnych "specyficznych" rozszerzeń języka C++. Arduino Core to zestaw bibliotek napisanych w języku C++. Obecnie w C++20 na większości wspieranych platform sprzętowych, poza AVR.

    Dodano po 6 [minuty]:

    Urgon napisał:
    Język skryptowy używany przez NodeMCU. Znajdziemy go też w modzie ComputerCraft do gry Minecraft. Warto go poznać choćby dla łatwego używania ESP8266.

    Używanie "okrojonej" wersji pythona z ESP8266 jest IMHO nieco działaniem masochistycznym i przeznaczonym raczej dla studentów wydziałów nie-informatycznych np. AWF. Płytka NodeMCU to nic innego, jak jedna z wielu modeli płytek rozwojowych z ESP8266. Niczym się szczególnie nie różni np. od Wemos. Na obu można również programować w C/C++, z Arduino Core lub bez, a nawet w aseblerze.
  • #14 20479896
    lemgo
    Poziom 14  
    @Urgon

    O pythonie:
    stąd: https://docs.python.org/3/glossary.html#term-virtual-machine
    "Python’s virtual machine executes the bytecode emitted by the bytecode compiler."
    Na polski: Wirtualna maszyna Pythona wykonuje kod bajtowy emitowany przez kompilator kodu bajtowego.

    A jakby napisać o javie, to wystarczy zamienić Pythona na Javy i będzie dobrze :P

    Więcej o bytecode pythona na przykład tu: https://www.goldsborouh.me/python/low-level/2...10/04/00-31-30-disassembling_python_bytecode/

    I może pokażę jak to wygląda:

    Kod: Python
    Zaloguj się, aby zobaczyć kod


    jest kompilowane do (python 3.9):
    
    x = 5
                  0 LOAD_CONST               1 (5)
                  2 STORE_FAST               0 (x)
    y = 7
                  4 LOAD_CONST               2 (7)
                  6 STORE_FAST               1 (y)
    return x + y
                 8 LOAD_FAST                0 (x)
                10 LOAD_FAST                1 (y)
                12 BINARY_ADD
                14 RETURN_VALUE
    


    Nie, to nie jest kod interpretowany
    Takie coś (bytecode) jest przekazywane do wirtualnej maszyny pythona.

    O javie:

    A taki kod

    Kod: Java
    Zaloguj się, aby zobaczyć kod


    jest kompilowany do (java 17):
    
      int bar();
        Code:
           0: iconst_5
           1: istore_1
           2: bipush        7
           4: istore_2
           5: iload_1
           6: iload_2
           7: iadd
           8: ireturn
    


    Takie coś (bytecode) jest przekazywane do wirtualnej maszyny javy.

    Zwracam uwagę, że nie ma tu grama optymalizacji, nawet próby inline. Nie będę się rozwodził nad powodami, dla których tu nie ma optymalizacji, zachęcam do przemyślenia

    -------

    Ani jeden, ani drugi nie jest interpretowany. Żaden nie jest jakoś bardziej rozwlekły.

    W pythonie: kod nie jest optymalizowany, dlatego warto się wesprzeć C++ przy wymagających fragmentach

    W javie JIT (Just In Time Compiler, kompilacja we właściwym momencie) wchodzi do akcji, gdy kod jest wykonywany często (wspomniałem, 2.000 albo 15.000 razy). Pierwsze podejście jest po 2000 - wtedy jest mechanicznie tłumaczony do ELF (kodu maszynowego, kompilator C1). A po 15.000 - kompilator C2, z optymalizacją
    Dla ART (Android) albo GraalVM - faza C1 jest wykonywana od razu, C2 - też w nieco innych okolicznościach

    --------

    O ChatGPT. Może przytoczę moją rozmowę z ChatGPT :) Skrót
    
    W jakim języku jest napisany ChatGPT?
    
    ChatGPT jest napisany w języku Python z wykorzystaniem biblioteki OpenAI. Wykorzystuje ona specjalistyczne algorytmy uczenia maszynowego [...]
    
    W jakim języku jest napisana biblioteka OpenAI?
    
    Biblioteka OpenAI jest napisana w języku Python. Jednakże, OpenAI korzysta również z innych języków programowania, takich jak C++, CUDA, JavaScript, TypeScript [...]
    


    Czyli podobnie jak większość systemów AI (tensorflow, pytorch): rdzenie CPU (C++) + rdzenie GPU (C++, CUDA)

    A python to tylko skleja

    Urgon napisał:

    Jak bardzo wydajny byłby ChatGPT napisany w całości w C++, albo w Rust czy innym języku dostosowanym do pracy wielowątkowej?

    No chyba nie przypuszczasz, że cały ChatGPT stoi na pojedynczym komputerku z jednym rdzeniem, bo python jest jednowątkowy? :)
  • #15 20479942
    Mlody_Zdolny
    Poziom 30  
    Urgon napisał:
    ChatGPT jest pisany w Pythonie, bo byłoby za dużo zachodu z przepisaniem go na bardziej optymalny język, zwłaszcza język kompilowany. za to 5-10krotny skok wydajności by ten "zachód" teraz usprawiedliwił, gdyby komuś się chciało to zrobić.

    @Urgon z takimi pomysłami możesz śmiało startować do OpenAI, widełki zaczynają się od 200 tys. USD rocznie.
  • #16 20479985
    pawelr98
    Poziom 39  
    Urgon napisał:

    Głupoty mawiasz. Praca z szynami równoległymi pozwala na transfer informacji w jednym cyklu zegara, dlatego wewnętrznie wszystkie mikrokontrolery mają budowę równoległą. Wszystkie komponenty zarówno w tych starych komputerach, jak i we współczesnych maszynach są zaprojektowane do pracy równoległej - vide gniazda pamięci RAM i interfejsy PCI i PCI-E. Na potrzeby interfejsów szeregowych są dedykowane konwertery w formie wewnętrznych struktur w chipsetach lub specjalizowanych układów scalonych.

    Rozumiem jednak, że w dobie I2C, SPI, UART, CAN i USB interfejsy równoległe mogą wydawać się toporne i trudne, a prowadzenie ścieżek na PCB stanowi drobne wyzwanie. Ale historycznie i współcześnie forma równoległa jest zwyczajnie szybsza i wydajniejsza.


    Ale wszyscy możliwi producenci jakoś twierdzą inaczej i wyzbywają się ze swoich ofert podzespołów na szynie równoległej.

    Infineon daje gwarancję do 2030 na kostki flash i do 2031 na SRAM.
    Tak samo Renesas, chociaż oferuje MRAM, czyli taki "udziwniony" FLASH.
    Macronix lekko się wyłamuje, określając, że całe dwie kostki FLASH na cały katalog, będą dostępne aż do 2033.

    Tak samo procesory i cała reszta raczej nie bardzo będzie już pracować z interfejsem równoległbym.

    Problem szyny równoległej polega na tym, że im szybciej tym coraz trudniej to wszystko po pierwsze położyć na płycie, a po drugie obsłużyć.
    I producenci odkryli, już tak z ponad 20 lat temu, że szyny szeregowe to przyszłość, bo co prawda trzeba pracować szybciej żeby przesłać taką samą ilość danych, ale z drugiej strony szybsza praca przy mniejszej ilości linii jest łatwiejsza do uzyskania. Z rachunku zalet i wad, szyna szeregowa wygrała, co widzimy obecnie w komputerach i na całym rynku urządzeń wbudowanych.

    Więc w praktyce ukatrupia się całą ideę szyny równoległej, przynajmniej w tradycyjnym rozumieniu. Z szyną danych i adresową. QSPI niby trochę wraca do idei, ale wydzielonej szyny adresowej tu nie ma.
  • #17 20480021
    tronics
    Poziom 38  
    Cytat:
    Praca z szynami równoległymi pozwala na transfer informacji w jednym cyklu zegara, dlatego wewnętrznie wszystkie mikrokontrolery mają budowę równoległą. Wszystkie komponenty zarówno w tych starych komputerach, jak i we współczesnych maszynach są zaprojektowane do pracy równoległej - vide gniazda pamięci RAM i interfejsy PCI i PCI-

    PCI-E to protokół szeregowy. To, że można ileś nitek naraz puścić jest zupełnie bez znaczenia. Sprzętowo to niezależne szeregowe transcievery. Gdyby pamięci mogły latać na 20GHz po wąskiej szynie to pewnie takie pamięci byłyby stosowane powszechnie zamiast kilkuset bitowych pamięci równoległych. Inna strona medalu to peryferia. Pociągnij 2 metry choćby 16 bitowego interfejsu o przepustowości USB 3 to pogadamy. Już pomijając koszty kabli, gniazdek oraz ilość zajmowanego miejsca.
  • #18 20483389
    fotomh-s
    Poziom 24  
    Urgon napisał:
    1. Funkcje nie powinny zajmować więcej, niż jeden ekran tekstu. Długie funkcje warto rozbić na mniejsze kawałki. Kompilator to i tak poskłada.

    Zależy jaki kto ma ekran ;-) A tak na poważnie to funkcje funkcjom nie równe. Jeśli ktoś korzysta np. z różnych specjalistycznych bibliotek to dana funkcja wymaga znacznie mniej pisania niż w przypadku ich braku. Ilość tekstu w kodzie źródłowym ma się więc nijak do rozmiaru kodu wynikowego.

    Urgon napisał:
    O potędze Javy niech świadczy fakt, iż w latach dwutysięcznych jedno z polskich studiów wydało dwie gry komputerowe napisane w Javie: Chrome i Xpand Rally. Dziesięć lat później powstała inna gra, która zdobyła niewielką popularność w pewnych kręgach. Nosi tytuł Minecraft. Słyszeliście o niej może?
    Z teksturami w rozdzielczości jak z pierwszych lat grafiki rastrowej i z sześciennymi bryłami jak z pierwszych eksperymentów z grafiką trójwymiarową? Od kiedy to o potędze świadczy jak najniższa rozdzielczość tekstur i jak najprostsze bryły?
  • #19 20486397
    KJ
    Poziom 31  
    Też strasznie nie lubię Arduino - czego by nie poszukać to pierwsze X stron wyników w goglu to Arduiniarstwo nie wnoszące niczego konkretnego do rozwiązania problemu który akurat mam do rozwiązania :P W dodatku ten ekosystem wydaje się być tak skonstruowany aby użytkownik nigdy nie dowiedział się o istnieniu innych rozwiązań. Robienie na tym rzeczy których się kategorycznie nie powinno to inna kwestia. Oczywiście istnieją także ciekawe i porządnie napisane projekty stworzone w tym środowisku tak wiec osobiście uważam "arduino" raczej za stan umysłu niż środowisko programistyczne ;) Sam zmarnowałem ~20 lat życia na bascom bo wydawało mi się że inne języki są za trudne/niekoniecznie ich potrzebuję. To samo robią obecnie użytkownicy arduino i pythonów tylko bardziej - bascom wymagał chociaż minimum wiedzy o hardware. ESP - śmiesznie tanie układy o całkiem przyzwoitej mocy obliczeniowej jak na cenę i rozmiary - osobiście zdarza mi się używać gotowców ale sam jeszcze nie próbowałem nic pisać na to bo albo arduino ide albo męcz się z konfiguracją innego toolchaina ewentualnie jest jeszcze platformio ale chyba nadal wolę wziąć inny mikrokontroler. Moim osobiście ulubionym jest Psoc5 od dawnego cypresa a obecnie Infineona. Z nowości próbowałem trochę ruszyć STM32 ale mi nie idzie albo próbuję zbyt zaawansowanych tematów na pierwszy projekt. Z grubszych tematów zamówiłem sobie ostatnio płytkę z Zynq od Xilinxa na pokładzie ale chyba jeszcze nie mój poziom acz sam układ bardzo ciekawy.
  • #20 20486748
    TechEkspert
    Redaktor
    Zobaczcie jak AI porównało stare komputery Arduino i SBC: https://www.elektroda.pl/rtvforum/topic3964192-1350.html#20486606
    a tutaj stara się oszacować ile trwałoby brutforcowanie Enigmy gdyby Turing miał SBC Raspbery Pi: https://www.elektroda.pl/rtvforum/topic3964192-1380.html#20486657

    Ciekawa zabawa z 2xArduino i BASIC, właściwie powstało coś w rodzaju Commodore PET?


  • #21 20489801
    tronics
    Poziom 38  
    Cytat:
    Moc obliczeniowa Arduino Uno wynosi około 16 MHz

    Cytat:
    Moc obliczeniowa Amigi 600 wynosiła około 1,4 miliona OPS

    Yhym... Gdyby jechać po DMIPS to wyniki mogłyby być trochę bardziej reprezentatywne. Np. taki 68000 miał ok 0,2DMIPS/MHz (czyli dla 7MHz to 1,4DMIPS) a Cortex M0 ma zdaje się w okolicach 0,9DMIPS/MHz co dla 32MHz daje niecałe 30. Dla maszyn 8 bitowych nie bardzo jest chyba nawet sens sprawdzać. Z drugiej strony takie porównania są do niczego, bo blitter w A500/600 mógł wykonywać szybko operacje logiczne na blokach pamięci, szybciej niż zrobiłby to programowo 68000 7MHz, a robił to poniekąd niezależnie od procesora (kontroler pamięci pracował 2x szybciej niż potrzebował CPU więc co drugi slot dostępu był dedykowany do chipsetu). Więc w zastosowaniach do jakich był zaprojektowany wydajność była zdecydowanie większa niż wynikałaby z samego procesora. Niemniej - nikogo raczej dziwić nie powinna różnica 24MHz 8051 (12 taktowego) do 24MHz AVR8, a tym bardziej 24MHz CortexM0, a względem tego ostatniego nikogo nie powinna dziwić różnica do Cortex A72 1.8GHz (albo Cortex A76 z RK3588). Tylko czy Broadcom albo Rockchip szybciej macha GPIO niż te mikrokontrolery? Ma szybsze I2C albo UART? Jesteśmy - programując pod linux - absolutnie pewni w jakim czasie stan pinów się zmieni? Albo w jakim czasie układ zdąży obsłużyć przerwanie? No tak, nie samymi mipsami człowiek żyje.
  • #22 20566321
    titako
    Poziom 13  
    Cytat:
    dedykowane układy audio i video i bardzo dobry interpreter BASICa

    Tu trochę autor odleciał - C64 miał najbardziej ubogi interpreter - świadczy o tym fakt, iż jak ktoś chciał pobawić się grafiką potrzebował nakładek typu SIMONS BASIC (chyba że zadowalała kogoś grafika ASCII)
    A w ATARI XL/XE czy ZX Spectrum 48 (itp.) instrukcje te były dostępne od ręki.
    Dopiero wersja Commodore BASIC 3.5 (w C64 była 2.0) wprowadza komendy typu CIRCLE czy DRAW - Ale te wersję implementowano w późniejszych, i co zabawne gorszych (tańszych) modelach - C16,C116 czy Plus/4
  • #23 20566369
    snow
    Poziom 31  
    I tak w ostatecznym rozrachunku liczy się efekt. Nie ważne na czym (czy Arduino które notabene jest tylko platformą i środowiskiem opartym na zwykłym 8-bit AVR, czy STM32) i w jakim języku napisano kod jeśli urządzenie które jest projektowane działa poprawnie. Wybór platformy powinien być dostosowany do zapotrzebowania konkretnej aplikacji i nie ma tu znaczenia czy zrobimy to na '51 czy na ESP32 jeśli całość spełnia stawiane przed danym urządzeniem wymagania.
  • #24 20566387
    Urgon
    Poziom 38  
    AVE...

    Bardziej zaawansowane funkcje wymagają więcej pamięci w ROMie. Sinclair mógł sobie na nie pozwolić, bo ZX Spectrum był tani w produkcji i biedny w sprzęcie. W jego przypadku to właśnie oprogramowanie "robiło robotę". Z kolei Atari 800XL pojawił się w roku 1983, rok po C64. XE to rok 1987. Ta różnica w wieku przyczyniła się do niższej ceny pamięci, więc można dodać rozbudowane funkcje dodatkowe. Dalej, instrukcje typu CIRCLE czy DRAW to instrukcje wektorowe, które musiały nie tylko obliczyć dany kształt matematycznie, ale także skonwertować grafikę wektorową na rastrową. Bez żadnego koprocesora matematycznego czy akceleratora graficznego. Obliczeniowo to trochę kosztuje, przez co te funkcje są dość wolne...
  • #25 20567149
    titako
    Poziom 13  
    1. Mimo różnicy lat między XL a XE to ten sam komputer z takim samym (z drobnymi poprawkami) systemem i zawartością ROM'u. Były też układowe różnice - ale te bardziej związane było z optymalizacją konstrukcji i nie miały wpływu na możliwości/parametry sprzętu.
    2. To nie kwestia bardziej skomplikowanych obliczeń - to oszczędność pieniędzy XD - Tramiel po prostu kazał przenieść BASIC z starszego Commodore PET - który wcale nie miał grafiki - tylko tryb znakowy.
  • #26 20567191
    tronics
    Poziom 38  
    @titako - tak średnio. O ile PET zaczynał z 1.0 i wkrótce miał 2.0 to doszedł aż do 4.0 ;) A C64 tkwiło w 2.0 bo Tramiel uznał, że komputer do domu (i głównie do grania) więcej nie potrzebuje. I zasadniczo miał rację. Oczywiście, że funkcje rysujące były zasobożerne, tylko PLUS/4 czy C128 dalej działały na starym dobrym 6502 (no, kolejnej jego wariacji). C128 mógł co prawda działać 2x szybciej, ale ztcp tylko bez ekranu z VICa. C16/116 i PLUS/4 gdy TED rysował to miały nawet mniej niż 1MHz (0,88). Ogółem lipton.

Podsumowanie tematu

Dyskusja dotyczy porównania starych komputerów z nowoczesnymi platformami jednopłytkowymi (SBC) i płytkami rozwojowymi, takimi jak Raspberry Pi, Arduino i NodeMCU. Uczestnicy wymieniają swoje doświadczenia z programowaniem w różnych językach, takich jak C++, Python, BASIC, oraz omawiają zalety i wady obu typów sprzętu. Wskazują na problemy ze starymi platformami, takie jak praca na jednym wątku i problemy z kompatybilnością, a także na ograniczenia wynikające z architektury szyn równoległych. Wspomniano również o nowoczesnych rozwiązaniach, takich jak OrangePi, które oferują większe możliwości w porównaniu do Raspberry Pi. Dyskusja porusza także kwestie związane z wydajnością, optymalizacją kodu oraz różnicami w obsłudze peryferiów.
Podsumowanie wygenerowane przez model językowy.
REKLAMA