Powrót do AVR: Wybór IDE i narzędzi do programowania attiny806

Wed Nov 17, 2021 7:20 pm   

On 17/11/2021 19:08, Marek wrote:

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.

Wed Nov 17, 2021 7:25 pm   

On Wed, 17 Nov 2021 19:13:05 +0100, heby <heby@poczta.onet.pl> wrote:

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

--
Marek

Wed Nov 17, 2021 7:26 pm   

On Wed, 17 Nov 2021 19:14:53 +0100, heby <heby@poczta.onet.pl> wrote:

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

--
Marek

Wed Nov 17, 2021 7:31 pm   

On Wed, 17 Nov 2021 19:20:45 +0100, heby <heby@poczta.onet.pl> wrote:

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.

--
Marek

Wed Nov 17, 2021 7:48 pm   

On 17/11/2021 19:31, Marek wrote:

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.

Wed Nov 17, 2021 7:49 pm   

On 17/11/2021 19:25, Marek wrote:

A kodzie maszynowym. W gruncie rzeczy.

Wed Nov 17, 2021 8:14 pm   

On Wed, 17 Nov 2021 19:20:45 +0100, heby <heby@poczta.onet.pl> wrote:

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. ;)

--
Marek

Wed Nov 17, 2021 8:20 pm   

On Wed, 17 Nov 2021 19:48:46 +0100, heby <heby@poczta.onet.pl> wrote:

?? 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.

--
Marek

Wed Nov 17, 2021 8:22 pm   

On Wed, 17 Nov 2021 19:49:21 +0100, heby <heby@poczta.onet.pl> wrote:

Chyba maszyny do pisania.

--
Marek

Wed Nov 17, 2021 8:27 pm   

On 17/11/2021 20:20, Marek wrote:

Piszemy porządnie. Ale nie wszyscy.


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

Wed Nov 17, 2021 8:32 pm   

On 17/11/2021 20:14, Marek wrote:

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.

Wed Nov 17, 2021 8:33 pm   

On 17/11/2021 20:22, Marek wrote:

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.

Thu Nov 18, 2021 1:06 am   

środa, 17 listopada 2021 o 13:15:03 UTC-6 Marek napisał(a):

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.

Thu Nov 18, 2021 3:37 am   

Marek <fake@fakeemail.com> wrote:

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...

--
Waldek Hebisch

Thu Nov 18, 2021 12:14 pm   

On Thu, 18 Nov 2021 01:37:58 +0000 (UTC), antispam@math.uni.wroc.pl
wrote:

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.

--
Marek