środa, 17 listopada 2021 o 20:32:15 UTC+1 heby napisał(a):
> 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.

Napisz choć kilka przykładów.
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.

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

Który? I dlaczego?

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

No to którym kompilatorem "lepiej" się skompiluje program napisany w C - kompilatorem
C czy C++?

do góry

On Thu, 18 Nov 2021 06:52:45 -0800 (PST), Dawid Rutkowski wrote:
> środa, 17 listopada 2021 o 20:32:15 UTC+1 heby napisał(a):
>> 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.
>
> Napisz choć kilka przykładów.
> Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.

Piotr kiedys wymienial.

Chocby izolacja nazw procedur w klasie - i nie musisz wymyslac
unikalnych nazw, czy martwic sie, ze gdzies w bibliotece juz jest jest
tak nazwana funkcja.

W malych uC wydawało mi się to niewielką zaletą - nad małym programem
można zapanowac. Ale jak sie uC rozbudowały.

>>> 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.
>
> No to którym kompilatorem "lepiej" się skompiluje program napisany w C -
kompilatorem C czy C++?

Jeszcze kwestia, jak mocny musi byc procesor, żeby sie te konstrukcje
naprawde wydajnie kompilowaly.

C++ na 8051? :-)

No, ciekawe, czy by sie udalo ubrac te 3 rodzaje pamieci w klasy ...
nie, chyba nie :-)

J.

do góry

środa, 17 listopada 2021 o 19:37:59 UTC-6 a...@m...uni.wroc.pl napisał(a):
>
> 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.
>

Tak, ALE! :)
Wyjasnienie nizej.

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

Najsmieszniejsze w tym jest to ze o ile zrobienie sobie termostatu rzeczywiscie
zajmie te 3kb (lub pewnie mniej) nawet w arduino przy uzyciu gotowych bibliotek ALE
bardzo czesto tworca sobei zazyczy kontrole i monitoring zdalny. Czyli wifi, http(s),
jakas autoryzacja, jakies kolejki, moze scheduler zachowan...
I program nie miesci sie w attiny.
Nie miesci sie w byle atmega bo trzeba by przynajmniej taki z ethernetem.
Mozna zrobic na esp8266 czy podobnych rozwiazaniach ale jak malina kosztuje to samo,
ma ssh, ogarnia ssl, moze hostowac baze, moze miec zabbixa czy inna grafane to czemu
nie uzyc?

Smieszne jest to ze z punktu widzenia hobbysty to dobry kierunek. Z punktu widzenia
gigantow tez!

I dlatego ludki chca i C++ i arduino i maline bo kosztuje podobnie, a pozwala na
wiecej.

A ludzie tacy jak w tym watku, broniacy minimalizmu (lub atakujacy rozrzutnosc) czy
jeszcze inaczej motywowani to w praktyce mniejszosc.
Maja slusznosc w pewnych aspektach ale ogolny trend od dawna byl taki ze minimalizm
nie poplaca.

Sprawdza sie czasem (minecraft, notepad++, esp8266) ale ogolnie preferencja jest aby
miec wiecej za te same pieniadze. Fakt ze to powoduje pewne problemy (zawodnosc,
wiecej wektorow ataku itp) jednak nie zmienia tego trendu mimo ze to calkiem wazne
aspekty.

do góry

On 18/11/2021 15:52, Dawid Rutkowski wrote:
>> Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
>> *bardzo* przydatnym w embedded, bez narzutu wydajności.
> Napisz choć kilka przykładów.

Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.

Np taki:

foo()
{
DisableInterruptsInThisScope guard;

[...]
return;
[...]
return;
[...]
return;
}

> Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.

No to masz RIIA.

>>> 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++.
> Który? I dlaczego?

Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.

>> 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.
> No to którym kompilatorem "lepiej" się skompiluje program napisany w C -
kompilatorem C czy C++?

Oba skompilują tak samo.

Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.

do góry

On 18/11/2021 17:22, heby wrote:
> No to masz RIIA.

Tfu, RAII.

do góry

2021-11-18 o 17:22 +0100, heby napisał:
> Np taki:
>
> foo()
> {
> DisableInterruptsInThisScope guard;
>
> [...]
> return;
> [...]
> return;
> [...]
> return;
> }

Spodziewałem się jakiejś faktycznej wartości dodanej, a tu zawód. :)

To co podałeś to przecież nic innego jak to:

foo() {
_disable();
[...]
goto gameover;
[...]
goto gameover;
[...]
goto gameover;

gameover:
_enable();
}


Mateusz

do góry

On 18/11/2021 17:32, Mateusz Viste wrote:
> To co podałeś to przecież nic innego jak to:
>
> foo() {
> _disable();
> [...]
> goto gameover;
> [...]
> goto gameover;
> [...]
> goto gameover;
>
> gameover:
> _enable();
> }

No i właśnie nie rozumiałeś, więc C++ nie dla Ciebie.

Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.

W twoim przypadku, białko zostało i niczym się to nie rózni od ręcznego
pisania sei(); return;.

W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań. Jedna
kategoria bugów została właśnie usunięta: "zapomniałem załączyć przerwania".

do góry

2021-11-18 o 17:47 +0100, heby napisał:
> Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.

Cel szczytny, ale taki jakby mało realistyczny. A raczej: realistyczny,
ale kiedy zostanie osiągnięty, to już dawno nie będziemy potrzebni.

> W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań.
> Jedna kategoria bugów została właśnie usunięta: "zapomniałem załączyć
> przerwania".

W konkursie wystartowała natomiast kategoria nowa: "zapomniałem ustawić
scope guard na włączenie przerwań".

No i teraz można się spierać o styl, jakieś prawdopodobieństwa,
zwyczaje itd, ale liczyłem że podasz po prostu inny przykład, który
wykazałby wyższość tych plus-plusów w sposób bezdyskusyjny.

Mateusz

do góry

On 18/11/2021 18:01, Mateusz Viste wrote:
>> Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.
> Cel szczytny, ale taki jakby mało realistyczny. A raczej: realistyczny,
> ale kiedy zostanie osiągnięty, to już dawno nie będziemy potrzebni.

Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się błedu
w kodzie. Kazde takie miejsce przyczynia się do mniejszej ilości bugów.

Programowanie w językach wyższego poziomu własnie na tym polega: na
zmniejszeniu ilosci potencjalnych miejsc z pomyłką.

>> W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań.
>> Jedna kategoria bugów została właśnie usunięta: "zapomniałem załączyć
>> przerwania".
> W konkursie wystartowała natomiast kategoria nowa: "zapomniałem ustawić
> scope guard na włączenie przerwań".

Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.

> No i teraz można się spierać o styl

Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa kodu.
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.

, jakieś prawdopodobieństwa,
> zwyczaje itd, ale liczyłem że podasz po prostu inny przykład, który
> wykazałby wyższość tych plus-plusów w sposób bezdyskusyjny.

Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach miganai
diodą nie ma problemu i stąd ten problem z rozumieniem tej wyższości.

To jeszcze jeden:

UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;

Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7 to
jest poważny problem.

Mogę ten kod napisać sprytnie. Tak sprytnie, że użycie złej flagi będzie
niemożliwe na złym porcie. I w dodatku bez zmiany składni, którą widzisz
na górze, wyłącznie używając C++, wrapując enumeratory, przeciążając
operatory i na zawsze zapominając o błędnych flagach. I bez śladu
obciążenia w kodzie wynikowym, asm będzie zawierał tą samą instrukcję.

Tak, to też da się zastąpić uwaznym gapieniem się w kod, wiec doskonale
zdaje sobie sprawę, że nie będziesz pojmować po co to komu. Bo przeciez
wszystko da się napisać w asm, jak się jest uważnym hackerem.

do góry

2021-11-18 o 18:12 +0100, heby napisał:
> Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się
> błedu w kodzie.

Nie, nie dostałem. :)
Ty tego białka nie wyeliminowałeś, tylko je przesunąłeś w inne miejsce.

> > W konkursie wystartowała natomiast kategoria nowa: "zapomniałem
> > ustawić scope guard na włączenie przerwań".
>
> Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.

Ech, czyli jednak dyskutowanie o prawdopodobieństwach. Szkoda.

> Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa
> kodu. Są miejsca, gdzie takie gówno oparte o goto wyleciało by z
> hukiem na review razem z autorem tego szamba.

Bo ty tak mówisz?

> Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach
> miganai diodą nie ma problemu i stąd ten problem z rozumieniem tej
> wyższości.

Czy to miganie diodą, czy sterowanie promem kosmicznym, w obu
przypadkach scope nie powinien być tak rozległy, że autor przestaje nad
nim panować.

> To jeszcze jeden:
>
> UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;
>
> Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
> flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7
> to jest poważny problem.
>
> Mogę ten kod napisać sprytnie.

O, czyli może jednak będzie konstruktywnie. No to dajesz.

Mateusz

do góry