W dniu piątek, 22 marca 2013 17:49:48 UTC+1 użytkownik M.M. napisał:
> 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ę.
>

co do kompilatorow to tez moze byc wlasnie
tak ze intel icc optymalizuje lepiej niz gcc
i vcc, np w tym benchmarku

http://benchmarksgame.alioth.debian.org/u32/performa
nce.php?test=mandelbrot

najszybszy okazal sie intelowy fortran i to
prawie dwa razy szybszy niz c w gcc :/ - nie
przypuszczam zeby fortran byl szybszy od c

wiec wychodziloby ze roznica wynika z
optymalizacji kodu w asemblerze (icc vs gcc)

o ile tak jest tp jest troche straszne bo mz
znaczyloby ze icc albo jest w optymalizowaniu dobry albo jaki taki (bo tego tez nie
wiadnomo
czy on jet taki hiperdobry w stosunku do
recznego specjalisty) natomiast gcc i vcc sa byc moze dosyc slabe

jest to pewnego rodzaju hipoteza ale jak kogos to
interesuje to powinien pomierzyc lub conajmniej poczytac jakies w miare aktualne
porownania bo
pewnie sa jakies w necie (i moglby wpisac
wyniki na grupe)

mnie osobiscie jak na dzis bardziej interesuje
poznanie rwguł optymalizacji kodu samemu niz
posiadanie hiperoptymalizujacego kompilatora,
oczywiscie wolalbym raczej by kompilator ktorego
uzywam generowal na zadanie lepszego asma
ale nawet bardziej interesuje mnie reczna
optymalizacja - umiem optymalizowac kody w c
choc chcialbym sie nauczyc robic to lepiej
i troche umiem optymalizowac na poziomie asma
(ale tutaj slabo - tez chcialbym sie nauczyc
optymalizowac lepiej )