Sta ce se brze izvrsiti?

Koristim pravo na repliku. :)


Zasto? Prilicno sam siguran da to nece promeniti rezultat u korist druge petlje, jer je pred svakom od navedenih petlji stojala jos jedna sa k od 0 do 20000. Optimizacija je bila vec iskljucena jer je razlika nakon optimizacije stvarno neprimetna, ako je uopste ima...

Potpis

Ipak se ++uje.

Da, nisam lepo procitao, ucinilo mi se da si rekao da je prva petlja radila sporije.
Pokazi nam i nacine na koji si merio efikasnosti (b>c)?(a=b):(a=c) i a=(b>c)?b:c. Da li si stavio u neku petlju u kojoj si alternativno menjao vrednosti b i c tako da je u jednom slucaju b<c a u drugom b>c ? To je jako bitno jer procesor pamti gde je bio skok pa ce da pretpostavi da ce i sledeci put biti isti skok kada ponovo izvrsava tu instrukciju.

Ne, nisam uopste pokusavao da napravim realnu situaciju. Samo sam bio pustio dugacku petlju sa datim kodom. Kod je zakacen za post.

Potpis

Ipak se ++uje.

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.


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?

Da sam znao da ce ovako daleko otici... :)

Potpis

Phearless - Serbian/Croatian Security Magazine: www.phearless.org

Mozda koristi neki svoj memorijski alokator koji je spor za objekte te velicine koje si ti koristio. Neki alokatori su u nekim slucajevima dobri a u nekima losi. Npr. kada se zahteva veliki broj alokacija za objekte male (fiksne!) velichine onda je dobro koristiti boost::pool alokator:
http://www.boost.org/libs/pool/doc/index.html

Pisano je malo o alokatorima ovde:
https://www.elitesecurity.org/...Boost-Pool-memorijski-alokator

gde ima link i ka ovoj temi:
http://www.codeproject.com/cpp/allocator.asp

Ako je zaista rad sa dinamickom memorijom boljka Intelovog kompajlera opet nije lose ako to znamo jer to onda mozemo i da promenimo. Slicno tome i za funkcije clanice koje ne menjaju sadrzaj objektra treba koristiti kljucnu rec const jer tako zaista mnogo mozemo da pomognemo kompajleru da optimizuje neke najobicnije petlje jer samo zbog te jedne kljucne reci on ce znati da funkcija ne menja objekat pa moze da pozove funciju i nekim drugacijim redosledom. Verujem da rucnim optimizacijama moze dosta stvari da se poboljsa ali bolje je taj trud uloziti na pisanje koda koji godi kompajleru jer na taj nacin isto mozemo da optimizujemo stvari uz cistiji kod a optimizacije ce raditi na bilo kom procesoru. Sve je stvar procene da li npr. platiti $50000 programeru (programerima) da potrose mesece rada na optimizovanju nekog koda za neki super racunar ili tih 50000 potrositi na unapredjivanje tig racunara sa brzim procesorima. Za takve stvari je najbolje pitati nekog operativnog menadzera jer su neki programeri dosta sujetni i vole da prckaju tamo gde postoji i jednostavniji nacin da se rese stvari. Menadzer moze da pogleda procenu vodje projekta o vremenu potrebnom za optimizaciju i onda da odluci sta da radi. I naravno pre bilo kakve optimizacije treba izvrsiti merenja i videti gde je bottleneck. Npr. ako imamo neki program koji cita gomilu podataka sa diska i obradjuje i stampa rezultate onda je gubljenje vremena optimizovati obradu podataka ako se ta obrada ionako brze izvrsava od citanja tih podataka sa diska. Merenjem mozemo videti sta najvise usporava program i onda dalje mozemo videti sta da radimo.