performanca e C# vs C++

[hot_prinz]

tani pasi qe i kompilova gjitha per x64, shkuan gjerat ne vendin e tyre.
Edhe vete fillova te dyshoj pse C# eshte me i ngadalshem se Java e pse Java me e shpejte se C++, problemi ishte se disa programe ishin te kompiluara ne 32 e ca ne 64bit.
Personalisht per RAD me shume me pelqen C# se Java, edhe ate vetem per intellisense dhe debugger te VS.
Per Java ende nuk kam hasur ne nje debugger ala VS per C#.

[hot_prinz]

Duke i ndryshuar instruksionet ne loop nga:

progresion += i;
buffer[i % buffsize] += progresion;

ne:

*(pBuffer + i % buffsize) += progresion += i;

C# behet me i shpejte per 120 ms, C++ dhe Java nuk ndryshojne dukshem. Ne pergjithesi nuk dallojne dukshem nga njera tjetra, per ~200 ms ne me shume 500 mil instruksione.

Ne vazhdim vetem per statistika dhe kodet e PHP dhe Javascript, pasi qe Browser ose PHP nxjerrin pyetje rreth kohezgjatjes se scriptit, ndryshova zgjatjen e instruksioneve ne 50 mil (1/10) = 8sek *10 = 80sek per 500 mil instruksione.

PHP:

";
    echo "koha: ".$diferenca."

";
    
    for ($i = 0; $i < $buffsize; $i++)
        echo $buffer[$i]."
";

?>

JavaScript:

PHP dhe JavaScript jane pothuaj te ngjajshme kurse se bashku ~50 here me te ngadalshme se C++,..

[Neritan Hyso]

Po, pak a shume keto rezultate do duhej te ishin. Por jane vetem ne x64. Ne x86 versionet VM ngelen ~4 here me te ngadalte. Nderkohe qe do duhej t'i pershtateshin me mire procesorit 'host' se sa programet 'native', qe kompilohen nje here e mire.

[Neritan Hyso]

Sot edhe skriptet janë “just-in-time-compiled”.
JavaScript e PHP mund të ekzekutoheshin me një shpejtësi të përafërt me Java apo .NET.
Një nga problemet e tyre është se s’kanë tipe.
Duke mos pasur ‘tipe’, në ç’do rast përdorin tipin që është me fleksibël, që në rastin e numrave i bie të jetë ‘double’. Por veprimet me numra me presje dhjetore (për më tepër varianti me precizion më të lartë) janë shumë më të ngadaltë se veprimet me numra të plotë.

Observimi tjetër nga shembulli është se sot procesorët ekzekutojnë pak a shumë 1 instruksion për ç’do “rrahje të zemrës” së procesorit. Dhe jo një instruksion asembleri – por një instruksion të një gjuhe të zhvilluar (që përfaqëson disa instruksione makine).

Konkretisht loop-i përmban:

1. i <= 0x1FFFFFFF
2. for
3. progresion += i
4. i % buffsize
5. buffer[]
6. += progresion
7. i++

7 instruksione * ~500 mil / 1.25s ~== 2.67 GHz => pak a shumë shpejtësia e procesorit.

~200 ms ne me shume 500 mil instruksione mund të duken si “asgjë”. Por ~200ms në ~1s janë ~20% (në rastin e këtij shembulli).
Por prapë 20% s’është asgjë sepse procesorët ç’do vit bëhen më të shpejtë. Apo jo?
Gabim. Procesorët ka vite që nuk po bëhen më të shpejtë.

Shpejtësia më e madhe në natyrë është shpejtësia e dritës. Dhe është mahnitëse të konstatosh se procesorët e sotëm (për kompjutera personal) arrijnë të mbledhin këta dy numra: 2942947 + 129489 (“random typing”) aq shpejtë, sa drita mezi arrin të bëjë 10 cm rrugë ndërkohë.
Dhe drita lëviz aq shpejtë, sa i bie rreth e qark Tokës 7 herë e gjysmë brenda një sekonde.

Deri më sot merrej si e mirëqenë se prodhuesit e hardware-it e kishin për detyrë të prodhonin kompjutera më të shpejtë, 2 herë më të shpejtë, ç’do 2 vjet.

Në debatet (e zjarrta) midis gjuhëve/feve të ndryshme të programimit, përkrahësit e gjuhëve ‘më produktive, por me performancë më të ulët’ shpesh herë përdorin argumentin:

kostoja e kompjuterëve është shumë më e vogël se kostoja e programeve, dhe ata (kompjuterat) sa vijnë e bëhen më të shpejtë, kështu që është më ekonomike:
- software me kosto të ulët + hardware më i shpejtë (dhe disa qindra $ më i shtrenjtë) se sa
- software me performancë më të lartë (potencialisht qindra mijëra $ më i shtrenjtë) + kompjutera më të ngadaltë (dhe lirë).

Në fakt ky argument ka sens vetëm kur programi-i instalohet në një numër relativisht të vogël kompjuterash.

Kur numri i kompjuterëve rritet, kostoja e hadware-it bëhet më e lartë se ajo e software-it, sepse software-t shumëfishohen pa kosto.

Dhe këtej e tutje, hadrware-t as nuk kanë për t’u bërë më të shpejtë (së paku jo ashtu siç ishim mësuar).

The Free Lunch Is Over.

Microsoft's top developers prefer old-school coding methods

[hot_prinz]

Pershendetje Neritan,



berthama e procesorit nuk po shpejton proporcionalisht si me heret sepse edhe teknologjia e prodhitmit te procesoreve ka kufinje, momentalisht prodhohen procesore me 45nm. Nese do te arrihet teknologji me e sakte le te themi 20nm do te dyfishohet shuma e transistoreve, aktualisht psh. i5 posedon me shume se 750 milione transistore.

Prodhuesit e procesoreve prandaj kaluan ne procesore me me shume berthama apo multicore. Per te shfrytezuar mire procesoret multicore nevojitet dhe programimi paralel apo hyperthreading.

Ja nje shembull ne C# i progresionit ne programim paralel josinkron, ku kater berthamat bejne llogaritjen ne te njejten kohe, procesori llogarit 4x me shume/shpejte dhe nese llogarit instruksionet ~11 miliarde instruksione ne ~1500 ms:




Natyrisht, nuk dua te komprimitoj C++ eshte gjuhe e fuqishme multiparadigmale.

Por le ta marrim nje shembull, ne Java kompilon nje program dhe ai version ekzekutohet ne Windows, Linux, Mac, Unix, etj. Ne C++ duhet me kompilu nje varg versionesh, per te gjithe OS-at, edhe ate ne 32bit, 64bit, 128bit, etj etj.

Tani, sa luan rol shpejtesia e ekzekutimit per 200ms dallon nga projeki ne projekt dhe eshte relative.

Projektet e medha - xxl ku shpejtesia eshte primare optimohen ne asembler e jo ne c++.

[josif]

Neritan pershendetje,

Ne rastin ne fjale nuk mund te krahasohet performanca e C++ me C#.

Si fillim kodi C++ perpilohet ne gjuhe assembly dhe eshte i egzekutueshem direkt ne arkitekturen ku ajo perpilohet.

Kurse C# perdor nje shtrese te ndermjetme, fillimisht kodi perpilohet ne nje gjuhe te quajtur MSIL (Microsoft Intermediate Language) e cila ne princip ngjason me bytecode e Java-s. Ne momentin kur nje program i punuar ne C# egzekutohet atehere kodi MSIL egzekutohet nga platforma e ndermjetme .Net, e cila eshte nje program i ngjashem me JVM (Java Virtual Machine).

E dyta C# eshte nje gjuhe me e kontrrolluar ne aspektin e type safety, ka nje mekanizem te Garbage Collector (GC) qe automatikisht fshin objektet e allokuara qe sjane me ne perdorim. Ne rastin e C++ ti duhet te calokosh hapesirat e marra nga memorja heap. Vete GC eshte nje algoritem qe ka kosto ne kohe, por nuk ka probleme te aksesimit te memorjeve pasi calokohen etj. Pra ke trade-off midis sigurise dhe shpejtesise. Plus kesaj ke shume vecori tipike te C# qe mund ti lexosh ngado.

Ky eshte diskutim i gjere, por ne praktiken e Software Engineering ne shumicen e rasteve aplikacionet ose qendrojne Idle (pa bere gje), ose presin per veprime IO (lexim te dhenash nga file, database, etj ...). Veprimet IO varen nga shpejtesia e leximit ne disk dhe interrupted qe priten deri sa data te jete lexuar kerkojne te njejten kohe me te gjitha gjuhet e perdorimit. Nga ana tjeter ne biznes kerkohen me shume aplikacione te qendrueshme, qe ndertohen shpejt e ne kosto, etj ... Prandaj njerezit jane te synuar te mesojne gjuhe ku programimi eshte me i lehte e komod si C# apo Java.

Keshtu qe si perfundim, nese te duhet nje program i rende kalkulativ dhe koha per kete task eshte kriter kryesor, (psh drivera, simulime shkencore, programe real-time ), atehere perdor C++ ose C. Ne te gjithe rastet e tjera do te te keshilloje te perdorje ate qe je me i zoti te perdoresh e te lejon te punosh shpejt.

Me respekte,

[Uke Topalli]

Tungjatjeta Josif,

gadi plotesisht pajtohem me postimin tend. Madje me heret (ne po kete teme) jam munduar edhe vet ti ceki mu keto dallime fundamentale por si duket kam perdorun ndonje gjuhe te Afrikes, sepse vazhdimisht permendej JIT perpilimi e une, si duket nuk mundesha te kjartesoj se eshte CLR (common language runtime) e cila si ndermjetesues e fute nje penalti ne aspektin e perfomances.

Vetem nje shtesa kisha ne postimin tend. Net dhe java programet jane shum te pershtatshme per long running tasks psh per sherbime webi (webservice) qofte soap qofte json. Keto platforma e mundesojne edhe kompozimin e sherbimeve gje qe e mundeson nderrimin e perpunimit ne mase bukur te madhe me shum pak mund. Pra si "middleware" ose "application stack" jane tejet te dobishme ne programe komerciale ku llogaritjet nuk jane edhe aq intenzive.

[Neritan Hyso]

Përshëndetje

Unë desha të krahasoja performancën e C# kundrejt C++ nxitur nga shumë mesazhe (kryesisht në stackoverflow.com) që jo vetëm “dëshmonin” superioritetin e C# në performancë, por madje edhe i argumentonin të dhënat e tyre eksperimentale me faktin se “është normale, C# optimizohet në funksion të procesorit target (host)”. Apo “C# ka një model të mirë-definuar të veprimeve me numrat me presje dhjetore, ndërsa C/C++ vuajnë faktin që duhet të jenë ‘backwards-compatible’”, ...
http://stackoverflow.com/questions/686483/c-vs-c-big-performance-difference
http://stackoverflow.com/questions/2496803/c-and-c-speed-compared
...etj.

Në mesazhin e link-ut të parë p.sh. testi bëhej përkundrejt llogaritjes në një ‘loop’ të sqrt().
Fillimisht versioni C/C++ ishte nja 30 herë me i ngadaltë se versioni C#, por mbas përpjekjeve të personit në fjalë për ta “optimizuar” versionin C/C++ që të mos bënte figurë aq të keqe ndaj C#, përfundimisht versioni C/C++ “arriti” të ishte rreth 150% më i ngadaltë se ai C#, çka sipas autorit të testit “është e pranueshme”.

Unë e bëra vetë një test të tillë, dhe fillimisht programi C/C++ ishte rreth 2 herë më i ngadaltë se ai në C#. Kjo nuk më habiti, sepse e di që opsioni default për ‘Floating Point Model’ është ‘Precise’. Kështu që e ndryshova në ‘Fast’. Kësaj rradhe të dy programet ekzekutoheshin njëlloj.
Por diku kisha lexuar që në VS2010 (apo VS2008, nuk e mbaj mend) MS e kishte zvogëluar pak performancën edhe në rastin e opsionit ‘Fast’ në funksion të ‘consistency’.
Kështu që e kompilova me kompilatorin e Intelit, dhe përfundimisht versioni C/C++ u bë rreth 150% më i shpejtë se ai C#.

Tashmë, pohime si ato mësipër nuk më habisin më. Ajo që kam kuptuar është se ata që bëjnë këto pohime nuk kanë haber as të kompilojnë një program, dhe ndoshta një nga arsyet pse preferojnë C# është se nuk ofron shumë opsione, e për pasojë më pak gjasa të ngatërrohen me këmbët e tyre (në rastin e shembullit, C# nuk ofron ndonjë opsion për FPU, por e ka të paravendosur ekuivalentin e C++ ‘Fast’).

------------------------------------

Për sa i përket portabilitetit...

Ka dy lloj portabilitetesh: në raport me hardware të ndryshëm; dhe në raport me sisteme operimi të ndryshëm.

Por më parë le të biem dakord se portabiliteti nuk ka të bëjë me faktin nëse programin duhet ta kompilosh për platforma të ndryshme. Kompilimi është një proces “mekanik”(d.m.th. automatik) që kryhet nga kompilatori, pa ndonjë kosto të perceptueshme.
Portabiliteti ka të bëjë me faktin nëse programin të duhet ta (ri)shkruash për ç’do platformë. Kjo ka kosto.

Në raport me hardware-in, C/C++ janë aq portable sa më sbëhet. Me .NET-in e Java s’kanë të krahasuar.
C-ja shpesh herë përshkruhet si “portable assembler”, dhe C++ është po aq portable sa C.

Arsyeja pse C/C++ janë gjuhë “të vogla”, pa suport për threads, UI, network, etj. është pikërisht që të jenë portable. Në C/C++ mund të programosh praktikisht ç’do lloj hardware të programueshëm. Motorë luftanijesh, avionë, misile, robotët për në Mars, ... etj. janë programuar në C++.

Natyrisht, hardware kaq të ndryshëm kanë karakteristika unike, dhe ato pjesë të programit që trajtojnë këto aspekte s’mund të jenë portable. Por ky është një terren ku Java e .NET nuk janë fare prezent.

Gjithashtu është e mundur që programet C/C++ të jenë portable edhe në raport me sisteme të ndryshme operimi, duke mos programuar përkundrejt API të këtyre OS-ve, por përkundrejt ndonjë librarie që ofron një interface uniforme, siç është p.sh. Qt.

Por problemi kur programon përkundrejt emëruesit të përbashkët të sistemeve të ndryshme operimi është se s’mund të shfrytëzosh avantazhet unike që ofron secili OS. Dhe kjo vlen edhe për Java e .NET.

Për sa i përket Java, kjo është e vetmja alternativë (të programosh kundrejt JVM).
Në rastin e C/C++ mund të zgjedhësh të programosh kundrejt një librarie si Qt, por nuk je i detyruar. Dhe në fakt shumica nuk zgjedh këtë alternativë.
Ndërsa C# është praktikisht e lidhur mbas Windows-it. E di, ekziston edhe Mono, por të gjithë (përdoruesit e .NET-it) deklarojnë se është një implementim inferior ndaj atij të MS.

Edhe pse një nga avantazhet e pretenduar të VM është portabiliteti, e vërteta është se Java e .NET janë më të përhapur në programimin e web-serverave dhe aplikacione biznesi.
Që të dy skenarë ku portabiliteti s’ka pikë rëndësie!
Në të dy rastet numri i kompjuterave në të cilët programi ka për t’u ekzekutuar është i vogël dhe nën kontrollin e një subjekti të vetëm.

Pjesa dërrmuese e programeve që targetojnë konsumatorë individualë, që përdorin një larmi hardware/OS, dhe ku portabiliteti mund të kishte domethënie, faktikisht shkruhen në C/C++.

Për sa i përket ‘type-safety’, Ok, C-ja nuk ka shumë pretendime, por C++ është po aq ‘type-safe’ sa .NET apo Java.

GC është vetëm një nga mënyrat se si memoria mund të administrohet, dhe nuk është domosdoshmërish mënyra më e mirë, së paku jo në të gjitha rastet.
Kjo është dhe arsyeja pse në C# ekziston “using(){}”, që imiton mënyrën se si administrohen resourcet në C++ - RAII (Resource Acquisition Is Initialization).
Gjithashtu, ekzistojnë disa implementime të GC për C++, dhe nuk është e vështirë ta implementosh vetë.
Në ketë libër shpjegohet një variant i thjeshtë.
Dhe si për ç’do gjë tjetër, përdorimi i GC në C++ është një opsion, por nuk është i detyruar.


Edhe një herë mbi performancën... (strumbullari i kësaj teme)

C++ ofron të njëjtën performancë që ofron C. Madje, në disa raste është e vështirë që me C të arrish performancën e C++, por për faktin e thjeshtë se C++ derivon prej C, performanca e C është automatikisht e trashëguar në C++.

Edhe në situatat që kërkojnë performancë të lartë, programet nuk shkruhen në asembler, me përjashtim të rasteve kur dikush e shkruan në asm thjesht dhe vetëm për të demonstruar se mund ta shkruajë të gjithin në asm (ose kur programi është ekstremisht i vogël, siç është p.sh. bootstrap).
Arsyeja është e thjeshtë: programet e shkruar në C++ mund të link-ohen me module të shkruar në C, fortran apo asembler.

Rritja e numrit të procesorëve, bërthamave (core) brenda një procesori, rritja e sasisë së memories (cache) dhe shpejtësisë së saj, kanë për të dhënë njëfarë kontributi në rritjen e aftësive procesuese, por pak a shumë kemi arritur në limitet e kësaj teknologjie.

Çdo program ka pjesë që mund të ekzekutohen në paralel, dhe pjesë që duhet të ekzekutohen në seri.
Pjesët që mund të ekzekutohen në paralel mund të ekzekutohen edhe në seri, por pjesët që duhet të ekzekutohen në seri nuk mund të ekzekutohen në paralel.
Kështu që paralelizmi nuk ka për të na çuar shumë larg.

Arsyeja pse gjithë energjitë janë fokusuar tek multicore/paralelizëm është se procesorët kanë arritur pak a shumë limitin e shpejtësisë.
Shpejtësia e ka një limit – shpejtësinë e dritës.

Numri i transistorëve mund të vazhdojë të dyfishohet ç’do 18 muaj edhe për ca kohë, por kjo nuk e rrit frekuencën, dhe gjithë çfarë mund të merrej nga “branch prediction”, “speculative execution” apo “pipelining” pak a shumë është shfrytëzuar.

Shembulli i paralelizmit që ke sjellë më sipër hot_prinz, demonstron të kundërtën e asaj që ke dashur të thuash: “procesori llogarit 4x me shume/shpejte”.

Vetëm njëri nga procesorët ka bërë punë.
Tre të tjerët kanë harxhuar korrent kot. Ekzistenca e tyre nuk bëri që progresioni të llogaritej më shpejtë.
Dakord, progresioni u llogarit 4 herë, po kujt i hyn në punë kjo?
Nëse dikujt i duhen 4 kopje të rezultateve, fare mirë mund të kopjojë rezultatet që llogariti procesori i parë.




----------------------------------------
Ky ishte mesazhi im i fundit në këtë forum.

Përpara nja dhjetë ditësh, me urdhër të sali berishës u pushkatuan 3 qytetarë Shqiptarë, të paarmatosur, pa precedentë penalë, pa gjyq, në mes të bulevardit Dëshmorët e Kombit, në një hapësirë publike ku gjithkush ka të drejtë të rrijë.
Vrasësve, saliu u dha një rrogë shtesë dhe, ndonëse me ligj nuk u takon, imunitet ndaj hetimit.


Nëse i vret këlyshin një qëni apo maceje, mund të angullijnë për disa orë, e në ndonjë rast mund të refuzojnë edhe ushqimin për një, a mbase dy ditë. Por vetëm kaq. Janë kafshë dhe jetojnë vetëm në të tashmen. Sapo e tashmja bëhet e shkuar, asnjë gjurmë s’ngelet më tek ta.

Por një gjë të tillë s’mund ta bësh me njerëzit. Njerëzit nuk falin.
Njerëzit, dhe jo ata që quhen njerëz thjesht dhe vetëm sepse qëndrojnë mbi dy këmbë (e që fare mirë mund të quheshin pula).

Njerëzit jetojnë edhe në të shkuarën, përmes kujtimeve, edhe në të ardhmen, përmes imagjinatës.
Dhe sa më inteligjent të jenë, aq më thellë në të shkuarën, dhe aq më larg në të ardhmen shkon mendja e tyre.


Unë s’mund të jem më pjesë e këtij forumi që ose censurohet (siç ankohej dikush), ose në pjesën dërrmuese popullohet nga llumi i shoqërisë Shqiptare. Cilido rast qoftë.

Në vijim kam për të postuar në ndonjë nga forumet e tjera Shqiptare, me këtë emër, e ndoshta mund të blogoj edhe në sitin tim.

[hot_prinz]

Përshëndetje

Shembulli i paralelizmit që ke sjellë më sipër hot_prinz, demonstron të kundërtën e asaj që ke dashur të thuash: “procesori llogarit 4x me shume/shpejte”.

Vetëm njëri nga procesorët ka bërë punë.
Tre të tjerët kanë harxhuar korrent kot. Ekzistenca e tyre nuk bëri që progresioni të llogaritej më shpejtë.
Dakord, progresioni u llogarit 4 herë, po kujt i hyn në punë kjo?
Nëse dikujt i duhen 4 kopje të rezultateve, fare mirë mund të kopjojë rezultatet që llogariti procesori i parë.

.

Pershendetje Neritan,

pse ore deshiron te largohesh?
Na trego faqet ku shkruan te lexojme nganjehere, se do te mallengjehemi, per keto shkrime dhe per pasionin prej programuesi.

Sa i perket rastit qe kam sjelle, pse ore thua qe nuk llogarit per te njejten kohe 4x me shume/me shpejte?
Ja nje screenshot gjate ekzekutimit ku te kater berthamat mund te verehen qe perdoren deri ne maksimum, dhe perderisa llogaritin rezultatin e njejte normal qe llogaritin 4x me shume ne te njejten kohe.



Pse llogarita regresionin 4x, ishte sepse regresioni i ndare ne kater pjese ne secilin task fillon nga numri 1, dhe shuma e progresionit nuk mbetet e njejte sepse varet nga progresioni ne nje seri te loop-it, progresioni i loopit mund te llogaritet njehere per pjesen e pare e tasqet tjera te startojne me progresion dhe ndryshore te loop-it te llogaritur, por prapeseprape ja nje rast kur i gjithe loop-i u dhurohet 4 berthamava me [int x = 0x1FFFFFFF / 4;] dhe llogarisin per 400 ms me progresion fillestar:



Dhe kodi:

using System;
using System.Threading.Tasks;

namespace csharp1
{
    class Program
    {
        static void Main(string[] args)
        {
            int x = 0x1FFFFFFF;

            System.Diagnostics.Stopwatch timer = new System.Diagnostics.Stopwatch();

            timer.Restart();

            Task task1 = Task.Factory.StartNew(() => llogarit(x, 1));
            Task task2 = Task.Factory.StartNew(() => llogarit(x, 2));
            Task task3 = Task.Factory.StartNew(() => llogarit(x, 3));
            Task task4 = Task.Factory.StartNew(() => llogarit(x, 4));

            task1.Wait();task2.Wait();task3.Wait();task4.Wait();

            timer.Stop();

            System.Console.Write("\n\nkoha gjithsejt: {0}", timer.ElapsedMilliseconds);
            System.Console.ReadKey();
        }

        public static unsafe void llogarit(int x, int j)
        {
            const int buffsize = 10;
            Int64 progresion = 0;
            Int64[] buffer = new Int64[buffsize];
            System.Diagnostics.Stopwatch timer = new System.Diagnostics.Stopwatch();

            timer.Restart();

            fixed (Int64* pBuffer = buffer)
            {
                for (int i = 0; i <= x; i++)
                {
                    *(pBuffer + i % buffsize) += progresion += i;
                }
            }

            timer.Stop();

            System.Console.Write("task: {0}\nprogresion: {1}\nkoha: {2}\n\n", j, progresion, timer.ElapsedMilliseconds);
            for (int i = 0; i < buffsize; i++)
                System.Console.Write("{0}{1:x16} ", i % 4 != 0 ? "" : "\n", buffer[i]);
            System.Console.Write("\n\n");
        }
    }
}

Sa i perket Assembler. C gjate kompilimit ofron mundesine e eksportimit te codit ne assembler per optimim te metutjeshem, vete compileret e gjuheve te larta optimohen ne assembler. Assembler si gjuhe e ulte eshte me prane hardware-ve se c/c++. Per llogaritje te larta, BLAS [Basic Linear Algebra Subprograms] eshte optimuar ne Assembler.

[josif]

Pershendetje Neritan,

Kryesisht bie dakort me postimin tend ne vija te pergjithshme. C/C++ eshte me i shpejte se C# ne rast te pergjithshem e ketu e kemi permendur te pakten tre vete kete fakt.

Por me beri pershtypje nje mendimi yt ne lidhje me portabilitetin e C++ e krahasuar me .Net, ku ti pretendon se C++ eshte me portable ne aspektin e hardware.

Ky argument mua me duket paksa jo praktik ose te them me duket nje kendveshtrim tendencioz. Per mendimin tim nese nje platforme supporton JVM atehere suportohet automatikisht nje pjese e madhe e hardware-ve si rrjedhoje e utiliteteve qe ofron sistemi operativ.

Ja pershembull rasti i hardwareve bazike te nje sistemi operativ, te themi nje shembull: hard diskeve. A ka rendesi se cfare lloji eshte hard disku nese ti shkruan nje file dhe sistemi operativ i ka driverat e duhur per ta lexuar diskun? Nuk ka kurfare rendesie pasi tashme eshte kryesisht pergjegjesi e sistemeve operative te sigroje layerin. I njejti diskurs ne rastin e procesoreve. Krijimi i nje procesi varet nga utilitetet e sistemit te operimit dhe nuk eshte vecori e gjuhes se programimit. E njejta teme me karten grafike, te zerit, etj ...

Ne rastin tjeter kur nje device, te themi atipike, ka nje driver, ne shumicen e rasteve librari asembli, atehere komunikimi me pajisjen mund te aksesohet nepermjet librarive te driverit qofte nga C# (DllImport) ose Java (Java Native Library / jna ).

Per te shtuar ne raste ekstreme ku te themi ke nje device te vecante qe nuk ka driver por ka nje dokumentacion mbi kodimin e bytestream-eve dhe protocolin e komunikimit, atehere edhe kjo fare mire mund te behet ne C# apo Java nepermjet nje byte stream me porten ku eshte lidhur pajisja.

Pra nese .Net ose JVM suportohet nga nje platforme e caktuar, atehere automatikisht C# ose Java ka perdorim dhe portabilitet te njejte me C++, biles akoma me te lehte pasi nuk nevojitet rikompilimi. Ne rastin e .Net kemi probleme me shume sisteme operimi *nix, por JVM eshte portable thuajse ne nje range te plote te platformave. Sigurisht ka edhe platforma me pak te perdorura ku JVM mungon, dhe ne ato raste C++ eshte e vetmja zgjidhje.

Ti ke bere nje gabim kur ke thene rikompilimi i kodit C++ ne nje platforme tjeter eshte proces i kollajte. Ne rastet kur ti perdor nje librari me pagese, (per shembull nje third-party dll library), atehere duhet qe edhe ato te rikompilohen ne platformen e re. Po sikur te mos e kesh source code-in e librarive third-party? Ne projekte te medha ky eshte nje problem shume serioz pasi jo gjithmone te mundesohet kodi i librarive me pagese. Ose me tej ta zeme qe munde ta gjesh souce code-in e librarive third-party. Po sikur libraria third-party, te perdori nje library tjeter third-party nga ana e saj?

Prandaj portabiliteti ne C++ eshte ndofta teorikisht me i potencial sesa Java apo C# pasi nuk ke nevoje qe .Net/JVM te jene gati per ate platforme ku punon, por ne praktike ato te thjeshtojne shume punen nese jane te suportuara.

Si perfundim do te thoja qe nuk ka gjuhe me te mire se tjetra, rendesi ka trade-off. Ne te duhet shpejtesi dhe performance ate e realizon me C++, por kerkon me shume efforts/budget ne development. Nese te duhet me shume features gati dhe me pak kosto perdor Java apo .Net.

Nese nje program ne C++ punon 2 sekonda me shpejt po kushton 20.000 dollare me shume pasi duhet te besh ndonjehere qofte edhe librari string vete, pasi nuk i ke te gatshme, nga ana tjeter ne C#/Java mund te perdoresh shume librari te gatshme qe te shkurtojne koston e software. Plus asaj programuesat e C++ kerkojne me shume rroge se ata te Java, etj, pra duhen pare gjerat edhe nga aspekti ekonomik. Keshtu qe une parashikoj qe ana ekonomike do te detyroje perdorim te platformave .Net/JVM ne te ardhmen, qe te ofrojne shume funksione dhe funksionalitete te gatshme dhe te nxjerrin ne treg me kosto te ulet.

Kurse ne rast se development e shikon si art e jo biznes, nese merresh me research, aplikacione qe duan performance brilante, etj, ... me mire perdor C++.

Shpresoj te jem sqaruar.

Përshëndetje

Unë desha të krahasoja performancën e C# kundrejt C++ nxitur nga shumë mesazhe (kryesisht në stackoverflow.com) që jo vetëm “dëshmonin” superioritetin e C# në performancë, por madje edhe i argumentonin të dhënat e tyre eksperimentale me faktin se “është normale, C# optimizohet në funksion të procesorit target (host)”. Apo “C# ka një model të mirë-definuar të veprimeve me numrat me presje dhjetore, ndërsa C/C++ vuajnë faktin që duhet të jenë ‘backwards-compatible’”, ...
http://stackoverflow.com/questions/686483/c-vs-c-big-performance-difference
http://stackoverflow.com/questions/2496803/c-and-c-speed-compared
...etj.

Në mesazhin e link-ut të parë p.sh. testi bëhej përkundrejt llogaritjes në një ‘loop’ të sqrt().
Fillimisht versioni C/C++ ishte nja 30 herë me i ngadaltë se versioni C#, por mbas përpjekjeve të personit në fjalë për ta “optimizuar” versionin C/C++ që të mos bënte figurë aq të keqe ndaj C#, përfundimisht versioni C/C++ “arriti” të ishte rreth 150% më i ngadaltë se ai C#, çka sipas autorit të testit “është e pranueshme”.

Unë e bëra vetë një test të tillë, dhe fillimisht programi C/C++ ishte rreth 2 herë më i ngadaltë se ai në C#. Kjo nuk më habiti, sepse e di që opsioni default për ‘Floating Point Model’ është ‘Precise’. Kështu që e ndryshova në ‘Fast’. Kësaj rradhe të dy programet ekzekutoheshin njëlloj.
Por diku kisha lexuar që në VS2010 (apo VS2008, nuk e mbaj mend) MS e kishte zvogëluar pak performancën edhe në rastin e opsionit ‘Fast’ në funksion të ‘consistency’.
Kështu që e kompilova me kompilatorin e Intelit, dhe përfundimisht versioni C/C++ u bë rreth 150% më i shpejtë se ai C#.

Tashmë, pohime si ato mësipër nuk më habisin më. Ajo që kam kuptuar është se ata që bëjnë këto pohime nuk kanë haber as të kompilojnë një program, dhe ndoshta një nga arsyet pse preferojnë C# është se nuk ofron shumë opsione, e për pasojë më pak gjasa të ngatërrohen me këmbët e tyre (në rastin e shembullit, C# nuk ofron ndonjë opsion për FPU, por e ka të paravendosur ekuivalentin e C++ ‘Fast’).

------------------------------------

Për sa i përket portabilitetit...

Ka dy lloj portabilitetesh: në raport me hardware të ndryshëm; dhe në raport me sisteme operimi të ndryshëm.

Por më parë le të biem dakord se portabiliteti nuk ka të bëjë me faktin nëse programin duhet ta kompilosh për platforma të ndryshme. Kompilimi është një proces “mekanik”(d.m.th. automatik) që kryhet nga kompilatori, pa ndonjë kosto të perceptueshme.
Portabiliteti ka të bëjë me faktin nëse programin të duhet ta (ri)shkruash për ç’do platformë. Kjo ka kosto.

Në raport me hardware-in, C/C++ janë aq portable sa më sbëhet. Me .NET-in e Java s’kanë të krahasuar.
C-ja shpesh herë përshkruhet si “portable assembler”, dhe C++ është po aq portable sa C.

Arsyeja pse C/C++ janë gjuhë “të vogla”, pa suport për threads, UI, network, etj. është pikërisht që të jenë portable. Në C/C++ mund të programosh praktikisht ç’do lloj hardware të programueshëm. Motorë luftanijesh, avionë, misile, robotët për në Mars, ... etj. janë programuar në C++.

Natyrisht, hardware kaq të ndryshëm kanë karakteristika unike, dhe ato pjesë të programit që trajtojnë këto aspekte s’mund të jenë portable. Por ky është një terren ku Java e .NET nuk janë fare prezent.

Gjithashtu është e mundur që programet C/C++ të jenë portable edhe në raport me sisteme të ndryshme operimi, duke mos programuar përkundrejt API të këtyre OS-ve, por përkundrejt ndonjë librarie që ofron një interface uniforme, siç është p.sh. Qt.

Por problemi kur programon përkundrejt emëruesit të përbashkët të sistemeve të ndryshme operimi është se s’mund të shfrytëzosh avantazhet unike që ofron secili OS. Dhe kjo vlen edhe për Java e .NET.

Për sa i përket Java, kjo është e vetmja alternativë (të programosh kundrejt JVM).
Në rastin e C/C++ mund të zgjedhësh të programosh kundrejt një librarie si Qt, por nuk je i detyruar. Dhe në fakt shumica nuk zgjedh këtë alternativë.
Ndërsa C# është praktikisht e lidhur mbas Windows-it. E di, ekziston edhe Mono, por të gjithë (përdoruesit e .NET-it) deklarojnë se është një implementim inferior ndaj atij të MS.

Edhe pse një nga avantazhet e pretenduar të VM është portabiliteti, e vërteta është se Java e .NET janë më të përhapur në programimin e web-serverave dhe aplikacione biznesi.
Që të dy skenarë ku portabiliteti s’ka pikë rëndësie!
Në të dy rastet numri i kompjuterave në të cilët programi ka për t’u ekzekutuar është i vogël dhe nën kontrollin e një subjekti të vetëm.

Pjesa dërrmuese e programeve që targetojnë konsumatorë individualë, që përdorin një larmi hardware/OS, dhe ku portabiliteti mund të kishte domethënie, faktikisht shkruhen në C/C++.

Për sa i përket ‘type-safety’, Ok, C-ja nuk ka shumë pretendime, por C++ është po aq ‘type-safe’ sa .NET apo Java.

GC është vetëm një nga mënyrat se si memoria mund të administrohet, dhe nuk është domosdoshmërish mënyra më e mirë, së paku jo në të gjitha rastet.
Kjo është dhe arsyeja pse në C# ekziston “using(){}”, që imiton mënyrën se si administrohen resourcet në C++ - RAII (Resource Acquisition Is Initialization).
Gjithashtu, ekzistojnë disa implementime të GC për C++, dhe nuk është e vështirë ta implementosh vetë.
Në ketë libër shpjegohet një variant i thjeshtë.
Dhe si për ç’do gjë tjetër, përdorimi i GC në C++ është një opsion, por nuk është i detyruar.


Edhe një herë mbi performancën... (strumbullari i kësaj teme)

C++ ofron të njëjtën performancë që ofron C. Madje, në disa raste është e vështirë që me C të arrish performancën e C++, por për faktin e thjeshtë se C++ derivon prej C, performanca e C është automatikisht e trashëguar në C++.

Edhe në situatat që kërkojnë performancë të lartë, programet nuk shkruhen në asembler, me përjashtim të rasteve kur dikush e shkruan në asm thjesht dhe vetëm për të demonstruar se mund ta shkruajë të gjithin në asm (ose kur programi është ekstremisht i vogël, siç është p.sh. bootstrap).
Arsyeja është e thjeshtë: programet e shkruar në C++ mund të link-ohen me module të shkruar në C, fortran apo asembler.

Rritja e numrit të procesorëve, bërthamave (core) brenda një procesori, rritja e sasisë së memories (cache) dhe shpejtësisë së saj, kanë për të dhënë njëfarë kontributi në rritjen e aftësive procesuese, por pak a shumë kemi arritur në limitet e kësaj teknologjie.

Çdo program ka pjesë që mund të ekzekutohen në paralel, dhe pjesë që duhet të ekzekutohen në seri.
Pjesët që mund të ekzekutohen në paralel mund të ekzekutohen edhe në seri, por pjesët që duhet të ekzekutohen në seri nuk mund të ekzekutohen në paralel.
Kështu që paralelizmi nuk ka për të na çuar shumë larg.

Arsyeja pse gjithë energjitë janë fokusuar tek multicore/paralelizëm është se procesorët kanë arritur pak a shumë limitin e shpejtësisë.
Shpejtësia e ka një limit – shpejtësinë e dritës.

Numri i transistorëve mund të vazhdojë të dyfishohet ç’do 18 muaj edhe për ca kohë, por kjo nuk e rrit frekuencën, dhe gjithë çfarë mund të merrej nga “branch prediction”, “speculative execution” apo “pipelining” pak a shumë është shfrytëzuar.

Shembulli i paralelizmit që ke sjellë më sipër hot_prinz, demonstron të kundërtën e asaj që ke dashur të thuash: “procesori llogarit 4x me shume/shpejte”.

Vetëm njëri nga procesorët ka bërë punë.
Tre të tjerët kanë harxhuar korrent kot. Ekzistenca e tyre nuk bëri që progresioni të llogaritej më shpejtë.
Dakord, progresioni u llogarit 4 herë, po kujt i hyn në punë kjo?
Nëse dikujt i duhen 4 kopje të rezultateve, fare mirë mund të kopjojë rezultatet që llogariti procesori i parë.




----------------------------------------
Ky ishte mesazhi im i fundit në këtë forum.

Përpara nja dhjetë ditësh, me urdhër të sali berishës u pushkatuan 3 qytetarë Shqiptarë, të paarmatosur, pa precedentë penalë, pa gjyq, në mes të bulevardit Dëshmorët e Kombit, në një hapësirë publike ku gjithkush ka të drejtë të rrijë.
Vrasësve, saliu u dha një rrogë shtesë dhe, ndonëse me ligj nuk u takon, imunitet ndaj hetimit.


Nëse i vret këlyshin një qëni apo maceje, mund të angullijnë për disa orë, e në ndonjë rast mund të refuzojnë edhe ushqimin për një, a mbase dy ditë. Por vetëm kaq. Janë kafshë dhe jetojnë vetëm në të tashmen. Sapo e tashmja bëhet e shkuar, asnjë gjurmë s’ngelet më tek ta.

Por një gjë të tillë s’mund ta bësh me njerëzit. Njerëzit nuk falin.
Njerëzit, dhe jo ata që quhen njerëz thjesht dhe vetëm sepse qëndrojnë mbi dy këmbë (e që fare mirë mund të quheshin pula).

Njerëzit jetojnë edhe në të shkuarën, përmes kujtimeve, edhe në të ardhmen, përmes imagjinatës.
Dhe sa më inteligjent të jenë, aq më thellë në të shkuarën, dhe aq më larg në të ardhmen shkon mendja e tyre.


Unë s’mund të jem më pjesë e këtij forumi që ose censurohet (siç ankohej dikush), ose në pjesën dërrmuese popullohet nga llumi i shoqërisë Shqiptare. Cilido rast qoftë.

Në vijim kam për të postuar në ndonjë nga forumet e tjera Shqiptare, me këtë emër, e ndoshta mund të blogoj edhe në sitin tim.