Regruparea calculelor

Regruparea calculelor este o modalitate de a reduce numărul ciclurilor mașină. În secvența:
s1=0;
for(i=0;i <n; i++) s1+=x[i];
s2=0;
for(i=0;i <n; i++) s2+=x[i]*x[i];
s3=0;
for(i=0;i  <n; i++)  s3+=x[i]*x[i]+x[i];
sxy=0;
for(i=0;i  <n; i++) sxy+=x[i]*y[i];
prin regruparea intr-o singura structura repetitiva, devine:
s1=0;
s2=0;
s3=0;
sxy=0;
for(i=0;i <n; i++)
            {
             s1+=x[i];
             s2+=x[i]*x[i];
             s3+=x[i]*x[i]+x[i];
             sxy+=x[i]*y[i];
             }
Dacă numărul de cicluri variază se vor găsi modalități de  a face ceea ce trebuie și de a rezolva problema.
Dacă se consideră secvența:
s1=0;
for(i=0;i <n; i++) s1+=x[i];
s2=0;
for(i=0;i <m; i++) s2+=x[i]*x[i];
și dacă m= n+2, atunci sevența inițială prin  optimizare devine;
s1=0;
s2=0;
for(i=0;i <n; i++)
            {
             s1+=x[i];
             s2+=x[i]*x[i];
             }
s2+=x[n]*x[n] + x[n+1]*x[n+1] ;
și se vede că se țin sub control numărul de repetări ale instrucțiunii for() care apare o singură dată, ceea ce la o analiză atentă este un lucru benefic. Regruparea de calcule presupune ca secvențele să fie independente între ele, ceea ce se întâlnește destul de des în programe.

(023 decembrie 2017)

Factorul de blocare

Factorul de blocare este legat de modul în care se dispun articolele în fișiere. Există două noțiuni:
- articolul logic;
- înregistrarea la nivel fizic.
Se citește o cantitate de informație de lungime fixă numită înregistrare la nivel fizic. Programatorul definește articolul unui fișier funcție de datele cu care lucrează. Articolul definit de programator are o lungime dată de suma lngimilor câmpurilor ce-l compun. Dacă lungimea articolului așa cum este definit de programator este cu mici diferențe cam aceeași ca lungimea articolului fizic, se memorează un articol logic în ceea ce se scrie în fișier. Rezultă că numărul de operații de scriere dat de numărul de articole la nivel fizic, este egal cu numărul de articole pe care programatorul este interesat să le scrie în fișier.
Dacă articolul definit de programator este foarte mic, el are posibilitatea să pună acele articole, mai multe într-un articol și să facă o singură scriere pe suport. Acel număr maxim de articole care încaă intr-un articol fizic se numește factor maxim de blocare. De exemplu, dacă articolul fizic are 1024 bytes și articolul definit de programator are 300 bytes, factorul de blocare este 3, căci maximul 3 articole definite de programator încap într-un articol la nivel fizic și mai rămân neutilizați 124 bytes. dacă programatorul vrea să scrie 600 de articole ce corespund celor 600 de elemente ale unei colectivități de care se ocupă programul său, la nivel fizic se vor scrie grupe de câte 3 articole logice. Deci la nivel fizic se vor executa 200 de operații de scriere ceea ce e mare lucru comparativ cu programul în care corespondența este de 1 la 1, adică un articol de 300 de bytes se scrie în cei 1024 ai articolului fizic și cele 600 de articole se vor scrie unul câte unul.
Fiecare sistem de calcul, fiecare sistem de operare are tabele cu factorii de blocare și programatorii eficienți nu lasă lucrurile la voia întâmplării nici în ziua de azi.

(023 decembrie 2017)

Gestionarea conversiilor de tip

Gestionarea conversiilor de tip este importantă pentru că ele ascund în spate conversii de tip. Sunt compilatoare care gestionează ele acest lucru.
În secvența:
INTEGER A,B,C,D,X
REAL I, K
A=2.
B=3
C=18.
D=32
I=100
K=D/15+C/22.
X=K
au loc destul de multe conversii. Dacă nu se dispune de compilator care să festioneze el însuși conversiile se produc următoarele conversii:
- constanta 2. este de tip real și se face conversie spre întreg pentru a se face inițializarea variabilei A; programatorul care știe despre ce este vorba cu siguranță ar fi scris din prima A=2, 2 fiind de tip întreg ca variabila A;
- la fel se întâmplă și la inițializarea C=18. fiind necesară o conversie;
- variabila I este de tip real are o reprezentare internă care diferă de cea a constantei 100 care este de tip întreg, fiind necesară și în acest caz conversie de la întref spre real;
- în expresia K=D/15+C/22. tipul dominant este cel real și de aceea înainte de a se face evaluările se fac conversii a tot ceea ce este de tip întreg spre tipul real;
- conversie se face și de la real spre întreg să se evalueze expresia X=K.
Chestiuni neînsemnate uneori duc la volume foarte mari de cicluri mașină și numai programatorii care știu limbaje de asamblare își dau seama ce și cum la nivelul acestor chestiuni de finețe.

(023 decembrie 2017)

Reducerea apelurilor

Reducerea apelurilor de funcții și de proceduri este benefic dacă și numai dacă are un rol de a compensa creșterea lungimii programului prin creșterea numărului de instrucțiuni din secvențe similare, care au justificat regruparea în subrutine.
Trebuie spus că la apelul unei subrutine, oricare ar fi tipul ei, se produc niște lucruri, care se concretizează prin cicluri mașină.
Într-un program fortran dacă se dorește să se calculeze patru medii aritmetice vom proceda astfel:
- scriem un subprogram de calcul pentru media aritmetică;
- apelăm subprogramul de patru ori schimbând parametrii:
- subprogramul realizează transferul de parametrii;
- subprogramul efectuează returnarea rezultatului;
- subprogramul efectuează reansfer la instrucțiunea următoare.
Probabil, pentru a evita salturile din apelator în subprogram și din subprogram în apelator, este mai rezonabil să se încorporeze inteligent instrucțiunile de calcul ale mediilor direct în apelator.Dacă voi scrie fără a apela subprograme, textul va fi:
             DIMENSION X(100), Y(100), Z(100), WW(100)
             INTEGER I, N
             INTEGER MEDX,MEDY,MEDZ,MEDW
             REAL SUMX, SUMY, SUMZ, SUMW
C          INITIALIZARI NUMAR COMPONENTE
C          INITIALIZARI SERII DE DATE
             SUMX=0
             SUMY=0
             SUMZ=0
             SUMW=0
........................................
             DO 50 I=1,N
             SUMX=SUMX+X(I) 
             SUMY=SUMX+Y(I) 
             SUMZ=SUMX+Z(I) 
50         SUMW=SUMX+W(I)
             SUMX=SUMX
             MEDX=SUMX /N
             MEDY=SUMY /N
             MEDZ=SUMZ /N
             MEDW=SUMW /N
..................................
C          INSTRUCTIUNI DE SCRIERE  A REZULTATELOR

Se observă că textul sursă este mai lunguț, dar nu conține niciun apel prin CALL și nico revenire în apelator prin RETURN, dar dacă mai se ține seama că suprobramele s-ar încărca în segmente diferite, salturile intersegment au un număr de cicluri mașină înfiorător de mari, lucru demonstrat în toate manualele de prezentare a limbajelor de asamblare, care se respectă și care intră în astfel de detalii.
Dacă ar fi să calculăm media folosind un subprogram acesta va avea forma:
C          SUBPROGRAM DE CALCUL MEDIE ARITMETICA
             SUBROUTINE MEDIA (X, N,XMED)
             DIMENSION X(N)
             INTEGER I
             REAL    SUM
             SUM=0
             DO 10  I=1,N
10         SUM=SUM+X(I)
             XMED=SUM/FLOAT(N)
             RETURN
             END
În acest text sursă variabilele X, N,XMED se numesc parametrii formali. Programul apelator va conține instrucțiunile:
             DIMENSION X(100), Y(100), Z(100), WW(100)
             INTEGER I, N
             INTEGER MEDX,MEDY,MEDZ,MEDW
             REAL SUMX, SUMY, SUMZ, SUMW
C          INITIALIZARI NUMAR COMPONENTE
C          INITIALIZARI SERII DE DATE

........................................
             CALL  (X, N,XMED)
             CALL  (Y, N,YMED)
             CALL  (Z, N,ZMED)
             CALL  (W, N,WMED)
..................................
C           INSTRUCȚIUNI DE SCRIERE MEDII: 
C           XMED,YMED, ZMED, WMED
Sunt situații unde așa ceva nu este rentabil. Programatorul va face evaluările astfel încât ceea ce obține să fie un program cât de cât eficient dacă a obține un program optim este prea pretențios. În celelalte limbaje tot cam așa stau lucrurile deși multe dintre proceduri se scriu direct nemaifiind necesară o instrucțiune de tip CALL ca pe vremuri, dar tot se produc salturi  necondiționate  la apel și la revenire chiar dacă sunt intersegment sau intrasegment tot hulitele  salturi necondiționate sunt.

(05 decembrie 2017)

Înjumătățirea repetărilor

Înjumătățirea repetărilor este un mod de a optimiza și eficiența se vede foarte clar, prin reducerea volumului de prelucrări dat în cicluri mașină care însoțesc repetările instrucțiunii for().

Secvența:
int n, i;
int a[100];
int sa=0;
..............
for(i=0; i < n; i++) sa+=a[i];
.......................

conține n repetări ale instrucțiunii for().

Dacă numărul de repetări n este un număr par, n=2*k este mult mai eficientă secvența:

int n, n, i;

int a[100];

int sa=0;

k=n/2;

..............

for(i=0; i < n; i++) 

    {

     sa+=a[i];

     sa+=a[k+i];

      }

.......................

căci instrucțiunea for() are un număr de execuții înjumătățit. Pentru a elimina restricția aceea legată de faptul că n trebuie să fie număr par se construiește o formă generală a secvenței care are devine:

int n, n, p,i;

int a[100];

int sa=0;

k=n/2;

p=n%2;

..............

for(i=0; i < n; i++) 

    {

     sa+=a[i];

     sa+=a[k+i];

      }

if(p)  sa+=a[n-1];

.......................

Sunt multe situațiile în care acest mod de lucru este benefic, mai ales în calculele statistice unde se lucrează cu serii de date de aceeași lungime și cu fiecare serie se fac anumite calcule, care presupun traversarea termen cu termen a fiecărei serii, calculele fiind independente în raport cu termenii.
Înjumătățirea repetărilor duce la creșterea vitezei de rulare a întregului program, ceea ce este benefic și nu presupune un efort prea mare din partea programatorilor, căci instrucțiunea for(0 la numărătoare este una singură, dar ea include mai multe expresii a cărăr evaluare are caracter repetitiv, ceea ce înseamnă multe cicluri mașină, deci timp în plus.

(023 decembrie 2017)

Eliminarea duplicării de cod

Eliminarea duplicării de cod are efecte foarte bune asupra volumului de calcule, căci un rogram va arăta cu toeastă optimizare pe text sursă este efectuată îngrijit și complet. Totul se vede în cazul în care din start secvențele sunt scrise așa cum sunt descriși pașii algoritmului și programatorul vede că nu există dependențe între ele.

Secvența:

int n, i;

int a[100];

int b[100];

int c[100];

int d[100];

int sa=sb=sc=sd=0;

..............

for(i=0; i < n; i++) sa+=a[i];

for(i=0; i < n; i++) sb+=b[i];

for(i=0; i < n; i++) sc+=c[i];

for(i=0; i < n; i++) sd+=d[i];

.......................

conține de patru ori același număr de repetări executate independent pentru calculul celor patru sume, ceea ce aplicând o modalitate de a concentra toate calculele intermediare într-un bloc va duce la secvența:

int n, i;

int a[100];

int b[100];

int c[100];

int d[100];

int sa=sb=sc=sd=0;

..............

for(i=0; i < n; i++) 

       { 

        sa+=a[i];

        sb+=b[i];

        sc+=c[i];

        sd+=d[i];

        }

.......................

care este mult mai elegantă, iar din punct de vedere al volumului de calcule mult mai eficientă, căci lipsesc cele patru instrucțiuni for(), care sunt înlocuite de o singură astfel de instrucțiune.
În secvența:
int i, s=0;
................
s=0;
for(i=0; i < n; i++) sa+=a[i];
.............................
a doua inițializare cu zero a variabilei s nu se justifică dacă nu s-a mai lucrat cu aceasta până la electuarea acelei însumări repetitive.
Ori se va scrie secvența:
int i, s=0;
................
for(i=0; i < n; i++) sa+=a[i];
.............................
ori secvența de instrucțiuni:
int i, s;
................
s=0;
for(i=0; i < n; i++) sa+=a[i];
.............................
Eliminarea duplicării de cod vizează fie concentrări de secvențe, fie instrucțiuni puse în program neglijent care se văd de la o poștă că sunt în plus, pentru că fac același lucru de două sau mai multe ori.

[]

{ }

<

>

{ }

<

>

(04 decembrie 2017)

Criterii de optim

Criteriile de optim sunt importante căci de la ele pornește totul.  Astfel de criterii sunt:
- maximizrea dimensiunii problemei de rezolvat;
- maximizarea nivelului calitatii agregate a produsului software;
- maximizrea  fiabilității produsului software;
- maximizrea preciziei rezultatelor;
- maximizarea  flexibilitățiiin structurii cheilor în procesul de regăsire;
- maximizrea gradului de satisfacție al utilizatorului;
- maximizrea nivelului de secutitate al produsului software;
- maximizrea productivității echipei de dezvoltare;
- maximizrea  gradului de acoperire prin testare a ramurilor produsului software;
- maximizarea gradului de generalitate a probelelor de rezolvat;
- maximizrea duratei etapei de utilizare;
- maximizarea gradului de ocupare a masivelor definite static;
- maximizarea elementelor care asigură continuitatea în interfețe;
- minimizarea costului de construire a unui produs software;
- minimizarea costului calității produsului software;
- minimizarea duratei tranzacției;
- minimizarea duratei procesului de mentenanță;
- minimizarea lungimii efectului de ondulană;
- minimizarea necesarului de memorie;
- minimizarea lungimii produsului software;
- minimizarea ciclurilor mașină;
- minimizarea duratei de realizare a produsului;
- minimizarea complexității programului;
- minimizarea volumului de date necesar pentru regăsire;
- minimizarea  numărului de fișiere utilizate în program;
- minimizarea  numărului de încărcări/descărcări de pe server;
- minimizarea expresiilor logice din selectarea articolelor;
- minimizarea volumului de variabile de tip static;
- minimizarea numărului de apeluri de proceduri;
- minimizarea numărului de instrucțiun return executate;
- minimizarea numărului de instrucțiuni de salt necondiționat;
- minimizarea volumului de instrucțiuni prin duplicare de cod;
- minimizarea  volumului de conversii de tip;
- minimizarea listelor de parametrii.
Procesul de optimizare este în cazul produselor software de o mare complexitate și tot timpul trebuie găsit un echilibru, căci se urmărește de regulă satisfacerea mai multor criterii de optim simultan, ceea ce este deosebit de dificil de obținut. Este rezonabil să se extragă o submulțime de criterii și acestora să li se dea note, iar după aceea să li se calculeze coeficienții de importanță și criteriile să fie agregate folosind acele ponderi, care din timp în timp trebuie recalculate.
Criteriile  de optim sunt dorințe intime ale oricărui programator, dar punerea în operă este anevoioasă că programatorul nu face ce vrea el și are nenumărate constrângeri de care trebuie să țină seama. Uneori deși îmi propusesem să scriu cel mai fain program din câte existau pe planetă, beneficiarul, dar și șefii veneau cu biciușca și mă mânau de la spate și nu numai că uitam de visul meu frumos, dar o mai și zbârceam. Lucrul cel mai urât este să știi unde ai greșit și să nu ai cum să-ți îndrepți greșeala dintr-o mie de motive, care mai de care mai obiective, indispensabile, presante și imposibil de controlat.

(023 decembrie 2017)

Eliminarea subexpreiilor comune

Eliminarea subexpreiilor comune nu se explică prea bine în cuvinte, ci trebuie venit cu un exemplu. Se consideră expresia:

se vede acolo că o subexpresie notată de mine cu s se repetă

Dacă o înlocuim, expresia e devine:

Complexitatea primei expresii include:
- operanzii diferiți e, a, b, c,  3, 1, 2,4, numărul lor fiind de 8;
- operatorii diferiți sunt  =, +, *. -, /, pow numărul lor fiind 6;
- complexitatea C a expresiei este C = 8 * log2 8 + 6 * log2 6 =39,51  .
Dacă este eliminată subexpreis comună, atunci cele două expresii s și e concuc la:
- operanzi utilizați e, a, b, c, s,  3, 1, 2,4, numărul lor fiind de 9;
- operatorii diferiți sunt  =, +, *. -, /, pow numărul lor fiind 6;
- complexitatea C a expresiilor este C = 9 * log2 9 + 6 * log2 6 = 44,04 , ceea ce înseamnă că eliminarea subexpresilor comune cu complexitatea calculată luând diversitatea operanzilor și operatorilor nu este profitabilă.
Dacă însă se ține seama de operanzii și operatorii care apar efectiv în expresia inițială, se observă că:
- variabila a apare de 4 ori;
- variabila b apare de 4 ori;
- variabila c apare de 4 ori;
- variabila e  apare o dată;
- constanta 1 apare o dată;
- constanta 3 apare o dată;
- constanta 2 apare o dată;
- constanta 4 apare o dată;
- operatorul de atribuire apare o singură dată;
- operatorul de împărțire /, apare o singură dată;
- operatorul de adunare +, apare de 10 ori;
- operatorul de scădere, apare de 2 ori;
- operatorul de ridicare la putere pe care l-am notat pow, apare de 12 ori;
- operatorul de înmulțire *, apare de 2 ori.
Rezultă că expresia e are  17 operanzi și 28 de operatori ceea ce conduce la o conplexitate calculată de C = 204,075.
În cazul în care se optimizează prin înlocuirea subexpresiei comune se identifică frecvențele:
- variabila a apare  o singură dată;
- variabila b apare  o singură dată;
- variabila c apare   o singură dată;
- variabila e  apare o dată;
- variabila e  apare de 5 ori;
- constanta 1 apare o dată;
- constanta 3 apare o dată;
- constanta 2 apare o dată;
- constanta 4 apare o dată;
- operatorul de atribuire apare 2 ori;
- operatorul de împărțire /, apare o singură dată;
- operatorul de adunare +, apare de 4 ori;
- operatorul de scădere, apare de 2 ori;
- operatorul de ridicare la putere pe care l-am notat pow, apare de 3 ori;
- operatorul de înmulțire *, apare de 2 ori.
Cele două expresii au 13 operanzi și 14noperatori. Complexitatea C  după eliminarea subexpresiilor comunie este C =  13 * log2 13 + 14 * log2 14 = 101,398 care este la jumătatea complexității expresiei inițiale, ceea ce arată că eliminarea subexpresiilor comune este benefică duratei de execuție a unui program, știut fiind faptul că reducerea numărului de cicluri mașină este foarte  importantă.
Eliminarea subexpreiilor comune reprezintă o modalitate specială de a arăta că programatorul performează cu adevărat, chiar dacă viteza de calcul este acum amețitoare și n-ar mai conta o reducere cu 3-% să zicem a numărului de cicluri malșină. Numai că de aici se adună ceva, de dincolo mai se aducă și altceva și tot așa se construiește non-performanța unei aplicații dată de viteza redusă per global de a obține un rezultat complet.

(03 decembrie 2017)

Eliminarea invarianților

Eliminarea invarianților se impune din cauză că apar în mod nejustificat în secvențe repetitive construcții care  de la o iterație la alta nu aduc nimic nou. Este vorba de instrucțiuni care se execută repetitiv, deși execuția lor o singură dată este suficientă.

În secvența:

sum=0;

sump=0;

sumc=0;

for(i=0; i <n ;  i++) {

                             sum+=x[i];

                             sump+= x[i] * x[i];

                             sump=0;

                             sumc+= x[i] * x[i] * x[i];

                             sumc=0;

                            }

După eliminarea invarianților secventa devine:

sum=0;

for(i=0; i <n ;  i++) {

                             sum+=x[i];

                             sump+= x[i] * x[i];

                             sumc+= x[i] * x[i] * x[i];

                             

                            }

Construcția:

for(i=0; i <n ;  i++) {

                             a=0:;

                             b=0;

                             c=0;

                             

                            }

devine:

a=0;

b=0;

c=0;

sau

a=b=c=0;

În programe sunt multe locuri unde apar invarianți. Programatorii trebuie să fie atenți că atunci când li se analizează programele de către alții este foarte greu să justifice de ce inițializează aiurea o variabilă simplă. Lucrurile sunt și mai rușinoase dacă acea variabilă intră într-o expresie care se execută repetat, anulând în acest fel sensul secvenței unde se implementează structura repetitivă.

Secvența:

for(i=0; i <n ;  i++) {

                             sum+=x[i];

                             sum0;                             

                            }

ori era scrisă pur și simplu:

sum=0; ori s-ar fi scris corect:

 sum0;  

for(i=0; i <n ;  i++) {

                             sum+=x[i];                                                       

                            }

Apar riscuri de a greși mai ales când programatorul nu definește variabile grupat, nu face inițializări grupar și nu scrie secvențe de prelucrare cât mai omogene. Eliminarea invarianților presupune introducerea de variabile simple care se inițializează fără rost în cadrul structurilor repetitive, lucru greu de argumentat de către programatorul care crede că are și el un oarece statut de meseriaș.

(03 decembrie 2017)

Eliminarea codului mort

Eliminarea codului mort este o operație de care programatorul ar trebui să fie preocupat pentru că unele compilatoare o execută rapid și el se va mira că ceva lipsește în execuția lui.
Dacă va scrie secvența:

if(5>7) { a=13;
                b=20;
                 c=-1;
             }
             else {
               a=-1;
                b=140;
                c=12;
                }
evident că secvența:
             { a=13;
                b=20;
                 c=-1;
             }
nu se va executa niciodată, deci este codul mort din program.
În secvența:
   int a = 10;
   int b = 15;
   int c=31;
   e = a * b + (c / 2 -1);
   if (0) {
     printf("%d\n", a);
     printf("%d\n", b);
     printf("%d\n", c);
     printf(" a= %d\n", a);
     printf(" b= %d\n", b);
     printf(" c= %d\n", c);
     printf(" e= %d\n", e);
   }
expresia ce se evaluează la instrucțiunea if(0) duce pe ramura fals, deci acele imprimări nu vor fi executate niciodată, adică never, cum zicem noi chinezii. Dacă ar fi fost if(-1) sau if(1110003) s-ar fi tipărit, dar așa este viața când în loc de o expresie din greșeală s-a scris acolo acel nevinovat zero.
Tot ce nu se execută niciodată se numește cod mort. Se introduc din greșeală secvențe de acest fel și ele încarcă nejustificat programul, deci trebuie eliminate sau trebuie făcute corecții căci este posibil ca programatorul să fi greșit o expresie relațională și să fi ieșit altceva decât a vrut el să scrie în realitate. Eliminarea codului mort este cel mai ușor de realizat. Codul mort nu influențează execuția unui program, ci o alterează.

(023 decembrie 2017)

în lucru acum

Optimizarea programelor

Optimizarea programelor a fost o temă care m-a obsedat din studenție. Mi-am zis, când făceam Cercetări operaționale, că dacă se optimizează rații de calorii pentru vaci, dacă se face programare numere întregi pentru sortimente de strunguri și autoturisme, de ce nu s-ar face și optimizarea programelor. Atunci nu era ca acum să dai pe internet pe Google un search cu software și optimization ca să apară nenumărate articole. Atunci am găsit în Communicațion of the ACM  articolul referit prin:
Donald E. KNUTH - Structured Programming with go to Statements, ACM Journal Computing Surveys 6, no. 4, 1974, pg. 268–301.
Și de atunci a început aventura mea cu optimizarea programelor.
Am studiat.
Am scris porgrame cu optimizări în ele.
Am scris articole.
Am coordonat lucrări de diplomă.
Am coordonat lucrări la sesiuni științifice.
Am scris și o carte.
Am coordonat și o teză de doctorat.
Cu alte cuvinte, era să fiu dat afară de la grădiniță pentru cât am insistat pe acest subiect, pe care îl consider excepțional și care în viitor va face diferența cîci în cloud computing nu se va lucra decât numai cu lucrări performante, care fac totul perfect și se demonstrază că altceva mai bun nu există.
Ca să arăt că nu bat câmpii exemplific cu:

• Ion IVAN, Catalin BOJA - Practica optimizarii aplicatiilor informatice ,Editura ASE, Bucuresti, 2007, 479 pg, ISBN 978-973-594-932-7
• Ion IVAN, Adrian PIRVULESCU - Atribuirea de ponderi pentru criteriile de optimizare a aplicatiilor informatice, Revista Romana de Statistica, vol. 54, nr. 2, 2005, pg. 21 - 31
• Ion IVAN, Sergiu COMAN, Alexandru BALOG - Tehnici de evaluare a efectelor optimizarii de programe (1), Revista de Statistica, vol.32, nr. 1, 1983 pg. 27 - 33
• Ion IVAN, Sergiu COMAN, Alexandru BALOG - Tehnici de evaluare a efectelor optimizarii de programe (2), Revista de Statistica, vol. 32, nr. 4, 1983, pg. 46 - 50
• Ion IVAN, Eugen DUMITRASCU, Daniel MILODIN, Dragos PALAGHITA - Optimum Criteria for Developing Defined Structures , Informatica Economica, vol. 12, nr. 2, 2008, pg. 43 - 54, ISSN 1453-1305
• Ion IVAN, Catalin BOJA -Optimizarea bicriteriala a software, Informatica Economica, vol. 10, nr. 1, 2006, pg. 17 - 24, ISSN 1453-1305
• Ion IVAN, Catalin BOJA -Optimizarea empirica a software, INFORMATICA ECONOMICA, vol. 9, nr. 2, 2005, pg. 43 - 50
• Ion IVAN, Cristian CODREANU - Optimizarea programelor Assembler, Informatica Economică, vol. 2, nr. 2, 1998, pg. 26 - 37
• Ion Ivan, Gheorghe Nosca, Otilia PÎrlog - The optimization of the software quality cost using neural networks, The 4th International Symposium of Economic Informatics Information Technology, Bucharest, May 6-9, 1999, INFOREC Printing House, pp. 177 Ă˘â‚Źâ€œ 180, ISBN 973-98508-5-5
• Ion IVAN, Adrian VISOIU, Mihai DOINEA - Image Processing Oriented to Security Optimization, Journal of Information Technology and Communication Security, The 2nd International Conference on Security for Information Technology and Communication, 19 - 20 November 2009, Bucharest Romania, ASE Publishing House Romania, pp. 31 - 38, ISBN 978-606-505-283-3
• http://www.ionivan.ro/teaching16600-procomp-10optimizare.php

Deci problema este deosebit de vastă, suculentă, inepuizabilă și sursă de soluții originale, drept care va dăinui peste veacuri, atât timp cât lumea vă căuta să-i fie din ce în ce mai bine. Optimizarea programelor este un lucru deosebit căci de acest proces epinde fundamental performanța oricărei aplicații, căci între o aplicație online rapidă și una mai lentă, diferența este acum de milioane de USD, la cât de mulți clienți fac trab=nzacții cu o aplicație de acest tip.

(23 decembrie 2017)