Programowanie w C

Zwykle nie ma potrzeby pisać programu w assemblerze, ale trzeba znać i assembler i budowę programowanego procesora żeby napisać porządny kod.
To nie musi być jakaś zaawansowana wiedza i znajomość, zwykle wystarczą podstawy, ale bez tego wychodzą cuda...
Ostatnio walczyłem z poprawianiem programu, w którym pan "programista" na 32-bitowym procesorze użył 16-bitowych zmiennych, które się przepełniały i program się sypał... Tak to jest kiedy ktoś pisze program na "czarną skrzynkę"...

drzasiek90 pisze: ↑

14 gru 2022, 18:27

Aż taki dobry jesteś, że napiszesz lepszy assembler niż zrobi to kompilator z języka C?

Tak
W przypadku jaki podałem.

A poza tym to nie ma nic dziwnego w tym że kod napisany przez człowieka jest lepszy od tego z kompilatora.
Niekoniecznie mój, bo nie ja pisałem powszechnie używane kompilatory, ale na pewno kod pewnych ludzi jest lepszy od kodów z kompilatora. Bo to oni pisali te kompilatory Musieli więc najpierw samemu rozkminić jak efektywnie poukładać instrukcje (i jakich użyć). Kompilator później tylko korzysta z tej wiedzy. Sam jej nie wymyślił. Sam nie jest więc mądrzejszy i bardziej efektywny od człowieka jaki ten kompilator napisał.
Obecnie AI może trochę zmienia, ale jeszcze nie zmieniło na tyle żeby mieć przewagę nad człowiekiem (ma co najwyżej w czasie wykonywania zadań).

atom1477 pisze: ↑

14 gru 2022, 21:24

A poza tym to nie ma nic dziwnego w tym że kod napisany przez człowieka jest lepszy od tego z kompilatora.

No właśnie jest.
W większości przypadków kompilator z języka C zrobi lepszy assembler niż większość całkiem niezłych programistów.
Nie wiem czy jest sens paprać się w pisanie całych procedur w asm, bo pisząc je w C wyjdzie na to samo lub nawet lepiej.
Jedyny sens to jakaś krótka wstawka.
Używanie assemblera sprawia, że twój kod staje się "mało przenośny" a tak naprawdę nic nie zyskujesz.
Co zupełnie nie przeszkadza, aby wiedzieć co to jest i umieć go użyć.

Tak apropo optymalizacji przeprowadzanej przez współczesne kompilatory - artykół na temat problemów z implementacją dość prostego algorytmu: https://www.researchgate.net/publicatio ... ed_Locking

Interesujące bo dopiero po przeczytaniu tego dowiedziałem się jak dużo swobody ma kompilator c++ przy decydowaniu o kolejności działań. Artykół jest z 2004 - ponoć dopiero w 2011 wprowadzono do standardu c++ pozwalające napisać ten kod w 100% bezpiecznie
W pewnym sensie zetknąłem się z podobnym problemem w praktyce - kompilator c firmy windriver na procesory arm - generował bardzo szybki i wydajny kod ale debugowanie było bardzo upierdliwe bo kolejność wykonywania linii była inna od oczekiwanej, nie dało się postawić pułapki w blokach typu
If (a)
B++

Bo potrafił je skrócić do pojedynczej instrukcji itd.
Co gorsza - nie dało się tych optymalizacji wyłączyć bo traktował je jako poziom podstawowy.
Trochę znam asembler arm - ale z całą pewnością nie potrafiłbym napisać czegoś równie wydajnego w asemblerze Tak więc jestem w obozie "wstawki asm tam gdzie to absolutnie konieczne"

drzasiek90 pisze: ↑

15 gru 2022, 07:05

atom1477 pisze: ↑

14 gru 2022, 21:24

A poza tym to nie ma nic dziwnego w tym że kod napisany przez człowieka jest lepszy od tego z kompilatora.

No właśnie jest.
W większości przypadków kompilator z języka C zrobi lepszy assembler niż większość całkiem niezłych programistów.

Nie jest. Pod pojęciem "człowieka: miałem na myśli odpowiedniego człowieka. Nie ma co porównywać do całości ludzkości, ani nawet do tych lepszych programistów.
Porównujmy to samo z tym samym. Czyli kompilator używający assemblera, do programisty piszącego w assemblerze. Nawet najlepsi programiści, ale nie piszący w assemblerze, nie są odpowiedni do tego porównania.

Przecież kompilator został napisany przez człowieka.
Skąd inaczej by wiedział że w AVR nie ma instrukcji ADDI, i że zamiennie należy używać SUBI?
Albo że JMP jest szybsze od LJMP (choć ma inne ograniczenia)? To człowiek musiał to wcześniej wiedzieć. Czyli to człowiek jako pierwszy wiedział jak napisać optymalny kod.

drzasiek90 pisze: ↑

15 gru 2022, 07:05

Nie wiem czy jest sens paprać się w pisanie całych procedur w asm, bo pisząc je w C wyjdzie na to samo lub nawet lepiej.

Ale ja nie pisałem ogólnie, tylko napisałem że ciągle się w pewnych zastosowaniach pisze w assemblerze.
To o tych zastosowaniach mowa, a nie o wszystkich jakie są.

drzasiek90 pisze: ↑

15 gru 2022, 07:05

Używanie assemblera sprawia, że twój kod staje się "mało przenośny" a tak naprawdę nic nie zyskujesz.

Oczywiście że zyskujesz: wydajność.
Kod ma być nieprzenośny.
Jak niby kod ma być przenośny z AARch64 z NEONEM na rdzenie CUDA, i jednocześnie maksymalnie wydajny na obu?
Ja o chlebie Ty o niebie.
Nie pisałem o całości kodu w assemblerze. Ani o jakimś zwyczajnym kodzie.
Mówiłem konkretnie o bibliotekach DSP (które potem się wywołuje już z wysokopoziomowego kodu).
Nawet istnieją dodatki do C pozwalające wymuszać konkretne instrukcje assemblera żeby użyć tego NEONa.
Czyli de facto piszesz w assemblerze, obudowując to mnóstwem naddatków.
Kompilator bez tych naddatków, nie skompiluje optymalnie kodu C pod NEONa. Przenośność będzie, ale optymalności nie.
A gdyby nawet istniał kompilator który to skompiluje wydajnie, to niespodzianka: używałby nieprzenośnych bibliotek do różnych procesorów. Innej dla jednego innej dla drugiego. Ty z zewnątrz byś tego nie wdział. Bo ten sam kod w C by Ci kompilował do dwóch procesorów, i w obu przypadkach optymalnie.
No ale ktoś wcześniej musiał by ten kompilator i biblioteki napisać. I nie był by to jakiś inny wcześniejszy optymalny kompilator

grg12 pisze: ↑

15 gru 2022, 08:41

Tak więc jestem w obozie "wstawki asm tam gdzie to absolutnie konieczne"

A czy ja jestem w innej?