W dniu poniedziałek, 25 marca 2013 08:08:34 UTC+1 użytkownik firr kenobi napisał:
> 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 :/
No proszę. Tak podejrzewałem, ale nie wiedziałem.
Teraz widać, różnice dwa razy to coś czego można
się spodziewać.

Pamiętam jak kiedyś dobierałem drobiazgi implementacyjne w
programie szachowym na bardzo wczesnym etapie realizacji.
Chodziło dosłownie o przesuwanie bierek po planszy i o
update kilku pomocniczych statystyk przy okazji przesuwania.
Kompilowałem gcc, wtedy jeszcze na platformę 32bitową. Od
czasu do czasu zauważałem, że po jakiejś drobnej zmianie
kompilator wygenerował kod 2-3 razy szybszy. Dosłownie 50
różnych pomysłów, różnice w wydajności pomiędzy pomysłami
o ułamki procenta, a czasami/nagle różnica o 200-300%. Taki
kod skompilowany potem przy pomocy MSVC++ działał o wiele
wolniej. To było tak, jakbym dobrał konstrukcje językowe,
które kompilator gcc akurat umie zoptymalizować. Więc kilka
przesłanek na to jest, że jakby sztab fachowców przysiadł, to
by napisał kompilator 2-3 razy wydajniejszy.


> - nie przypuszczam zeby fortran byl szybszy od c
Nie zdziwiłbym się, jakby napisanie optymalizatora do
frotrana/ady, było łatwiejsze niż do C/C++.

> wiec wychodziloby ze roznica wynika z
> optymalizacji kodu w asemblerze (icc vs gcc)
No chyba tak, chyba potwierdzają się moje przypuszczenia.

> 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)
Liczyłem że ktoś bardzo doświadczony w asemblerze coś konkretnego
powie w tym wątku, na razie wszyscy łącznie ze mną bazujemy na
przypuszczeniach.

Przed laty wyszła książka "procesory pentium, narzędzia optymalizacji"
autorstwa Micheal L. Schmit. W którymś z rozdziałów pokazał ręcznie
zoptymalizowaną procedurę w asemblerze, po czym dodał coś w rodzaju
"nie sądzę aby jakikolwiek kompilator zdołał tak zoptymalizować". Myślę,
że to stwierdzenie nadal w jakimś stopniu jest aktualnie, ciekawe tylko w
jakim :)

Odbiegając od tematu...
Ostatnio napisałem w proceduralnym C++ prosty program optymalizacyjny.
Prosty, bo kodu tam raptem 1000 linijek, z czego kod obliczeniowy to
może 400 linii. Kod jest bardzo sprytnie zoptymalizowany, ale patrzę na
niego, patrzę na podejrzane wyniki i się zastanawiam... czy tam na pewno
nie ma błędu? No i właśnie dziś przepisuję w wysokopoziomowym C++,
nafaszerowanym klasami i vectorami... co byłoby gdybym miał ten kod
napisany w asemblerze? Pewnie bym po pierwszej procedurze miał dosyć i
bym wrócić do wysokopoziomowego C++ albo do Javy :)

Pozdrawiam





>
>
>
> 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 )