> rozumiesz aktu że im język jest wyższego poziomu tym programista ma
> mniejszą kontrolę nad kodem?:O)
> np: taka zwykłą pętla for w C, wiesz ile z tego kompilator robi instrukcji
> asemblera?:O) jak sprawdzisz to przynajmniej dędziesz wiedział ile tam
> jest śmiecia

Programowanie to nie tylko zadanie napisania kodu który raz zadziała,
przejdzie 2 proste testy i już. Kod często ma też sprawdzać zakresy
oczekiwanych
danych i wyników aby wyłapywać ewentualne inne mniej oczywiste błędy
przetwarzania.
Samo dodawanie czy pomnożenie to nie wszystko. Sprawdzanie zakresu wyniku,
przekroczenie tabeli
itd jest ważnym elementem prawie każdego programu. Jesli tego nie robisz w
swoich programach to
są one marne. Nawet nikt nie wie, że występują błędy i wychodzą bzdurne
wyniki.
Stąd takie proste x+y może być obudowane większym sprawdzonym kodem
kompilatora czy biblioteki.


>> Jaka niewiedza? Co mnie obchodzi jak dziala jakas funkcja. Mam funkcje
>> biblioteczna, ktora realizuje np. x+y i nie ma dla mnie znaczenia jak ona
>> to robi, byle to robila.
>
> no włąśnie, co ciebie obchhodzi, tak samo co ciebie obchodzi ze
> oprogramowanie jest niestabilne i z masą śmieci skoro jest poprawnie
> napisane:O(

Czepiasz się niesłusznie. Nie musi go obchodzić efektywność kodu
który wykonuje się sporadycznie, ważniejsza jest wtedy jego pewność
poprawności działania. A poprawność kodu na pewno jest wyższa z kompilatora
C
niż wklepanego ręcznie w asm. Ilość błędów jest związana z ilością linijek
kodu,
im prostrzy i czytelniejszy zapis tym mniej pomyłek.

Także optymalizacja kodu to inne zadanie kiedy piszesz prosty program dla
prostego 8 bitowca
i możesz to zrobic ręcznie niż kiepski C, a inne kiedy tworzysz kod dla
robudowanych
procków mających mnóstwo schematów adresowania i dla których kompilator
szuka optymalnego kodu, wykorzystania banków rejestrów , analizuje i
eliminuje martwy kod,
itd

> nic do tego programu nie pisałem, pisałem włąsny program w C o
> funkcjonalności podobnej do tamtego programu w asemblerze, dlatego wiem
> jaka byłą między nimi róznica w wydajnosci
>...
> jeśli coś można zrobić sprzętowo to lepiej to będzie działąć sprzętowo,
> ale czy ty myślisz ze grafika 3D to tylko gry PC? nie każda grafika ma
> zwiazek z przetwarzaniem obrazu, często są to czasochłonne filtracje,
> sploty, operacje na wielkich macierzach i tym poodbne, pod które nikt
> sprzętu masowo nie produkuje

Pisałem kiedyś program w C - implementując prosto dla próby własne FFT a
następnie
skorzystałem z gotowej biblioteki intela - była ona ponad 10 x szybsza od
mojego kodu,
ale to nie zasługa języka programowania tylko wykorzystania wbudowanych
zaawansowanych
instrukcji sygnałowych procka!. Jest ich teraz tak dużo i są związane
ściśle z konkretnymi
prockami, w kazdym są inne zestawy, że sami ani w asm ani w C tego nie
oprogramujemy -
biblioteki tworzy producent procków i ma popisane różne kawałki dla różnych
procków..

Takie filtry i inne o których piszesz właśnie mają piękne wsparcie sprzętowe
(SIMD) w procesorach.


zbyszek