Citat:
gandalf
Takodje posle toga mislim da bi svako treba da nauci C++ posto obuhvata deo oko low level stvari: memorija, pointeri, kao i OOP. I sve preporuke idu da se nauci i neki funkcionalni jezik ( Scala, Erlang, Haskell.. )
Koliko je meni poznato, mozda gresim, u C++-u su pointeri tu samo zbog kompatibilnosti sa C kodom i gomilom biblioteka raspisanim za isti.
"Pravi" C++ kod ne bi trebao da koristi pointere (kao ni, npr, malloc) vec reference, koje su kud i kamo bezbednije od pointera.
Naravno, reference nisu magicno resenje posto mogu da unesu druge probleme ako programeru nisu najjasnije neke stvari, ali tako je sa svim stvarima u zivotu, nista nije dzabe.
Citat:
negyxo
Isto tako i lociranje memorije je automatizovano
Kome treba automatski menadzment memorije, ima GC. Medjutim, postoji gomila jako dobrih razloga zasto je dobro imati i fallback na menadzment memorije "na ruke".
Na primer, pises novi HPC program koji treba da procesira data set na makini sa 8 novih Ivy Bridge EX procesora sa ukupno 120 jezgara.
Tih 8 procesora su podeljeni u 8 NUMA nodova, gde svaki nod ima svoju memoriju.
Ukoliko ne radis alokaciju memorije "na ruke", OS i kompajler nisu dovoljno pametni da ti garantuju da ce memorija biti alocirana optimalno i tako da svaki worker thread bude:
a) Scheduleovan na poseban CPU
b) Radi sa memorijom alociranom u lokalnom NUMA nodu
Za optimalne performanse danas ti >moras< da prvo koristis neki low-level OS API (ili CPU instrukcije) kako bi dobio topologiju sistema, a onda na osnovu te topologije da kreiras optimalan broj radnih niti i "pin-ujes" ih na procesor/jezgro. Takodje, alokacija memorije mora biti takva da radna nit koristi, ako je moguce, memoriju koja je u NUMA nodu na kome trci ta nit.
Ako ovo ne uradis, mozes ocekivati pad performansi koji moze biti drastican ako se radi o memorijski intenzivnoj aplikaciji. Pristup memoriji na stranom NUMA nodu je bar 30-tak% sporiji a cesto i mnogo vise. To nije kraj price, posto pristupi stranim NUMA nodovima, takodje, generisu saobracaj preko processor interconnect bus-a i zauzimaju uncore resurse kada se sve ukombinuje nije iznenadjujuce videti i visestruko veci pad performansi cele aplikacije.
OS ce verovatno rasporediti niti na posebne procesore, ali slabe su sanse da ce ti memorijska alokacija biti optimalna. U najboljem slucaju ce ispasti optimalna u nekim slucajevima i razlikovace se u razlicitim izvrsavanjima programa.
Low-level stvari postoje sa jako dobrim razlogom. Za one kojima trebaju, naravno.
Ako neko kaze "pff, to je HPC... kome to treba" - tacno, HPC spada u <0.1% aplikacija ali operativni sistemi i ozbiljni programski jezici moraju da podrzavaju
i HPC, bas kao sto moraju da podrzavaju i mikrokontrolere, ves masine, game konzole, satelite, mobilne telefone i, naravno, Angry Birds. Zbog toga su C/C++ toliko uspesni, zato sto, ako treba, ljudima daju mogucnosti da urade tacno ono sto hoce.
Kome ne treba ta fleksibilnost naravno da je besmisleno da se insistira na rucnoj alokaciji memorije i sl... Ali je isto tako besmisleno insistirati na izbegavanju istih stvari po svaku cenu, zato sto postoje situacije gde su te stvari i te kako potrebne.
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos:
http://www.digicortex.net/node/17 Gallery:
http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! -
https://github.com/psyq321/PowerMonkey