Dnia Mon, 25 Mar 2013 14:17:01 +0100, wloochacz wyszeptal:

> 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

To *nie* jest odpowiedź na pytanie. Od dawna wiadomo, że kompilatory
w brzegowych przypadkach dają wolniejszy kod - dotyczy to *bardzo małych*
procedur operujących na *dużych danych*, czyli video, raid, szyfrowanie.
Takie opłaca się pisać ręcznie.

Gdyby kompilator miał je optymalizować porządnie, co najmniej trzeba
by przekazać kompilatorowi informację "poświęć na te 100 linijek 30%
czasu kompilacji poświęcanego na milion linii reszty kodu". Nie
ma czegoś takiego w językach programowania, więc kompilatory optymalizują
cały program i tu już są w granicach 10%. Niby jest PGO, ale jest
mało używane więc mało rozwijane, dodatkowo dochodzi detekcja sprzętu,
więc poważne PGO powinno mieć farmę testową różnych maszyn dla
sprawdzenia - nie widziałem nigdy takiej implementacji.

Pokazywanie znanych warunków brzegowych niczego nie dowodzi.

> 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!"

Mój GPU na płycie z Atomem robi to ze 20x szybciej, tylko co z tego?

--
Edek