optimizare c++

Intrebari despre limbajul C++, standardul C++, STL, OOP in C++ sau alte subiecte nelegate de VisualC++
Post Reply
viorel2005
Membru
Membru
Posts: 208
Joined: 24 May 2008, 09:41

optimizare c++

Post by viorel2005 » 17 Jul 2010, 12:30

Salut!

Din cartea:Optimizing C++,scrisa de:Harriet Gecks
Early address calculation

Try to calculate the value of a pointer or iterator somewhat before when
you need to access the referenced object.
For example, in a loop, the following statement:
a = *++p;
may be a bit less efficient then the following:
a = *p++;
In the first case, the value of the pointer or iterator is calculated just before it
is used to access the referenced object, while in the second case it is
computed in the previous iteration.

In a pipelined processor, in the second
case, the increment of the pointer may be performed simultaneously with the
access of the referenced object, while in the first case the two operations
must be serialized.
Care este de fapt diferenta dintre cazuri?Mai concret pe ce tip de procesor e favorabil unui caz sau altul.
Testele efectuate de user-ul jos8cal :

http://www.codexpert.ro/forum/viewtopic.php?f=13&t=1449

nu tin cont de arhitectura procesorului. Iar problema de fapt este:
tinand cont ca acum sunt in era multi-core, e nevoie ca C++ sa includa la nivel de limbaj anunite extensii
care sa permita implementarea multicore sa fie independenta de arhitectura procesorului?

O alta intrebare este daca la firmele unde lucrati, codul este optimizat multicore?



User avatar
Ovidiu Cucu
Fondator
Fondator
Posts: 3778
Joined: 11 Jul 2007, 16:10
Judet: Iaşi
Location: Iasi
Contact:

Re: optimizare c++

Post by Ovidiu Cucu » 20 Jul 2010, 17:49

The Cardinal Rules of Optimization:
1. Do not optimize
2. For experts only: do not optimize yet

User avatar
MrSmersh
Microsoft MVP
Microsoft MVP
Posts: 289
Joined: 20 Jul 2007, 10:18
Location: Timisoara
Contact:

Re: optimizare c++

Post by MrSmersh » 20 Jul 2010, 21:18

Sau unu dintre cei care s-au chinuit sa ma invete ceva C++ spunea, nu incerca sa fi mai destept decit compilatorul, da pe 1x (continuat cu =0 :)) erau o tona de optmizari in cod, dar acuma compilatorul le face automat, si daca incerci optimizarile ii dai de lucru ca nu mai recunoaste patternu. My 5 bani :)

User avatar
mihk
Junior
Junior
Posts: 39
Joined: 03 Jul 2009, 14:51

Re: optimizare c++

Post by mihk » 21 Jul 2010, 17:46

viorel2005 wrote: Iar problema de fapt este:
tinand cont ca acum sunt in era multi-core, e nevoie ca C++ sa includa la nivel de limbaj anunite extensii
care sa permita implementarea multicore sa fie independenta de arhitectura procesorului?

O alta intrebare este daca la firmele unde lucrati, codul este optimizat multicore?
1. Vezi OpenMP daca iti place. https://computing.llnl.gov/tutorials/op ... rcise.html
Nu cred ca vor pune in C++ ISO asa ceva.
2. este destul de greu sa obtii paralelism in executie cand toate aplicatiile si librariile sunt vechi de 10 ani, si mai nimic nu e threading safe.
Caut profesor.

User avatar
Silviu Ardelean
Senior
Senior
Posts: 1175
Joined: 12 Jul 2007, 09:22
Judet: Timiş
Location: Timisoara
Contact:

Re: optimizare c++

Post by Silviu Ardelean » 24 Jul 2010, 22:24

Acum citesc si eu acest topic. Viorel, sincer, ptr. discutia cu operatorii post/pre incrementare, nu prea vad ce treaba sa aibe treaba de procesare paralela. :D
Propun sa lasi povestile de-o parte si mai bine sa vezi cum sunt implementate lucrurile, folosind tasta magica F12 (daca folosesti VS). :) De asemenea, nici teste concrete (chiar daca sunt influentate de optimizarile compilatorului) nu sunt de ignorat.
In FAQ-ul respectiv dau detalii despre cum sunt implementati cei 2 operatori. Privind aceste implementari de operatori ai zice oricand ca ce zic eu acolo e sigur 100%. Numai ca, in zilele noastre, lucrurile au evoluat si optimizarile compilatorului pot rasturna situatia in cazul benchmark-urilor.

User avatar
cristianamarie
Membru++
Membru++
Posts: 480
Joined: 12 Mar 2009, 18:47
Judet: Iaşi
Location: Iasi

Re: optimizare c++

Post by cristianamarie » 25 Jul 2010, 09:19

Ma bag si eu cu un citat din Peter Viscarola (Peter Pontificates -- OSR) despre optimizari (citat aproximativ)
"Back in the old days, I used to wrote assembler saying 'show me a compiler that is better than me on optimizing assembler code'.
Now the compilers are a hell of a lot better than I was [...] when comes to optimize assembler code. And I was good."

Presupun ca discutia nu e ca trebuie sa dispara optimizarile, evident. Doar ca undeva la > 90% acum sint rezolvate de compilator.
Ramin cele de 10% (cred ca regula lui 90-10), unde mai degraba tin de proiectare. Degeaba incercam sa sortam o lista uriasa, cind mai bun era un map sau un hash table, de fapt. Cel putin 50% - empiric vorbesc - cred ca se incadreaza si ele aici. Ramin deci un sub 5% de chestii cu adevarat groase.

Cit despre operatorul ++, presupun ca depinde de context, dar regula de baza ar fi ca postfix face o copie, pe cind prefix e direct pe obiect.
In exemplul de mai sus

Code: Select all

a = *++p;
a = *p++; 
ar fi probabil de vazut ce cod asm se genereaza. Presupun ca e acelasi cod generat de compilator, evident, flagii de compilare si compilatorul in sine conteaza (nu am verificat), dar treaba mai importanta aici e cine e p mai mult decit codul generat.
Daca se produce o copie de p, si p e scump, aia e. Daca mai sare si un volatile pe undeva... se deschid ceva paranteze.

PS Uite cu ce ne batem noi capul, in loc sa facem un

Code: Select all

a = System.Core.Integer(IntPtr(p)).Deref().Increment();
:D
Nuclear launch detected

User avatar
Andreas
Membru
Membru
Posts: 117
Joined: 09 Nov 2008, 12:13
Judet: Timiş
Location: Timisoara

Re: optimizare c++

Post by Andreas » 26 Jul 2010, 13:43

cu siguranta cazul prezentat are legatura cu executia multicore/paralela...
deci avem:

Code: Select all

a = *++p;
a = *p++;
plecand de la ipoteza ca flow-ul din program asigura aceeasi valoare dereferentiata a pointerului p, exista o diferenta majora de interpretare pe care o face compilatorul pe o platforma multicore: in primul caz a=*++p, pentru ca outputul lui "++p"(urmatoarea adresa), sa-i zicem y, este input pentru *y, inseamana ca acest cod nu poate fi procesat "in paralel" in doua linii de executie separate, pentru ca trebuie sa se astepte "sincron" incrementarea pointerului, asa ca se va genera cod masina pentru un singur core; in al doilea caz, output-ul pentru "p++" este deja generat(avem deja pregatita urmatoarea adresa) de undeva din executia anterioara a programaului si atunci compilatorul poate sa optimizeze codul masina pentru executia multicore, adica sa incarce adresa intr-o linie si sa faca operatiile ulterioare(deref, assignare etc.) si in alta linie sa faca incrementarea pointerului, pentru ca rezultatele din liniile de executie nu sunt interdependente
cred ca despre asta e vorba aici...si nu conteaza complexitatea lui p...
un alt exemplu ar pute fi gasit:aici
in cazul incrementarilor/decrementarilor de tipuri primare fara asignare, in vremurile de azi, orice compilator comercial genereaza acelasi asm, deci nu mai conteaza diferenta...la fel si la iteratori, repet daca nu se fac asignari(cazul parcurgeri containerelor cu for)...
legat de interviu: consider ca e mai important sa inteleaga problema decat sa o stie "a priori"...

lize1
Junior
Junior
Posts: 1
Joined: 21 Jun 2012, 15:32
Judet: Alba

Re: optimizare c++

Post by lize1 » 21 Jun 2012, 15:33

destul de interesant :D

User avatar
bu7ch3r
Membru++
Membru++
Posts: 326
Joined: 17 May 2011, 15:17
Judet: Iaşi
Location: Sofia
Contact:

Re: optimizare c++

Post by bu7ch3r » 21 Jun 2012, 22:11

:-? Eu nu intleg ce treaba are ce zice Gecks cu multicore? Acuma daca zice cineva ca se face incrementarea pe un core si indirectarea pe altu ma inpushc in gat(ca tot e la moda):P
Cu stima,
Lupu Claudiu

User avatar
Silviu Ardelean
Senior
Senior
Posts: 1175
Joined: 12 Jul 2007, 09:22
Judet: Timiş
Location: Timisoara
Contact:

Re: optimizare c++

Post by Silviu Ardelean » 22 Jun 2012, 14:38

Trecand peste spam-ul mascat al lui lize1 cred ca subiectul e departe de-a fi epuziat.
tinand cont ca acum sunt in era multi-core, e nevoie ca C++ sa includa la nivel de limbaj anunite extensii
care sa permita implementarea multicore sa fie independenta de arhitectura procesorului?
In cazul utilizarii mai multor core-uri problema se pune diferit si nu cred ca e vorba de-a incrementarea pe un core si indirectarea pe altul.
Pentru a pune la treaba mai multe core-urile folosesti thread-uri sau task-uri din librarii de procesare paralela (gen OpenMP sau PPL), librarii ce "stiu" sa optimizeze entitati ce pot fi paralelizate pentru a rula pe core-uri diferite. Intr-un final OS-ul decide ce core va trata un anume thread.
Atentie! Nu orice se preteaza a fi paralelizabil. De exemplu, daca ai de lucru cu accesul I/O a te apuca sa paralelizezi citirea/scriere nu e o idee prea fericita si nu vei obtine performanta asteptata. Ba dimpotriva...
In schimb, daca ai un loop printr-o colectie de date / container / buffer(ex. o imagine) in memorie, pe care le poti impartii in mai multe entitati independente atunci se preteaza sa faci paralelism.

Un aspect important de care trebuie sa ai grija in momentul paralelizarii e sa nu ai race conditions sau wrong variable shared. Daca folosesti mutexul corespunzator, chiar daca rulezi in paralel si faci ++p sau p++ apelul e efectuat pe un singur core caci intr-un final e executat intr-un thread per core. PPL iti ofera combinable class ce te ajuta sa ai thread-safe dar si sa-ti combini rezultatele optinute pe core-uri diferite intr-un rezultat final.

Viorel, daca te mai intereseaza poveste pre-post increment in multi-core environment poti da o geana pe un articol. Si echipa Visual C++ recomanda pre-increment. Daca se va rula aplicatia demo pe VS2010 pe o masina multi-core se poate observa cum fiecare core va procesa o bucata din container in mod independent. Si pentru ca folosesc clasa combinable mai sus mentionata nu avem parte de nici o "coliziune".

Post Reply