I tu się mylisz. Przede wszystkim mózg programisty ma dość niewielką moc przerobową w porównaniu do CPU. CPU może wykonywać miliardy operacji na sekundę, więc może wypróbować sobie mnóstwo różnych optymalizacji i wybrać najlepszą.
Tja, tylko zajęło by to dużo czasu. Przeceniasz optymalizację, jakby robiła ona coś magicznego, tak że nie liczy się kod wejściowy.
Może dokonać optymalizacji na dużą skalę, tzn nie tylko coś w rodzaju "peephole optimization" ale może optymalizować całe grafy wywołań funkcji.
Chyba mówimy o wstawkach assembly? Zresztą, widziałem dużo kodu wyprodukowanego przez VS i uwierz mi, wcale magii nie ma.
Kompilatory używają algorytmów kolorowania grafów dla optymalnego wykorzystania rejestrów procesora, itp itd
daje to przyrost w przypadku dużych kodów, zgoda. Natomiast my mówimy o wstawkach w asmie które odpowiadają za kluczową funkcjonalność.
Jeśli dalej twierdzisz że optymalizacje przeprowadzane przez dobrej klasy kompilator będą zwykle słabsze od przeciętnego asemblerowca to odpal sobie jakiś algorytm rozwiązywania sudoku czy sztuczną inteligencję do gry w szachy i spróbuj się z tym zmierzyć. Powodzenia. Jeśli komputer będzie w stanie lepiej grać w szachy niż człowiek to czemu ma nie być w stanie lepiej optymalizować?
Sudoku i szachy to proste problemy matematyczne. Program komputerowy jest bardziej skompilowany bo kompilator nie wie co dany program ma robić. Nie zmieni on algorytmu na lepszy etc. Nie jest on w stanie również przewidzieć która część wyniku nas interesuje. Natomiast może przekształcać instrukcje na równoważne, ale szybsze.
Czytałem wywody o optymalizacji, ZTCP to były chyba wywody Paula Hsieha, w jednym z jego artykułów pokazywał, że kompilatory takie jak Intelowski kompilator C++ są generalnie trudne do pokonania.
Dobrze, dajmy kod jakiegoś newbie twoim błogosławionym kompilatorom, i porównajmy z moim albo twoim kodem który realizuje to samo. I?
Również czytałem dużo kodu assembly, głównie produkowanego przez FPC i VS, i o dziwo często dziwiłem się niepotrzebnym instrukcjom asma.
Inny problem ze wstawkami asemblerowymi jest taki, że kompilatorowi może być ciężej optymalizować taki kod, przez co inlinig i wieloetapowe optymalizacje zadziałają gorzej.
Bo kompilator nie wie co chcemy osiągnąć, a wszelkie udawanie że wie, wychodzi mu tylko na poziomie najbliższym maszynowemu, który składa się z ciągu operacji matematycznych etc.
Bardzo prosty test na optymalizację: Napisz sobie program, który zeruje tablicę dwuwymiarową, oczywiście zrób to podwójnym forem. Jeżeli napiszesz oczywisty for
to o dziwo VS wyprodukuje kod który za pomocą jednej procedury wyczyści cały region pamięci. Dobry optymalizator. Teraz odwróć kolejność zmiennych z obu forów, VS już wyprodukuje kod normalnych forów. Taki dobry ten optymalizator?
Generalnie ja nie mówię że optymalizatory są tępe jak pień, ale wydaje mi się że przeceniasz ich możliwość. Na papierze wszystko wygląda super, to takie magiczne. Natomiast prawda jest taka że kod powinno się pisać pod kompilatory tak żeby ich optymalizatory mogły zrobić optymalny kod. Nie ma możliwości żeby z nieoptymalnego kodu źródłowego wyszedł optymalny kod maszynowy.
Optymalizator na pewno wykonuje wystarczającą robotę jeżeli chodzi o normalny kod, jeżeli kod jest dobry to kod maszynowy również będzie dobry. Natomiast nie zrobi on niczego co by wykraczało poza sferę skróć instrukcje maszynowe do prostszej/szybszej postaci. Gdy się pisze kod w asmie, znając ograniczenia można dostosować algorytm do procesora. Optymalizator nie jest tego świadomy, jeżeli ma 12 zmiennych to przecież nie wsadzi ich wszystkich do rejestrów bo zabraknie miejsca. Natomiast gdy będzie się pisać w asmie to można wykombinować taki algorytm który wpakuje wszystko do rejestrów.