Limbaje de programare

[Arthur6]

Ati incercat c#?

mie unul imi pare destul de flexibil si puteti lucra foarte usor in mediul visual express 2008,iar mai nou 2010!

[Dendros]

Eu unul am vrut să-l încerc, dar C# nu (prea) merge în Linux. Însă, da, e un limbaj modern şi flexibil. Am citit că Microsoft a programat în C# un fel de prototip de sistem de operare, numit Singularity, care ar fi un OS extrem de stabil şi sigur.
Deci se pot face multe în C#.

[AlexandruLazar]

Merge sub Linux dacă pui Mono.

Singularity e un SO experimental; ideea nu e că e stabil şi sigur (oricum nu face altceva decât să booteze şi să ruleze nişte programe exemplu), ci că a arătat că se poate scrie un SO întreg folosind numai cod managed.

[Dendros]

Da, ştiu de Mono, l-am încercat, dar nu a prea funcţionat. Ştiu că Singularity e un SO experimental, dar tocmai de asta l-am pomenit, ca să arăt că se pot face multe în C#.
Nu sunt expert în programare, dar cod managed cred că înseamnă că mediul de rulare are grijă de execuţia codului, iar programatorul nu mai trebuie să se preocupe de detalii de nivel scăzut, pe scurt nu mai are nevoie de nicio bucăţică de cod în limbaj de asamblare. Corect?

[AlexandruLazar]

Cam aşa ceva. Nu e nimica nou -- e doar termenul celor de la Microsoft pentru cod-care-rulează-într-o-maşină-virtuală. Codul e compilat într-un format bytecode pe care îl execută o maşină virtuală -- aceeaşi chestie pe care o face şi JVM cu codul rezultat din compilarea programelor Java sau Scala, de exemplu.

[Dendros]

Atunci înseamnă că s-ar putea realiza un SO complet în Java. S-a încercat asta?

[AlexandruLazar]

Dap, JX e unul din ele. Şi JavaOS cred că era la fel.

[laurz]

Cunosc PHP, nu sunt expert dar suficient cat sa ma descurc, mi se pare faorte ok limbajul

[florin_try]

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.

[AlexandruLazar]

Doar câteva lucruri am de adăugat -- în mare sunt de acord .

operatii cu 1D sau 2D vectori. Operatiile cu 1D si 2D sunt "vectorizate".

Nu ştiu sigur dacă vorbim de acelaşi lucru, dar cred că asta fac foarte multe compilatoare din ziua de azi, în condiţiile în care instrucţiunile SSE sunt de găsit aproape pe orice acum.

-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.

Managementul memoriei nu e făcut de compilator ci de sistemul de operare . Dacă sistemul pe care lucrezi are o implementare proastă pentru malloc/calloc, prost o să meargă indiferent cu ce.

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.

Prima tentaţie ar fi să zic că acum 20 de ani probabil era aşa, dar de fapt cred că nici acum 20 de ani nu mai era aşa . Nu ştiu sigur cum e în Fortran pentru că n-am prea lucrat cu el, dar în C zonele de memorie pentru membrii structurilor sunt fixe (nu neapărat contiguue, dar fixe) aşa că de fapt codul generat de compilator le accesează direct, fără a mai trece prin deferenţierea unei instanţe a structurii sau obiectului respectiv. Sunt pachete de calcul de înaltă performanţă (de exemplu solver-ul pentru sisteme liniare SuperLU) care foloseşte ca structură de date pentru numere complexe un struct cu doi membri, r şi i, fără a pierde din performanţă cu asta. Începe să se simtă numai dacă obiectul este foarte mare şi nu mai e stocat în zone contiguue de memorie sau dacă accesul se face prin pointeri care nu sunt const (atunci compilatorul nu poate ghici că nu se schimbă niciodată adresa şi trebuie să-i deferenţieze de fiecare dată).

Altele sunt cazurile în care un sistem OOP începe să fie mai lent -- dacă recurgi la clase virtuale, la moşteniri sau dacă vrei să faci un management automat al memoriei. Desigur că fără a recurge la toate astea e dubitabil că mai ai de-a face cu OOP în prea mare măsură...

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.

Nu-i vorba numai că se investeşte în ele, cât că baza de cod existentă este foarte mare, foarte eficientă şi testată foarte bine. Costurile de a o rescrie de la zero în C nu se justifică, mai ales că oricum rutinele Fortran se pot apela din C.

[florin_try]

Prima tentaţie ar fi să zic că acum 20 de ani probabil era aşa, dar de fapt cred că nici acum 20 de ani nu mai era aşa. Nu ştiu sigur cum e în Fortran pentru că n-am prea lucrat cu el, dar în C zonele de memorie pentru membrii structurilor sunt fixe (nu neapărat contiguue, dar fixe) aşa că de fapt codul generat de compilator le accesează direct, fără a mai trece prin deferenţierea unei instanţe a structurii sau obiectului respectiv. Sunt pachete de calcul de înaltă performanţă (de exemplu solver-ul pentru sisteme liniare SuperLU) care foloseşte ca structură de date pentru numere complexe un struct cu doi membri, r şi i, fără a pierde din performanţă cu asta.

Prin 2004-2005 intel fortran compiler-ul (versiunea 7 pe vremea aia) lucra cu pina la 50% mai lent daca foloseam date incapsulate gen
a[ii].x,a[ii].y, a[ii].z in loc de a_xyz(ii,1:3). De indata ce am re-mapped datele incapsulate in array si lucrat cu array am recistigat din viteza, insa tinind cont de ce spui tu o fi posibil viteza sa o fi pierdut in alta parte fara sa imi dau seama iar explicatia sa fi fost alta.

De fapt am mai experimentat si alte ciudatenii de performanta in fortran, pe care la momentul respetiv nu prea am stiut cum de apar:
1. La cross indexari de genul a[pointer[ii]] pierde mult din viteza si azi.
2. NINT(x) intrinseca din fortran e amuzant de lenta, mai lenta ca un radical. Nu stiu daca compilatoarele mai recente au fixat asta.
3. Trimitind in subrutine / functii array la modul x[9:100] in loc de array indexati de la primul index 1 (x[:]), incetineste programul incredibil.