Citat:
srki:
Ako se pravi kod koji ce raditi i na buducim masinama onda ne treba skoro nista rucno optimizovati jer ne mozemo znati da li ce buduca masina imati duplo veci ili triput veci kes, da li ce imati istu duzinu pajplajna itd...
Moje iskustvo je da kompilator (čak ni Intelov) neće pokušati da optimalno iskoristi keš, kao što je učinjeno u onom primeru množenja matrica koji si naveo u jednoj od prethodnih poruka. Razmeniće petlje, odmotati ih i preurediti jezgro da bi što bolje iskoristio fP jedinice i njihove cevovode, ali neće umetnuti dodatne petlje radi boljeg iskorišćenja podataka u kešu.
Citat:
Bilo bi zanimljivo pronaci razloge za to jer ako znamo razloge mozda bismo sitnom promenom koda mogli da nateramo jedan kompajler da optimizuje bolje.
Moje lično zapažanje je da je Intelov kompilator nekako jogunast, da GCC daje robusnije rezultate preko svega. Posebno sam uočio da Intel voli statički rezervisanu memoriju, umevao je da bude i dvostruko brži nego ako je memorija dinamički rezervisana. U jednom primeru Intel sa statičkom rezervacijom bio je ~15% brži od GCCa, a sa dinamičkom ~25% sporiji (GCC baš briga za način rezervacije). Možda je isto to došlo do izražaja i u gorepomenutom merenju performansi, ali nisam imao živaca da svrćem kôd na statičko rezervisanje.
Ideja za neki vudu-ples da bi se Intelov kompilator umilio da radi pošteno sa dinamičkom rezervacijom?