Użytkownik "Adam Przybyla" <a...@r...pl> napisał:

> z kazda wersja kompilatora C bylo coraz trudniej. Pod koniec mojej zabawy, roznice
> byly juz prawie minimalne, miedzy tym co ja robilem i kompilator.

Mam podobne doswiadczenia (tyle ze na x86) i dlatego juz dawno temu
bez cienia zalu porzucilem assembler (mimo ze kiedys napisalem w asm x86
cala biblioteke standardowa C - i o dziwo ;) mialo to wtedy sens :).

AK

do góry

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

w necie jest np taka ciekawa stronka
z benchmarkami

http://www.willus.com/ccomp_benchmark2.shtml?p2

moge przekleic najciekawsze kawałki z podsumowamia:

In my 2002 Benchmarks, Intel did very well. On the two benchmarks common to both 2002
and 2011 (BW1D and LAME), the average performance improvement of the fastest
Intel-compiled code over the fastest gcc-compiled code was almost 80%. Intel had a
similar performance margin over Microsoft in 2002. In 2011, on the otherhand, the
result is similar, but the balance of power is shifting. Intel is still the overall
winner based on a geometric mean of the performance scores, but this time the margins
over gcc and Microsoft are only 7 - 26% (over gcc, depending on the compile flags and
32/64-bit--the best results, 64-bit, averaged 18% faster than gcc's) and 13 - 22%
(over microsoft), respectively, and on six of the ten benchmarks, the fastest
gcc-compiled executable is either faster or equivalent to (within 6%) the fastest
Intel-compiled executable (MS VC 2010 only had one result within 6% of Intel's
fastest score). This sort of performance seems roughly in line with what other people
are getting or have gotten recently between Intel and gcc

w skrócie: intel jest szybszy czesto o okolo 30
procend (sporadycznie o 0% albo o np 70%) wobec gcc i vcc ktore sa mw podobnej
szybkosci

Digital Mars and Tiny CC certainly leave a lot to be desired in terms of run-time
performance of their compiled executables (2.3X and 4.5X slower than Intel,
respectively, on average), but for ease of setup and use, install size, and fast
compiling, they are hard to beat, especially Tiny CC, which, on average, compiles and
links C applications nearly 4X faster than its closest competitor (Microsoft), 7X
faster than gcc 4.6.3, and over 10X faster than Intel!

male kompilatory kompiluja szybciej ale naiwnie
generowany kod jest nawet ze 4 razy wolniejszy niz
ten optymalizowany

pozatym narzekania ze intel jest kobylasty ponag gigabajt instalki - co tez mi sie
nie podoba

Intel's Transcendent Transcendental Performance
Two of Intel's clearest-cut victories are in BW1D and TRANSCEND. Both of these
benchmarks make heavy use of sincos(), pow(), and other transcendental C math
functions, so I wrote some programs to isolate the performance of these functions a
la my MinGW fast math function testing code. Sure enough, Intel is definitely doing
some in-line transcendental magic. On my sincos() loop test, the Intel-compiled
version is 3 times faster than gcc's best result. On the pow() loop, Intel's margin
increases--over 4 times. But the biggest margin is the exp() test loop: the
Intel-compiled code is 8 times faster than gcc! I am sure this kind of margin on
transcendentals is what lifts Intel to its impressive performance in BW1D and
TRANSCEND. Hopefully some talented programmer can disassemble Intel's lightning fast
transcendental C calls and mimic them in an open-source fast math library that can be
tightly coupled to gcc. With something like that, I think gcc would be neck-and-neck
with Intel for the best overall performance in these benchmarks.

to jest bardzo ciekawe - intel ma dobrze napisane
wielokroc szybsze funkcje transcendentalne w
szczegolnosci exp i pow ktore zarzynają gcc
(to ze pow jest baaardzo wolny to sam odkrylem jak pisalem prosty raytracer) - nawet
wnioski ze
gdyby nie to to gcc moglby byc podobnie szybki jak
intel (lub prawie)

do góry

W dniu poniedziałek, 25 marca 2013 11:52:51 UTC+1 użytkownik firr kenobi

> z benchmarkami
> http://www.willus.com/ccomp_benchmark2.shtml?p2
> moge przekleic najciekawsze kawałki z podsumowamia:
Dzięki wielkie, materiał wygląda na rzetelny.

http://www.willus.com/ccomp_benchmark2.shtml?p10+s14
Widać że na platformę 64bitową szachowy program (znam źródło, wyjątkowo
zagmatwany kod, moim zdaniem trudno poddający się optymalizacji) najlepszy
wynik 20s, najgorszy 24s - nieduża różnica, ale zawsze coś. W teście
wydawano komendę perft 6, czyli program miał "policzyć" ile jest
liści w drzewie gry na głębokość 6 ruchów.


http://www.willus.com/ccomp_benchmark2.shtml?p9+s14
Bzip2 - chyba każdy zna ten program :) Tutaj najlepszy czas na
platformę 64bit 44s, najgorszy 50s - znowu niedużo.


Widać także, że nie ma jednego najlepszego kompilatora. Jeśli kompilator
generuje dobry kod z jednego źródła, to wcale nie oznacza, że z innego
źródła także wygeneruje dobry kod. Czasami komercyjny kompilator przegrywa
z darmowym...


> male kompilatory kompiluja szybciej ale naiwnie
> generowany kod jest nawet ze 4 razy wolniejszy niz
> ten optymalizowany
Czasami zastanawiam się, czemu w kompilatorach nie ma opcji "kompiluj
do póki użytkownik nie wciśnie ctrl+c". Nie da się napisać takiego
kompilatora, że im dłużej kompiluje, tym większe prawdopodobieństwo że
wygeneruje lepszy kod?

> pozatym narzekania ze intel jest kobylasty ponag gigabajt instalki - co tez
> mi sie nie podoba
Wiadomo, mały program to poręczny program, szybko się pobiera z sieci,
szybko się instaluje, można go na pendriva wgrać... Ale jakby generował
bardzo wydajny kod, to mogę kupić specjalny dysk na jego instalację :)


> to jest bardzo ciekawe - intel ma dobrze napisane
> wielokroc szybsze funkcje transcendentalne w
> szczegolnosci exp i pow ktore zarzynają gcc
> (to ze pow jest baaardzo wolny to sam odkrylem jak pisalem prosty raytracer)
> - nawet wnioski ze gdyby nie to to gcc moglby byc podobnie szybki jak
> intel (lub prawie)
Też miałem z tymi funkcjami problemy w gcc i mvc. W kompilatorze intela
nigdy nie sprawdzałem. Na niektórych kombinacjach procesor-kompilator
widziałem, że np. pow(3.0,2.0) != 9.0. Może właśnie te kompilatory generują
szybszy kod, w których zachodzi powyższa nierówność. Może niektóre procesory
dlatego są tańsze... nie wiem... znowu kupa domysłów :)

Pozdrawiam i dzięki jeszcze raz za stronkę.

do góry

W dniu poniedziałek, 25 marca 2013 10:57:02 UTC+1 użytkownik AK napisał:
> Użytkownik "Adam Przybyla" napisał:
> > z kazda wersja kompilatora C bylo coraz trudniej. Pod koniec mojej zabawy,
roznice
> > byly juz prawie minimalne, miedzy tym co ja robilem i kompilator.
> Mam podobne doswiadczenia (tyle ze na x86) i dlatego juz dawno temu
> bez cienia zalu porzucilem assembler (mimo ze kiedys napisalem w asm x86
> cala biblioteke standardowa C - i o dziwo ;) mialo to wtedy sens :).
Kiedyś wielu programistów tak robiło, samemu też od czasu do czasu
sięgałem po asembler. Faktem jest, że kilka-kilkanaście lat temu
kompilatory zaczęły generować lepszy kod niż dobry programista, no chyba że
programista naprawdę włożył w małą procedurę dużo pracy i czasu. Jak
jest teraz to nie wiem. Żeby programować dobrze w asemblerze na dany
procesor, to trzeba mieć duże doświadczenie. Nie wiem jak duże... 2 lata po
150 godzin miesięcznie? Nie znam nikogo takiego, więc nie mam nawet kogo
zapytać :)

Pozostaje otwartym pytanie, jak dobry kod generowałby kompilator, np.
taki kompilator intela, jakby włożono w niego 10-30 razy więcej pracy :)

Pozdrawiam

do góry

W dniu 2013-03-25 14:08, M.M. pisze:
> Pozostaje otwartym pytanie, jak dobry kod generowałby kompilator, np.
> taki kompilator intela, jakby włożono w niego 10-30 razy więcej pracy:)
Odpowiedź na to pytanie (po części) można znaleźć na stronie podanej
przez firr kenobiego przy okazji testowania wydajności kodowania x264
H.264/MPEG-4
http://www.willus.com/ccomp_benchmark2.shtml?p17+s16

Takie zdanie można tam znaleźć:
"[...] For comparison, the latest version of 64-bit ffmpeg from zeranoe
with hardware detection and in-line assembly enabled in the x264 module
does the same conversion in 19 seconds--over 3X faster than the best
result below!"


--
wloochacz

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Na niektórych kombinacjach procesor-kompilator widziałem,
> że np. pow(3.0,2.0) != 9.0. Może właśnie te kompilatory generują
> szybszy kod, w których zachodzi powyższa nierówność.
> Może niektóre procesory dlatego są tańsze... nie wiem...
> znowu kupa domysłów :)

Lepiej sie naucz _uzywania_ liczb zmiennoprzecinkowych zamiast
psioczyc na niby zle kompilatory :(

AK

do góry

W dniu poniedziałek, 25 marca 2013 14:48:45 UTC+1 użytkownik AK napisał:

> Lepiej sie naucz _uzywania_ liczb zmiennoprzecinkowych zamiast
> psioczyc na niby zle kompilatory :(
Dlaczego niby nie umiem?
Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Żeby programować dobrze w asemblerze na dany
> procesor, to trzeba mieć duże doświadczenie.
> Nie wiem jak duże... 2 lata po

Niewazne jak dlugo. Wazne jak/co.
Pamietam ze mialem "we lbie" czasy
wykonywania (ilosc cykli proc) wiekszosci rozkazow
(oczywiscie z wylaczeniem zmiennoprzecinkowych).
Np kiedys mov ax,0 a "kanoniczne" xor ax,ax to byla
dosc znaczna roznica.
Np . oplacalo sie tez czesto mov bx,sp
zamiast : push bp; mov bp, sp ; pop sp
Czy np inne "kanoniczne"
push cs
call near ptr
zamiast:
call far ptr
itp, itd
PS: pisanie C-liba w assemblerze nie mialo jednak
"podloza" wydajnosciowego, a calkiem inne/komucho-prozaiczne

AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Lepiej sie naucz _uzywania_ liczb zmiennoprzecinkowych zamiast
> psioczyc na niby zle kompilatory :(
> Dlaczego niby nie umiem?

Np. dlatego ze porownujesz liczby zmiennoprzecinkowe
"na ostro" a tego nie wolno robic (prawie) nigdy !

AK

do góry

W dniu poniedziałek, 25 marca 2013 15:12:32 UTC+1 użytkownik AK napisał:

> Np. dlatego ze porownujesz liczby zmiennoprzecinkowe
> "na ostro" a tego nie wolno robic (prawie) nigdy !
Nie chciałem powiedzieć ani że wolno, ani że nie wolno.

Chcę powiedzie tylko to, że jeśli zarówno argumenty funkcji
jak i zwracane wartości są sumą (całkowitych) potęg dwójki i
mieszczą się w zakresie liczby zmiennoprzecinkowej, to nie
ma żądnych ważnych powodów, aby procesor podał wartość
przybliżoną - wtedy może podać dokładną.

Jeśli w powyższych warunkach jedna para: kompilator, procesor
daje dokładną wartość, a druga nie daje, to chcę powiedzieć
tylko to, że ta pierwsza działa trochę dokładniej.

Niemniej temat czy wolno czy nie wolno jest ciekawy, nadawałby
się na osobny wątek. Mam taki jeden program, w którym
funkcja działa pod warunkiem że suma jej argumentów równa
się jeden. W trakcie długotrwałych obliczeń, algorytmem
ewolucyjnym przerzucam z jednego argumentu do drugiego
jakąś wartość. Np.
a = 0.75
b = 0.25
tmp = a * 0.25;
a -= tmp;
b += tmp;

Okazuje się, że często działa to zgodnie z oczekiwaniami, czyli
strata dokładności po dobie obliczeń jest w okolicach zera, albo
wręcz jest równa zero. Niestety na niektórych procesorach muszę
co ileś iteracji robić poprawkę straconej dokładności...

Niby można to wytłumaczyć tym, że na typie zmiennoprzecinkowym mamy
obliczenia przybliżone. Ale jeśli procesor/kompilator akurat dla jakiś
argumentów może dać dokładny wynik a nie daje... to ja jakoś wolę nazywać
gorszą jakością procesora czy kompilatora.

Pozdrawiam

do góry