On 17/11/2021 19:25, Marek wrote:
>> 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.
> A ten JS to uruchamiany jest przez soft napisany w czym? :)

A kodzie maszynowym. W gruncie rzeczy.

do góry

On Wed, 17 Nov 2021 19:20:45 +0100, heby <h...@p...onet.pl> wrote:
> Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++.
> Który
> wykona się wolniej i dlaczego?

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

do góry

On Wed, 17 Nov 2021 19:48:46 +0100, heby <h...@p...onet.pl> wrote:
> Krytukujesz "dlaczego 99% doftu w C++" jes krytyką języka.

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


> To można powiedzieć o dowolnym innym języku.

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

--
Marek

do góry

On Wed, 17 Nov 2021 19:49:21 +0100, heby <h...@p...onet.pl> wrote:
> A kodzie maszynowym. W gruncie rzeczy.

Chyba maszyny do pisania.

--
Marek

do góry

On 17/11/2021 20:20, Marek 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.

Piszemy porządnie. Ale nie wszyscy.

>> To można powiedzieć o dowolnym innym języku.
> Ale jakoś C++ obrywa  najwięcej za wszystkie.

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

do góry

On 17/11/2021 20:14, Marek wrote:
>> Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
>> wykona się wolniej i dlaczego?
> Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++.

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.

> Przykład zły,
> bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu
> języków.

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

> Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby
> proces zajął min 2GB ram. ;)

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.

do góry

On 17/11/2021 20:22, Marek wrote:
>> A kodzie maszynowym. W gruncie rzeczy.
> Chyba maszyny do pisania.

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.

do góry

środa, 17 listopada 2021 o 13:15:03 UTC-6 Marek napisał(a):
> On Wed, 17 Nov 2021 19:20:45 +0100, heby <h...@p...onet.pl> wrote:
> > Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++.
> > Który
> > wykona się wolniej i dlaczego?
> 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. ;)
>
>

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.

do góry

Marek <f...@f...com> wrote:
> On Wed, 17 Nov 2021 18:22:19 +0100, heby <h...@p...onet.pl> wrote:
> > Podaj przyk?ad takiego softu, kt?ry jest napisany w *czym?* i C++ i
> > w
> > tym drugim wypadku dzia?a wolno.
>
> No poda?em przyk?ad siebie jako usera u?ywaj?cego od 25 lat g??wnie
> softu C++ i ci?gle tak samo korbi jak korbi? 25 lat temu. I tylko
> dzi?ki wzrostu wydajno?ci CPU i ilo?ci ramu rozw?j tego softu nie
> doprowadzi? do kompletnej jego nieuzywalno?ci (mam na my?li s?ab?
> responsywno?? czy u?ycie zasob?w).

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

do góry

On Thu, 18 Nov 2021 01:37:58 +0000 (UTC), a...@m...uni.wroc.pl
wrote:
> To ze programy dzialaja powoli jest niezalezne od jezyka. Po

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


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

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.


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

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

--
Marek

do góry