Dnia Mon, 25 Mar 2013 16:30:27 +0100, wloochacz wyszeptal:

> W dniu 2013-03-25 16:03, Edek Pienkowski pisze:
>> Dnia Mon, 25 Mar 2013 14:17:01 +0100, wloochacz wyszeptal:

>> 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.
> Tak wiem - ale ręcznie, tzn. optymalnie (a przynajmniej lepiej niż
> kompilator ogólnego przeznaczenia), prawda?
> I tak, IMO, jest to podpowiedź na to pytanie - poniekąd.
> Mamy tu porównanie kodu generowanego przez kompilator z kodem
> zoptymalizowanym ręcznie.

To nie jest kod zoptymalizowany ręcznie, porównujesz jabłka do
czereśni. To jest kod pisany wiele razy, testowany, mierzony i
poprawiany wiele razy ręcznie. Znajdź kod pisany ręcznie raz,
tak jak kompilator kompiluje raz, i wtedy porównaj to co wyjdzie.

> A poniekąd dlatego, że nie wiemy dokładnie jak zrealizowano to zadanie
> przez "zeranoe", także ciężko cokolwiek porównywać w "twardych" śiśle
> mierzalnych testach...
> Ja sobie gdybam, że mocno zoptymalizowany kod pod konkretne zadanie (tu
> - kodowanie x264) jest tylko 3x szybszy od kompilatora ogólnego
> przeznaczania.
> I teraz jest pytanie - jest to *tylko* czy *aż* 3x szybszy kod?

Robi się *aż* takie rzeczy, jak wiele implementacji i przy starcie
mierzona jest wydajność wszystkich na sprzęcie i wybiera
najlepszą. BTW, to mi podsuwa pewien pomysł..

>> 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.
> Co nie znaczy, że nie istnieje...

Ale oznacza, że kompilator przetwarzając program nie wie ile i jakich
będzie danych, a piszący ręcznie wie. Dlatego jest inny rezultat.

--
Edek