AVR po latach

Nie. Zawachałem się czy napisać "Niestety".

Słusznie. Ale przez ostatnich 25 lat doświadczenia ręcznej kompilacji tysięcy projektów w różnych językach i ich późniejszego testowania zawsze jakoś tak wychodziło, że jak coś było w C++ to zawsze startowało dłużej i zżerało zasoby. Oczywiście można to uciąć argumentem porównawczym jakim teraz próbujesz. Można. W takim razie chciałbym w końcu przed śmiercią zobaczyć jakieś pełen user space (desktop+browser+cokolwiek) działający szybko, resposnywnie i bez zżerania zasobów, tak żebym przed tym klęknął z podziwem.

Ok, tylko moje doświadczenia, na których oparłem swoją wypowiedź to tak z poza embedded. Na razie z ostrożności procesowej nie krytykuję C++ w embedded. Zobaczymy jak to dalej pójdzie.

Czyli nie masz porównania. Porównujesz tak naprawdę *postęp* to tego co

*było*. Gdyby ten postęp bazował na Delphi, było by takie samo narzekanie na wydajność Delphi. A ono niewiele winne.

Wzrost wydajności CPU i GPU spowodował że dzisiaj każde okienko jest/może być przezroczyste. To, tak na oko, kilkanaście razy więcej obliczeń wymaganych do jego wyświetlenia.

To wina C++ ze trzeba więcej liczyć, aby ładniej wygladało? Jesteś pewny, że znalazłeś prawdziwego winowajce? Nie sa to aby przypadkiem atechniczni userzy, którzy uważają że szczytem rozwoju technologicznego jest animowana, półprzezroczysa, rozmyta gauusowsko belka okna?

Jakosć kodu w ogóle, nie tylko w C++, spada na pysk. Wynika to z optymalizacji biznesowych z okolic "można mieć taniej, jeśli nie będzie optymalnie". Dotyczy to wszystkich możliwych dziedzin IT i nie ma w tym nic dziwnego, powodem jest wolny rynek, który toleruje dziadostwo. Tak samo jak toleruje chińskie parasolki które łamia się przy lekkim dmuchnięciu. I ludzie nadal kupują.

C++ jest jednym z najszybszych języków do pisania blisko sprzetu. Jest tam niewiarygodnie dużo histów dla kompilatora, pozwalajacych optymalizować detalicznie, blisko kodu maszynowego. Jest masa jezykó znacznie gorszych i popularniejszych od niego. Jak choćby gówniany JavaScript, który odpowiada za 90% wqrwu w internecie i nie wykluczone, że w KDE.

W momencie kiedy piszesz "To czemu 99% softu napisanego w C++ dziala wolno?" bierzesz na siebie odpowiedzialność za stwierdzenie, że to wina C++. Najwidoczniej przeprowadziłeś dogłębne badania i okazało się, że to język jest winień, nie złożonośc problemu, kiepscy programiści, tylko język właśnie.

Co jest oczywistą nieprawdą.

Wiec będziesz miał duży kłopot utrzymać tezę: "to wina C++".

Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który wykona się wolniej i dlaczego?

To nie *ja* porównuje C++ to reszty świata. Ja mogę co najwyżej wyjasnić, że C++ jest tak samo szybki jak C. Czy uważasz, że C jest wolny? I względem czego jest wolny?

Prawie 100% problemów z prędkoscią jezyka programowania wynika z gównianej jakosci programisty.

Nie dotyczy JavaScriptu. Tam wszystko jest do dupy, język i programiści na raz.

Nikt go nie potrzebuje. OSy będą tak szybkie, jak tylko możliwe, ale nie szybsze niż granica "wkurwienia na obecnej wydajności hardware". Każde przyśpieszenie sprzętowe jest natychmiast konsumowane przez dodatkowe ficzery, potrzebne debilom, jak kolorowe animowane przyciski.

Czasy szybkich, pisanych optymalnie GUI, zniknęły razem z Amigą.

Tak, Amiga miała *obiektowe* GUI.

A ten JS to uruchamiany jest przez soft napisany w czym? :)

Nie, oczywiście z powodu braku porównania aż tak daleko się nie posuwam.

Wydaje mi sie, że nie zrozumiałeś o czym mówię. Ja nie krytykuję C++. Ja tylko krytykuję to, co w nim jest napisane i dlaczego źle.

Krytukujesz "dlaczego 99% doftu w C++" jes krytyką języka.

To można powiedzieć o dowolnym innym języku. Pisaniem programów nie zajmują się obecnie algorytmicy, tylko w większości niedzielni programiści. Ssanie na rynku jest takie, że do pisania w Node.js bierze się tumanistów po tygodniowym kursie. Efekty widzisz w postaci strony wyśietlającej dwa obrazki i napis, zjadającej 100% CPU itp.

A kodzie maszynowym. W gruncie rzeczy.

Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++. Przykład zły, bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu języków. Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby proces zajął min 2GB ram. ;)

?? Ja krytykuję jakość softu. Tak się składa, że najczęściej używane nacodzień jest w C++. Piszcie porządnie, wtedy krytyki nie będzie.

Ale jakoś C++ obrywa najwięcej za wszystkie.

Chyba maszyny do pisania.

Piszemy porządnie. Ale nie wszyscy.

Nie zauważyłem. Być może tylko Ty jesteś tym tłumem krytykującym C++ za wydajność.

Jeden z nich na pewno jest.

Na tym polega proble m ludzi związanych z embedded. Wydaje im się, w swojej ignorancji, że kod C++ to biliardy klas, i eniony templejtów.

Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język

*bardzo* przydatnym w embedded, bez narzutu wydajności.

To dalej oznacza, że jeden z nich na pewno jest w C++.

To jest właśnie opinia niedzielnego programisty embedded o C++. Z nią walczę.

Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z

*klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.

To tylko taki żart, że wydajność JS jest niby z winy embedowania go do C++.

Wszystko jest embedowane do kodu maszynowego, na końcu. To on jest wszystkiemu winien.

Pozwol ze sie wlacze sie w dywagacje. Problem tutaj jest nie w tym co moze zrobic C++ i C albo asembler tylko w tym co ludzie sobie pisza. Jeden mowi ze C++ to kobyla a drugi mowi ze nie bo on robi w C++ i programy mu wychodza nieduze. Jeden mowi ze arduino to gówno bo cos tam zmontowal i mu pamieci zabraklo albo sie sypalo a drugi powie ze on zrobil co innego, uzyl innych bibliotek i mu dzialalo dlugo, wydajnie i stabilnie.

Problem jest w tych generalizacjach. Zeby temat wyjasnic trzeba by to samo zagadnienie zaimplementowac w obu srodowiskach, porownac kod wynikowy i stabilnosc/szybkosc dzialania. Nikt tego nie zrobi, klocic mozna sie tedy do zarzygania.

I druga uwaga: Sporo softow dzis jest powolna nie dlatego ze jest obiektowa czy napisana w kompilatorze takim czy owakim tylko dlatego ze albo jest okrutnie skomplikowana albo zbyt wiele procesow wewnetrznych zalezy od siebie i od asynchronicznych procesow zewnetrznych.

Czemu KDE dziala wolno? Trza by zapuscic profiler. Trza by oblozyc go tcpdumpem i straceami. Wtedy mozna sie dokopac czemu tyle muli.

I w praktyce moze sie okazac ze to nie jezyk jest winny a po prostu zawilosc aplikacji ktora sobie cos tam zbiera, monitoruje i nie czysci listy (tak jak to robil, i moze robi windows) przez co monitoruje mase smiecia co nikomu potrzebne nie jest. Ale to nie wina C++.

Jedno dodam na koniec. Bardzo duzo dzis sie odbywa synchronicznie przez siec. Albo pol asynchronicznie (user czeka, nic kliknac nie moze a apka odpytuje zdalny interfejs czy cos sie juz zrobilo czy nie). I te sprawdzenia niestety sa czesto uruchamiane szeregowo a do tego logika aplikacji czeka na choc jedno uaktualnienie kazdego statusu zeby userowi cos tam pokazac.

Otwierasz file managera a on odpytuje wszystkie dyski, wszystkie sieciowe udzialy, jakiegos blututa, pendrive i to w dobrych okolicznosciach trwa i w efekcie okienko zamiast pojawic sie natychmiast i potem odswierzyc 2-4-10 razy rysuje sie raz ale po sekundzie lub dwu.

W tym czasie user czeka. Czy to sie da obejsc? Nie sadze. Moze wycinajac pewne funkcje by sie dalo ale IMHO z paru powodow to zaklete kolko.

Czy bedzie lepiej? Tez nie sadze. Jak widze ile sie gówna produkuje bo w webie jest szybciej/prosciej to jestem przekonany ze nie bedzie lepiej.

To ze programy dzialaja powoli jest niezalezne od jezyka. Po prostu tak dziala prawo Parkinsona: programy zuzywaja cale dostepne zasoby (w tym czas). Jedyny sposob na powiekszenie szybkosci to "zmniejszenie" zasobow, tzn. gdyby userzy sie zbuntowali i odmowili uzywania nowych programow.

Przy tym wymagania stawiane desktopowym programom mocno sie roznia od embedded, wiec to co sie dzieje na desktopach to jest nie na temat jak piszemy o programowaniu MCU.

W embedded prawo Parkinsona tez dziala, ludzie wstawiaja Raspberry Pi z 1GB RAM i 1GHz zegarem w miejsca gdzie lepiej by dzialal MCU z 16k flashu i zegarem kilka-kilkadziesiat MHz.

Wracajac do C++ na MCU: jest sporo przykladow programikow ktore robia proste ale pozyteczne rzeczy napisanych w C++ gdzie kod jest ponizej 3 kB. Oczywiscie w 3 kB kodu wynikowego nie da sie wrzucic wszyskich ficzerow C++, ale wlasnie o to chodzi: uzywasz to co jest potrzebne a reszte pomijasz. No i sa pulapki: jak Ci przyjdzie do glowy zlinkowac program z libstdc++ to masz ponad

100kB w plecy...

Tak, to wiemy. Cały czas zwracam uwagę, że nie krytykuję C++ tylko programy w nim napisane źle.

Ależ ja o tym mówię od 40 lat, pierwsze prawo konsumenta: nie konsumować! Ale to niestety nie działa. Przez to mamy DRM i inne upierdliwości. Gdyby ludzie zaprzestali kupować sprzętu z DRM musiałoby to zniknąć z rynku.

Oczywiście, moja dygresja dotyczy tego co się dzieje w desktopach.