🚀 go-pugleaf

Dnia 08.10.2012 orcus@pwr.wroc.pl <orcus@pwr.wroc.pl> napisał/a:
> On 2012-10-08, Baranosiu <rad_n@wp.pl> wrote:
>> Żaden kompilator nie zastąpi myślenia :D
>
> Przy sporze o to który samochód może pojechać szybciej
> z 4 osobami i bagażami w środku też można powiedzieć, że
> mój - przecież bez tych 4 osób jest najszybszy...

Samochód może i jest nieco szybszy, ale to w jakim czasie pokonasz
trasę od punktu A do pnktu B zależy też od kierowcy :D

Co do mojego posta: od kilku lat nie używam icc i nie wiem jak on się
ma teraz do gcc, ale nigdy różnica nie była aż 12-krotna :D Autorzy
chyba "na szybko" pisali ten kod w książce (swoją drogą ja bym się
nawet wstydził opublikowac kod z takim formatowaniem :D) i trafił się
przypadek, w którym wyjątkowo icc sobie poradził kilkunastokrotnie
lepiej, więc odpisałem autorowi pytania, że "diabeł" tkwi w samym
indeksowaniu. Gdyby to były tablice zadeklarowane jako c[500][500] i
b[500][500] to szło by jak burza bo wyliczenie adresu elementu jest
proste, a skoro tablice są zadeklarowane jako **b i **c i potem
"ręcznie" są alokowane miejsca dla każdego wiersza z osobna, to te
wiersze nie muszą leżeć w pamięci "jeden za drugim", więc wyliczenie
adresu elementu przestaje być prostym mnożeniem i dodawaniem, tylko
trzeba "pobiegać" po pamięci. GCC akurat jest tak napisany, że
optymalizator lepiej sobie radzi, jeśli wewnątrz pętli zmienia się
ostatni indeks, bo wtedy nie trzeba za każdym razem wyliczać początku
wiersza (choć mógłby też zauważyć, że wyrażenie c[i][j] wewnątrz
najbardziej zagnieżdżonej pętli wskazuje zawsze na ten sam element i
nie trzeba go za każdym razem wyliczać, ale jak się okazuje, przy
niewielkim nakładzie pracy można "nieznacznie" pomóc kompilatorowi i
przyspieszyć kod nawet kilkunastokrotnie :D).