C# vs. VC++

@alex_ndc
Sorry man dar tu nu faci decit sa "paste" texturile PR ale Sun si MS legate de aceste creaturi incredibile....JITerele :D.

Tu, si ceilalti care ati postat pe acest topic si care ii toti dati inainte cu JITul , nu intelegi o chestiune elementara:
JITerul NU ISI PERMITE SA FACA LUCRURILE ALEA !!!!!!

Sa luam de ex. o functie de 20 LOC care trebuie executata (repet....e doar un exemplu pueril care sa dem. problema) :

cod nativ : este pur si simplu este executata. (sa spunem ca dureaza 5 secunde).
  versus
2 cazuri de JITing :

1. JITuiesti fct. direct (cod x86 fara nici o optimizare). 1 sec. dureaza JITuirea si 7 secunde dureaza executia (yeah...codul nativ era optimizat) .
Avem 5 vs. 8 secunde. You loose.

2. Hardware checks + code branching (0.5), JITuire (1) + optimizari (sa spunem Common Subexpression) (0.5). Executia dureaza 5.5 secunde.
Avem 5 sec. vs 7.5 secunde. You loose. AGAIN.

Ai inteles ideea acum ?  Nu conteaza ce (poate) face JITerul. Datoria lui este DOAR sa scuipe cod nativ cit mai rapid cu putinta.

De exemplu, in timp ce primul compilator JIT isi executa rutinele obisnuite, un al doilea compilator
poate rula in background masurand timpi de executie / bottlenecks etc ... recompiland cand este cazul.

  That's dumb. In primul rind te omoara context switchingul. Sa iti aduc aminte ca mai avem inca un thread pt graphul GCului ?
Si ca, pina la urma, you know.....mai trebuie sa ruleze si codul aplicatiei.  Apoi.....who gives a **** legat de prostia asta si chestii gen HotSpot ?
Inchizi programul.....se duce totul !!! Cind repornesti programul o iei iar de la capat ! ASTA e marele dezavantaj al JITerului. Ca sa nu mai pomenesc
nimic de marimea heapului :D :D

Teoretic, tehnica JIT ar putea fi mai buna decat AOC, deoarece cu AOC se fac optimizari specifice de platforma
    In primul rind acronimul e AOTC (Ahead Of Time Compilation). In al 2 rind din fraza respectiva rezulta EXACT inversul a ceea ce ai vrut
tu sa scoti in evidenta.

Repet...din pct de vedere teoretic un AOTC reprez. rezolvarea ideala : are partile bune ale unui compilator & JITer fara problemele aferente.

Si cam atit cu offtopicul pt. ca deja nu mai are nici o legatura cu topicul.

KLAMATH, on Feb 15 2006, 16:11, said:

Exista studii care arata ca optimizarile adaptive pot da performante similare cu compilatoarele de C++.
Nu sunt primul care remarca.
http://www.javaworld...02-jperf_p.html
http://www.bytonic.d...benchmarks.html

HotSpot-ul de la Sun nu a fost inventat de Sun ... au cumparat pur si simplu un VM Smaltalk denumit Strongtalk ce se potrivea cu Java deoarece era un mediu strongly-typed.
Cercetarile in domeniu tin de prin `90 si inca este un subiect nou, deoarece de abia recent au inceput sa se vada rezultatele. IBM de exemplu finanteaza de ceva timp cercetari in domeniu:
http://jikesrvm.sour...entations.shtml
http://jikesrvm.sour...004Tutorial.pdf

KLAMATH, on Feb 15 2006, 16:11, said:

Se pare ca Anders Hejlsberg nu este de aceeasi parere:
http://www.artima.co...tv/choices.html
Si lasa-ma sa citez:
"JIT technologies have gotten to the point where you can have multiple possible JIT strategies. You can even imagine using a fast JIT that just rips quickly, and then when we discover that we're executing a particular method all the time, using another JIT that spends a little more time and does a better job of optimizing. There's so much more you can do JIT-wise."

KLAMATH, on Feb 15 2006, 16:11, said:

Nu sunt expert in compilatoare, dar exemplul tau este cam invalid. Si iti voi explica si de ce.

KLAMATH, on Feb 15 2006, 16:11, said:

Tu te bazezi pe faptul ca acea functie este executata o singura data.
Pai noi vorbeam de optimizari adaptive.
Si in general, intr-o aplicatie bottlenecks-urile se formeaza in jurul functiilor care se executa de sute de mii de ori.
Si chiar si in exemplul tau, daca functia aia dureaza 5 secunde ... cel mai probabil apeleaza la randul sau alte functii care sunt repetate. Masina virtuala are timp berechet sa analizeze codul si sa faca profilari specifice compilarii AOTC si optimizari specifice platformei pe care ruleaza.

KLAMATH, on Feb 15 2006, 16:11, said:

Aici ai inteles un pic cam simplut lucrurile.
Si lasa-ma sa citez dintr-o lucrare de la IBM ce discuta optimizarile din Jikes RVM:
http://www.research....ind/RC23429.pdf

"The adaptive optimisation system contains four components:
- runtime measurements: This component monitors the application's runtime behaviour and produces profile data
- controller: this component determines what runtime data should be gathered, analyzez the profile data and determines which actions to perform regarding management of execution modes.
- recompilation: this component implements actions to change execution modes, including recompiling portions of the application
- knowledge repository: This component provides a store of shared information that the other components can consult"

KLAMATH, on Feb 15 2006, 16:11, said:

Oricum, insasi prezenta VM-ului presupune prezenta unor thread-uri ce monitorizeaza aplicatia.
Deoarece am lucrat la mai multe aplicatii multi-threading pot spune ... who cares ?
Prezenta unui thread in plus este infima, si daca vorbim si de procesoare multi-core lucrurile capata o alta dimensiune,

KLAMATH, on Feb 15 2006, 16:11, said:

Multa lume gives a **** pe langa SUN ... ca sa nu pomenim de Smaltalk care are de ceva timp astfel de masini virtuale ... IBM, BEA ... si in curand Microsoft.

Vom vorbi iar in ziua in care Microsoft lanseaza un astfel de VM si te vei mandri in stanga si-n dreapta ca platforma ta preferata are optimizari adaptive. Pana atunci poti spune ca "strugurii sunt acrii" :D

KLAMATH, on Feb 15 2006, 16:11, said:

Propozitia respectiva nu este completa, sorry ... vroiam sa spun ca AOTC compileaza cod specific platformei pe care este compilat.

AOTC NU REPREZINTA SOLUTIA PERFECTA DIN 2 MOTIVE:
1) Garbage collector-ul nu merge bine decat cu un VM
2) nu numai ca nu este practica, dar este aproape imposibila optimizarea pentru diferite procesoare ... chiar daca te rezumi doar la procesoarele Intel (la cate modele au ... inchipuie-ti) si de aceea, de multe ori se ajunge la compromisuri ... iar Microsoft Office tot nu este optimizat pentru procesoare mai bune de Pentium Clasic.


Da-i unui programator C++ masina virtuala si va folosi NGEN sau GCJ, in asa fel in care daca-i dai unui programator de assembler un limbaj structurat, acel programator va folosi GOTO ... si-n acelasi fel in care C++ este folosit inca de la aparitie ca un C cu clase si cu operator overloading.

Chiar conteaza cand un program ruleaza cu 10% mai incet, in contextul in care complexitatea circuitului integrat s-a dublat pana-n prezent la fiecare 18 luni ?

Discutia nu este offtopic deoarece vorbim de C# vs. C++ (si nu consider C++-ul manage-uit din .NET drept C++ - este mai degraba o gluma proasta).

Edited by alex_ndc, 17 February 2006 - 01:46.

Si ca sa mai adaug la disputa noastra ... chiar este pacat ca astfel de argumente (AOTC vs JIT) sa stea in calea adoptarii unei platforme.

Istoria ne invata mai bine.
LISP, unul dintre cele mai revolutionare limbaje create vreodata, nu a fost adoptat datorita vitezei scazute comparat cu Assembler, Fortran, COBOL, Algol, sau C++.

TOATE imbunatatirile din limbajele moderne exista sau sunt derivate din caracteristici din LISP. Si aici putem vorbi atat de Ruby, cat si de C# 3.0.

Si, desi implementarile LISP moderne sunt chiar mai rapide decat unele compilatoare C++, LISP nu este in continuare folosit, deoarece este pur si simplu diferit.

Paguba facuta de popularitatea limbajelor imperative, printre care amintim Pascal (predat la scoala si astazi) sau C/C++ este uriasa, si pentru ce ?
Acelasi motiv etern ... performanta proasta invocata pentru probleme care n-au nevoie de performanta ;)

Iar pretul este comportamentul de turma, spre castigul oamenilor mai destepti si mai curajosi:
http://www.paulgraham.com/icad.html

Edited by alex_ndc, 17 February 2006 - 01:26.

:w00t: Pe cine sa mai cred... A scris careva vreun compilator sau interpretor?

trident, on Feb 17 2006, 01:34, said:

Pe cine sa crezi ?
Daca tot vorbim de platforme Microsoft , poti crede in .NET deoarece in mod clar Microsoft vrea inlocuirea COM-ului cu .NET. Iar .NET are in componenta o masina virtuala.

Quote

Quote

Apropo, mi s-a parut mie ceva in neregula cand s-a amintit aici de NGEN.
Sunt impotriva compilatoarelor clasice, asa cum se poate vedea din ultimele mele postari, dar totusi, sa vorbesti de NGEN ca si cand ar fi un compilator in sensul `traditional` ... :)

"The Native Image Generator creates a native image from a managed assembly and installs it into the native image cache on the local computer."

Cu alte cuvinte, se JIT-uieste aplicatia (fara optimizari adaptive, deoarece CLR-ul nu are înca asa ceva :) ), si se stocheaza imaginea in global assembly cache.
O problema ar fi ca imaginea creata nu poate fi re-distribuita, deoarece ar viola securitatea CLR-ului ... ca pana una alta, o imagine NGEN, tot de CLR depinde.
Nu ca ar fi o problema, deoarece poti oricand genera imaginea la instalarea pe calculatorul clientului.

Doar ca NGEN nu prea este AOTC-ul de care tot vorbim, deoarece NGEN nu aduce nici o optimizare de viteza/resurse in plus fata de JIT-uirea normala ... doar timpi de startup mai buni ... timpi care sunt irelevanti (in afara de primele 5 minute), mai ales pentru o aplicatie care ruleaza timp de cateva ore, cum ar fi World of Warcraft (ca tot vorbeam de jocuri).

In rest, aceleasi probleme cu `heap-ul mare`, aceleasi probleme cu colectarea de gunoaie si cu firele de executie `in plus` ... cam aceeasi mancare.
Ca sa nu mai vorbim ca o pasarica mi-a soptit ca in .NET 1.x este foarte usor sa rupi dependente, invalidand imaginile NGEN si fortand o compilare `proaspata`.

Este un pic pueril sa te astepti la mai multe de la NGEN, decat de la JIT-uirea normala, sigur, in afara de timpi de startup mai buni :)

(Shit, KLAMATH o sa ma faca tandari ... but I don't care :peacefingers:  :notangel:  :proud:  )

PS: cel putin daca folosesti GCJ obti (in mare parte) cod cu adevarat nativ care poate fi redistribuit (dependent totusi de un VM) ... oops, I did it again

Edited by alex_ndc, 17 February 2006 - 04:55.

trident, on Feb 17 2006, 01:34, said:

ma gandesc ca sunt cativa, dar asta este irelevant pentru discutie din motivele:
- acel compilator fie a fost unul pt faculta (lab) fie unul pentru palcerea personala si deci nu e "mare branza"
- se discuta de compilatoarele moderne: asta presupune anumite cunoastiinte pe care un individ din cazul de mai sus s-ar putea sa nu le aiba

referitor la cateva posturi de mai sus: s-a tot vorbit de LISP. s-ar putea sa ma insel, dar nu e vorba defapt de lambda calculus? :huh: (ma refer in special la fraza "TOATE imbunatatirile din limbajele moderne exista sau sunt derivate din caracteristici din LISP" dar nu numai)

ciuly, on Feb 17 2006, 13:07, said:

Pai daca te gandesti ca lambda calculus sta la baza limbajului, ai putea spune si asta.

Dar, mai concret ...

Functia ca un tip de data ... ne amintim aici de delegatii din C#, ca sa nu mai vorbim de Ruby sau Python.

Masina virtuala, atat de raspandita astazi, a fost inventata odata cu LISP.

Posibilitatea de evaluare dinamica a expresiilor, datorita careia s-a nascut si LISP ca limbaj de programare, limbaj ce poate fi considerat primul limbaj dinamic (si mai concret, functia `eval`) ... sta la baza tuturor limbajelor dinamice de astazi.

In LISP, pentru prima oara, toate variabilele au aparut ca referinte la adrese de memorie.

Closures (termen considerat de adeptii programarii functionale drept incorect, dar pe de alta parte, termenul de "expresie lambda" este prea general).

Ar mai fi Continuations, caracteristica înrudita cu closures-urile mentionate mai sus ... se pare ca au aplicabilitate foarte buna in aplicatiile web, si este foarte probabil ca pe viitor toate platformele sa suporte caracteristica asta (Java suporta deja, dar momentan se lucreaza in domeniu cu Ruby si Smaltalk).

Type inference ... caracteristica ce va fi prezenta in C# 3.0, este deja prezenta in LISP ... initial nu, dar datorita optimizatilor, pe parcurs LISP a dobandit posibilitatea de static-typing optional ... de unde si trasatura importata din alte limbaje functionale si statice, cum ar Haskell si ML.

OOP-ul, desi nu original din LISP, si o caracteristica ce se cam bate cap in cap cu programarea functionala pe alocuri. Dupa ce Smaltalk a demonstrat ca OOP-ul este folositor, LISP a adoptat OOP printr-o extensie denumita Flavors ce includea mutiple-inheritance si combinare de metode.
Dar cel mai important, Flavors a introdus conceptul de Mixins.
Astazi, extensia CLOS este populara, si da posibilitatea modificarii claselor in real-time. Si de altfel, cea mai buna extensie de meta-programare (MOP) este cea din CLOS.

Ca tot vorbeam de Smaltalk, modelul de programare din Smaltalk, unde nu exista vreo diferenta intre read-time, compile time si runtime, a fost copiat din LISP, desi Smaltalk a mers ceva mai departe.

Sintaxa ciudata din LISP, cea cu multe paranteze, bazata pe ierarhii de liste, da posibilitatea de evaluare a expresiilor (expresii ce pot fi verificate la compilare, in comparatie cu `string`-urile ce pot fi evaluate in limbajele dinamice de astazi ... evaluare ce porneste un intrepretor nou in PHP  :puke: ), dar in acelasi timp, face posibil sistemul de macro-uri, care este cel mai puternic sistem de macro-uri din toate limbajele de programare, sistem ce permite Domain-specific programming si, de unde rezulta posibilitatea de a face design Bottom-UP al aplicatiei ... sistem de macro-uri ce a castigat LISP-ului distictia de "Limbaj de programare programabil".

Totul a inceput de la lambda calculus, intr-adevar. Desi, transpunerea intr-un limbaj de programare a fost interesanta in primul rand datorita functiei `eval`.
Motivul pentru care LISP este de actualitate si astazi ... este bazat pe un model matematic, si nu a fost gandit sa corespunda limitelor hardware ale vremii ... de unde si credinta mea ca a tine cont de detalii, doar de dragul performantei, cum ar fi termenii STACK/HEAP, este o prostie.

Mai amintesc de alte trasaturi, inventate tot odata cu LISP, care au devenit 'obisnuite', cum ar fi "garbage-collector", conditionala "if-then-else" (oarecum a dat start-ul programarii structurate, desi nu prea se face referire la LISP cand se discuta istoria programarii structurate ... si ar mai fi de spus ca LISP, deoarece este functional, nu a stiut niciodata de GOTO si de efectele sale) sau recursivitatea functiilor ... facilitate ce face posibila programarea functionala.


Sper sa nu fiu impuscat pentru OFF-TOPICUL mare de mai sus .. imi cer scuze, dar incerc de ceva vreme sa gasesc timp pentru a studia in detaliu LISP, si devin foarte pasionat cand cineva este interesat de discutii