z tego co obserwuje jesli ktos chce pisac
zoptymalizowane programy (np w c) to bez
asemblera nie mozna sie obejsc
(Pytanie czy to twierdzenie jest do końca scisłe,
ale chyba jest) - w obliczu sse (moze ze skalarnym asmem byloby nieco inaczje) i tego
ze obecne optymalizatory
sa pod tym katem beznadziejne (znowu, moze gdyby
jezyk c byl rozszerzony sytuacje uleglaby pewnej
zmianie, nie jestem do konca pewien) sprawa ma sie
po prostu tak ze trzeba pisac w asmie i "nie ma bata"
9przez asma moge tez rozumiec intrinsiki ale podobno nawet to wspolczesne kompilatory
robia dosyc kiepsko)

slowem kompilatory podobno (jak to powtarzaja co poniektorzy) optymalizuja dobrze kod
tylko ze wychodzi na to ze moze caly za wyjatkiem hotspotow ;/ [uzywam tego slowa bo
jakos poki co nie znam lepszego] bo jak
przychodzi co do czego okazuje sie ze takiego hotspota trzeba przepisac w asmie i
nawet nie ma tu mowy o zadnej konkurencji, sciganiu sie z kompilatorem - kompilator
po prostu lezy - takie sa moje
doswiadczenia [i wbrew temu co mowia liczni internetowi zamulacze przepisywanie
hotspotow w asmie moze dzis bardziej oplacalne (jesli komus zalezy na szybkosci kodu)
niz kiedys]

(sa to optymistyczne 'wiesci' (jesli to mozna nazwac wiesciami))

do góry

W dniu 05.07.2014 13:08, firr pisze:
> z tego co obserwuje jesli ktos chce pisac
> zoptymalizowane programy (np w c) to bez
> asemblera nie mozna sie obejsc
> (Pytanie czy to twierdzenie jest do końca scisłe,
> ale chyba jest) - w obliczu sse (moze ze skalarnym asmem byloby nieco inaczje) i
tego ze obecne optymalizatory
> sa pod tym katem beznadziejne (znowu, moze gdyby
> jezyk c byl rozszerzony sytuacje uleglaby pewnej
> zmianie, nie jestem do konca pewien) sprawa ma sie
> po prostu tak ze trzeba pisac w asmie i "nie ma bata"
> 9przez asma moge tez rozumiec intrinsiki ale podobno nawet to wspolczesne
kompilatory robia dosyc kiepsko)
>
> slowem kompilatory podobno (jak to powtarzaja co poniektorzy) optymalizuja dobrze
kod tylko ze wychodzi na to ze moze caly za wyjatkiem hotspotow ;/ [uzywam tego slowa
bo jakos poki co nie znam lepszego] bo jak
> przychodzi co do czego okazuje sie ze takiego hotspota trzeba przepisac w asmie i
nawet nie ma tu mowy o zadnej konkurencji, sciganiu sie z kompilatorem - kompilator
po prostu lezy - takie sa moje
> doswiadczenia [i wbrew temu co mowia liczni internetowi zamulacze przepisywanie
hotspotow w asmie moze dzis bardziej oplacalne (jesli komus zalezy na szybkosci kodu)
niz kiedys]
>
> (sa to optymistyczne 'wiesci' (jesli to mozna nazwac wiesciami))

Różnie z tym bywa.
Np. taki GCC ma opcje tuningujące kod wynikowy już pod najnowsze lub
prawie najnowsze procesory i potrafi korzystać z SSE czy innych
technologii, które są obce tym kompilatorom C, które zatrzymały się na
386 lub 686 (w sensie operacji skalarnych, bez MMX).
Przy często używanych operacjach, które kompilatory już umieją
optymalizować, może być ciężko je prześcignąć.
Ale kompilatory mogą sobie gorzej radzić w "intensywnych
obliczeniowo" fragmentach kodu, a poza tym np. biblioteki matematyczne
mogą nie być "gotowe" na optymalizacje czy używanie SSE.
Kompilatory mogą sobie też gorzej radzić z optymalizacjami na
poziomie całego programu (choć GCC też ma jakieś opcje z tym
związane), typu "przez cały żywot programu rejestr X będzie trzymał
moją stałą Y, aby był do niej szybki dostęp").
Czy da się prześcignąć kompilator? Sądzę, że tak. Może nie zawsze i
wszędzie, ale w pewnych sytuacjach według mnie jest to możliwe. W
końcu kompilator ma kompilować różne programy, a nie tylko ten nasz
jedyny, a zestaw optymalizacji dla jednej sytuacji może nie podziałać
dobrze w innej.
To wszystko też z raczej zasłyszanych rzeczy. Sam mam niewielkie
doświadczenie w porównywaniu programów C z asmem, ale pamiętam
mgliście jakąś historię, gdzie były pisane jakieś programy numeryczne,
chyba po milion iteracji i programy w C działały w "czasach
obiadowych" (tzn. można było sobie uruchomić program, ugotować obiad,
zjeść go, wrócić i może był wynik :) ), a podobne programy w
asemblerze kończyły pracę w czasie rzędu pojedynczych minut.
W skrócie: to, co da się wycisnąć, zależy od:
- kompilatora,
- człowieka,
- konkretnego kawałka kodu.
Jeśli czujesz, że Twój kod działa nie dość szybko w punkcie, w którym
nie da się go już bardziej zoptymalizować w języku wyższego poziomu,
spróbuj ten kawałek przepisać na asma, resztę pozostaw kompilatorowi
do optymalizacji.
No i kolejność operacji:
- implementujemy działający kod,
- wybieramy lepsze algorytmy (np. sortowania),
- optymalizujemy.


--
Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux): http://bogdro.ciki.me
Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org Soft(EN): http://bogdro.ciki.me/soft

do góry