W dniu piątek, 22 marca 2013 16:27:16 UTC+1 użytkownik Michoo napisał:
> Ca�y czas to powstaje. Ostatnio np. w glibc zrobili podstawy obs�ugi
> instrukcji stm w nowych procesorach intela.
Ano właśnie. Techniki optymalizacyjne implementuje się w kompilatorach
na bieżąco, można domniemać że jutro kompilatory będą lepsze, czyli dziś
są nie inne, tylko gorsze.

> Pewnie ze da sie, ale dopuki komitent standaryzacyjny bedzie sie
> zajmowal abstrakcjami a nie wprowadzal do core jezyka nowych typow
> danych ktore sie mapuja 1:1 na nowe sprzetowe rejestry to IMO nic sie
> nie poradzi. Wynalazki w postaci intrinsic functions to nie to samo
Kilkanaście lat temu rozmawiam ze znajomym. Był on wtedy wykładowcą
na UMK, uczył między innymi programowania w rożnych językach, głównie w C.
W trakcie rozmowy poruszam temat sensowności programowania w asemblerze w
celu przyspieszenia kodu. Pytam na ile dobry kod generują kompilatory
borlanda czy microsoftu. Prawie na mnie się wydarł że to jet niemożliwe
aby generowały nieoptymalny kod. Zdziwiłem się, bo wygenerowanie optymalnego
kodu jest niemożliwe. Pomyślałem więc, że chodzi po pierwsze o to, że
generują optymalny kod w stosunku do nakładu pracy jaki włożono w napisane
tych kompilatorów, a po drugie o to, że włożony nakład pracy był bardzo
duży. Uwierzyłem że są optymalne w takim sensie, że jak się zgromadzi
100 speców od optymalizacji kodu to przez 10 lat pracy napiszą kompilator
lepszy o góra 10%-20%. Tymczasem w ciągu nie więcej niż roku od naszej
rozmowy pojawiły się kompilatory tak efektywne, że czas wykonania wielu
programów skrócił się o 60%, rzadziej o 70%. Więc drugi raz na ten sam numer
nie dam się nabrać :) Ktoś by musiał napisać dużo więcej niż "w intelu się
starają", to wtedy bym uwierzył, że dzisiejsze kompilatory są u szczytu
możliwości. Być może są, ale ja na razie nie wierzę.
Pozdrawiam