Sunt sigur ca un compilator de fortran produce cod foarte optimizat in cazul algoritmilor numerici. E in productie de ceva vreme, au avut destul timp sa tot perfectioneze compilatoarele.
Depinde de ce tip de program rulezi. Nu e suficient sa folosesti fortran ca sa ai cod optimizat.
De exemplu, un banal algoritm iterativ de visitare a unui graph printr-un first-order-depth walk, nu va avea nici un beneficiu de viteza in fortran. Voi da mai jos detalii:
Iata cind e FORTRANUL rapid:
-operatii cu 1D sau 2D vectori. Operatiile cu 1D si 2D sunt "vectorizate".
-Structura de date e statica si nu se schimba in timpul executiei.
-memorie static alocata. Adica aloci de la inceputul executiei un chuck estimat de memorie (de regula ceva mai mare decit necesar) si cu ala lucrezi. Daca trebuie mai multa opresti programul (sau se va opri singur prin crash) si ceri de la inceput mai multa.
-metode iterative si nu recursive.
Iata cind FORTRANUL nu mai e chiar asa rapid:
-operatii pe arbori sau graphuri arbitrare. Daca structura graphurilor (arborilor) se schimba pe timpul executiei nu mai ai nici un beneficiu, de fapt C-ul ar putea fi mai optimizat aici ca e de multa vreme cu astfel de structuri.
-crosindexari de genul arr[iv[ii]] sau arr[iv[pointer[ii]]]. chiar daca folosesti vectori 1D, cu acest gen de crosindexari e mai lent.
-array 3-dimensionali cu cel mai dinafara index accesat in cel mai din interior loop: Ex-emplu:
do ii=1,N
do j=1,N
do k=1,N
sum += v[ii][j][k] + ...
e lent.
- Folosirea de recursie (posibila in FORTRAN 90/95 dar imposibila in varianta anterioara FORTRAN 77)
- Folosirea de pointeri.
Orice paradigma a OOP (chiar si encapsularea) incetineste fortranul, daca e folosita in ciclurile critice.
Exemplu: Un obiect de genul (il dau in notatie JSON-like):
obiect: { prop1: { paradigm1:whatever,
paradigm2:whatever_else},
prop2: { paradigm1:whatever,
paradigm2:whatever_else}
}
accesat ca:
o[ii].prop1.paradigm1= f(o[ii].prop1.paradigm2).operatie_whatever_complexa.g(o[ii].prop2.paradigm1).operatie.gg(o[ii].prop2.paradigm2) /*am cross indexari*/
o[ii].prop1.paradigm2=...
o[ii].prop2.paradigm1=...
o[ii].prop2.paradigm2=...
..........................
intr-un loop critic, ar putea fi mai lent decit daca ai serializa tot obiectul in array 1D (re-map acordingly) si efectua operatiile pe vectorul 1D, iar la final remap in forma encapsulata. Are sens sa faci asta in looporile cele mai critice, desigur e un nonsens sa te chinui in looporile experioare ce consuma de sute de ori mai putin timp.
Cel mai rapid program de simulari complexe din domeniul in care am eu cunostinta de cauza este in C++, dar e si din cauza ca anumite loopuri critice sunt rescrise in cod-masina pentru anumite procesoare.
Stiu insa de un grup ce a rescris o aplicatie de citeva zeci de mii de linii de cod, din fortran in C, iar dupa 2-3 ani de trial-and-error, versiunea C era la fel de rapida si uneori chiar mai rapida decit cea FORTRAN, desi genul de calcul/structuri (array statici) ar fi fitat perfect unde FORTRANUL exceleaza. Tot ei mi-au spus ca traducere 'ad-literam' (ciclu cu ciclu, si 'if' cu 'if') fortran-C nu va duce la cod eficient C.
Nu stiu care e motivul pentru care FORTRANUL nu e defunct sau obsolete.
Nu e vorba ca il folosesc cei in virsta ci de faptul ca librarii in fortran sunt inca produs comercial (vezi NAG) in care se investeste.
Probabil majoritatea aplicatiilor stiintifice de calcul numeric pot fi re-mapped / re-formulate in mod iterativ si cu structuri statice de date, sau array 1D sau 2D, si atunci folosesti avantajul fortranului de a fi rapid in aceste structuri.
