@combuster:
Citat:
Tacno, BP miss nas kosta onoliko koliko je dugacak sam instrukcijski pipeline, gubi se mnogo vise CPU ciklusa ako je pipeline duzi. Mada su oni isli na to da usavrse BP, AMD se sa K6 procesorima svojevremeno hvalio uspesnoscu pri BP-u od 95%.
Chak i ti promasaji su mali u odnosu na izmenu blokova u keshu. Penali za ovaj scenario su za nekoliko redova velicine veci.
Citat:
Inlining moze tu dosta da pomogne, mada ne treba preterivati kao i prefetch kod vrednosti za koje znas da ce se nenormalno mnogo potrazivati u kodu. Ono sto mene nervira je da je GCC postao mnogo pametan i koristi heuristiku za inlining pa ti sam inline-uje ili uninline-uje inline-ovanu funkciju od strane programera i na kraju kad ti naleti neki bug ne znas da li je bug u toj liniji koda ili onoj 1K linija iznad gde je definisana inline funkcija. Muke sam imao sa kernelom sa GCC 4.5 i opcijom CONFIG_OPTIMIZE_INLINING, jedno vreme sam mislio da je GCC puko (sto i nije daleko od istine).
Inline metode nece pomoci, jer je cena poziva zanemarljiva u odnosu na vreme potrebno da se memorija alocira ili obradi element strukture.
Tako nekako :)
@Nedeljko:
Citat:
Ako projekat to zahteva, onda je to neminovno i ne zavisi od izbora programskoj jezika.
Citat:
Ko te tera da koristiš više objekata nego što ti treba? U C++ se "(de)alokacija" uglavnom vrši na steku, dok ne potregneš new i delete ili strukture koje ih u sebi sadržr i kod kojih je to neizbežno. A neizbežno je iz malo fundamentalnijih razloga da bi to bilo specifično za programski jezik.
Da se ponovim - bilo je neophodno upotrebiti dinamicke strukture. Naravno da je fundamentalno pogresno pominjati stek u tom kontekstu.
Citat:
Mutex (un)lock je brza operacija ako se ne zahteva provera vlasništva niti nad mjuteksom, što OS neće ni da radi ako je mjuteks u njegovom vlasništvu. Problem može da nastupi samo ako dođe do zaglavljivanja jedne niti na njemu, jer ga je druga prethodno zaključala.
I ja mogu da trcim 500m/s... sve dok ne moram da krenem bilo gde :) Jedino u tom slucaju mi brzina pada. Dok sedim brz sam ko metak.
Citat:
Ako se new i delete različitih niti u najvećem broju slučajeva promašuju, onda je to mnogo brža operacija od traženja slobodnog bloka i zauzimanja memorije.
Odabran je C++ jer se cilja na visoke performanse. To znaci i da ce sistem raditi pod znacajnim opterecenjem. Ako uzmes da je code base uveliko presao milion loc.. ostaje samo bleda nada da ce se alokacije masiti..
@mmix:
Citat:
Problem sa heap globalnim spinlockom je resen u Windows 7/2008r2 kernelu. Drugo, to je ionako kacilo C++-evce ;) CLR (a i JRT) prealociraju memoriju u svoj intenrni heap koji vise ne zavisi od global locka, naravno uz space tradeoff.
Jos jedna prednost CLR-a je generacijski garbage collector koji grupise objekte po starosti. Osim toga i JRT i CRT tokom zivota objekata mogu da menjaju njihovu lokaciju u memoriji, kako bi sprecili fragmentaciju i popravili performanse kesha.
Uglavnom, tehnike pomocu kojih Java i C# ublazavaju problem kesh promasaja je digresija.
Zeleo sam da ukazem na hardverski bottleneck izmedju CPU-a i memorije..