performanca e C# vs C++

[Neritan Hyso]

Kohët e fundit implementova në një program timin aftësinë për t’i bërë auto-update vetvetes. Përveç modifikimit të vetë programit, kjo kërkonte që edhe serveri të asistojë në këtë proces.

Siti është implementuar në ASP.NET MVC, por unë nuk jam njohës shumë i mirë i C#, kështu që herë mbas here ndeshja vështirësi, zgjidhjen e të cilave e kërkoja në google, kryesisht tek www.stackoverflow.com.

Dhe në shumë raste, përveç zgjidhjes që kërkoja, ndeshja në pohime të tipit “C# mund të ekzekutohet po aq shpejtë sa C++, madje edhe më shpejtë, sepse JIT mund ta optimizojë kodin në varësi të procesorit ‘host’”, apo “C# mund të optimizohet më shumë se C++, sepse nuk ka problem me aliasing (për shkak të pointerave) siç ka C/C++, për më tepër JIT zotëron më shumë informacion lidhur me intencionet e programit”.

Unë nuk besoj se Sun apo Microsoft krijuan përkatësisht Java dhe.NET ngaqë ishin të pakënaqur me performancën e programeve C/C++. Gjithsesi, për të krijuar një ide, vendosa të bëj një eksperiment duke shkruar një program të thjeshtë në C# dhe C++ (Java nuk kam):

Në kompjuterin tim, versioni në C# ekzekutohet rreth 4 herë më ngadalë se ai në C++.
Siç e thashë, unë nuk e njoh mirë C# dhe penalizmi mund t’i detyrohej faktit që s’e kam shkruar mirë. Kështu që sërish kërkova në Google për të parë se si mund ta optimizoja dhe ndër të tjera mësova se performanca mund të rritej duke e deklaruar funksionin ‘unsafe’ dhe duke përdorur pointera (në C#) me anë të keyword-it ‘fixed’.

Gjithsesi, as këto përpjekje s’patën ndonjë rezultat.
Kështu që po e shtroj si “ushtrim” këtu në forum: ndokush një njeh më mirë C# (apo VB.NET... apo Java) mund të ofrojë një version më të optimizuar.

Versioni në C++ është ky:

#define	_WIN32_WINNT	NTDDI_WINXPSP2
#define	WIN32_LEAN_AND_MEAN
#include 
#include 
#include "stopwatch.h"
#include 
#include 
#include 
#include 

#pragma optimize ("t", on)


int _tmain(int argc, _TCHAR* argv[])
{
	const int               buffsize = 10;
	__int64                 progresion = 0;
	std::vector<__int64>    buffer(buffsize);
	intein::Stopwatch       timer;

	for (int i = 0; i <= 0x1FFFFFFF; i++)
	{
		progresion += i;
		buffer[i % buffsize] += progresion;
	}
	timer.Stop();

	printf ("progresion: %I64u\r\nkoha: %d\r\n\r\n", progresion, timer.ElapsedMilliseconds());
	for (int i = 0; i < buffsize; i++)
		printf ("%s%016I64x ", i % 4 ? "" : "\r\n", buffer[i]);

	printf ("\r\n\r\n");
	_getch();

	return	0;
}


#pragma optimize ("", on)

Ndërsa ai në C# është ky:

using System;

namespace csharp1
{
	class Program
	{
		static unsafe void Main(string[] args)
		{
			const int                    buffsize = 10;
			Int64                        progresion = 0;
			Int64[]                      buffer = new Int64[buffsize];
			System.Diagnostics.Stopwatch timer  = new System.Diagnostics.Stopwatch();

			//fixed (Int64* pBuffer = buffer)
			{
				timer.Restart();
				for (int i = 0; i <= 0x1FFFFFFF; i++)
				{
					progresion += i;
					buffer[i % buffsize] += progresion;
					//*(pBuffer + i % buffsize) += progresion;
				}
				timer.Stop();
			}

			System.Console.Write("progresion: {0}\nkoha: {1}\n\n", 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");
			System.Console.ReadKey();
		}
	}
}

Linku i bashkangjitur i përmban të dy projektet si dhe nga një version të kompiluar të të dy programeve.

[hot_prinz]

Pershendetje Neritan,


si duket ky ushtrim ne Java eshte me i shpejte se C++, nese anashkalojme formatimin e printf . Cuditem pse ne C# eshte aq i ngadalshem.


Kodi ne Java:

package program;

public class Main {

    public static void main(String[] args) {

        final int buffsize = 10;
        long progresion = 0;
        long[] buffer = new long[buffsize];
        StopWatch t = new StopWatch();

        t.start();
        for (int i = 0; i <= 0x1FFFFFFF; i++) {
            progresion += i;
            buffer[i % buffsize] += progresion;
        }
        t.stop();

        System.out.println("progresion: " + progresion);
        System.out.println("koha: " + t.getElapsedTime() + "\n");

        for (int i = 0; i < buffsize; i++) {
            System.out.printf(Long.toHexString(buffer[i]) + " ");
        }
        System.out.println("\n\n");

    }

}

Pasi qe nuk lejohen skedare te tipit ".jar", skedari i bashkangjitur "Program.doc" emertohet ne "Program.jar" dhe nese gjindet ne "C:\" mund te ekzekutohet ne CMD me "java -jar "C:\Program.jar", nevojitet JDK (Java Development Kit) ose JRL (Java Runtime Environment).

[Uke Topalli]

Dallimet mes .Net (c#, vb, etj) dhe java programeve ne njeren ane dhe programeve te "pamvaruna" (for the lack of a better term) ne anen tjeter jane fundamentale. ). Perderisa programet e mvaruna kerkojne sherbime nga nje strukture shtese (qofte .Net, qofte jvm) e tek pastaj me ndermjetesimin e kesaj strukture komunikojne me sistemin operativ, programet e pamvaruna komunikojn me SO ne menyre direkte. Pra nuk eshte fjala vetem ne ngecje me rastin e startimit te programit (JIT compilation) por edhe ne interaksionin me SO (garbage collection etj.). Rrjedhimisht C++ eshte me i shpejte, c edhe me i shpejte e keshtu me rradhe. Po neqoftese perfomancat jane me te dobeta atehere pse perdoren keto teknologji.

Perparesite e managed code jane ne kufizimin e demit qe mund ta beje nje program me gabim, lehtesia per krijimin e software-it per probleme komplekse etj.

[hot_prinz]

mu duk interesante me e testu kete detyre edhe ne VB.Net.
Pershkak se Int64 dhe Long sollen gabime "buffer(i Mod buffsize) += progresion" perdora tipin Decimal.
Vlerat jane decimale dhe ndryshojne ne floating, sepse funksioni i VB hex$() nuk mund te ktheje nje Decimal me me shume se 19 shifra ne Hexadecimal.

Java eshte ~ 43 here me e shpejte se VB.NET!

Per aplikacione te avansuara VB.NET eshte humbje kohe.
Si duket .NET ne pergjithesi nuk eshte e optimuar ndaj JRE.

Module Module1

    Sub Main()

        Const buffsize As Integer = 10
        Dim progresion As Decimal = 0
        Dim buffer(buffsize) As Decimal
        Dim timer As New System.Diagnostics.Stopwatch()
        Dim i As Long = 0

        timer.Start()

        For i = 0 To 536870911 '536870911(Long) = 0x1FFFFFFF(Hex)

            progresion += i
            buffer(i Mod buffsize) += progresion

        Next

        timer.Stop()

        System.Console.WriteLine("progresion: " & progresion.ToString())
        System.Console.WriteLine("koha: " & timer.ElapsedMilliseconds.ToString() _
                & vbNewLine & vbNewLine)

        For i = 0 To buffsize - 1
            System.Console.Write(buffer(i) & " ")
        Next

        System.Console.Write(vbNewLine & vbNewLine)
        System.Console.ReadKey()

    End Sub

End Module

[Neritan Hyso]

Përshëndetje hot_prinz

Me shumë gjasa VB.NET ka një performancë të krahasueshme me C#, por veprimet aritmetike me tipin Decimal simulohen ne software (për procesorin nuk ekziston një tip i tillë). Madje edhe MSDN e thotë:
• Performance. The Decimal data type is the slowest of all the numeric types. You should weigh the importance of precision against performance before choosing a data type.


Munda ta ekzekutoj programin Java në një kompjuter (netbook) që kishte JRE dhe vetëm ~5% më shpejtë se versioni C# ekzekutohet.



Në fakt unë prisja që versionet C# & C++ të ekzekutoheshin pak a shumë njëlloj - në fund të fundit loop-i s’përmban gjë tjetër veçse 2 mbledhje, 2 vlerëdhënie dhe (vetëm aksidentalisht) një modulo (%) – të gjitha veprime elementare që kryhen në hardware.

Kështu që fillimisht dyshova se diferenca e madhe mund të vinte ngaqë .NET mund të verifikonte nëse ‘i % buffsize’ ndodhej brenda kufijve të ‘buffer’ për ç’do vlerë të ‘i’. Por fakti që alternativa me pointer (në rastin e C#) s’dha ndonjë rezultat, si dhe fakti që versioni Java në kompjuterin ku e testova unë ekzekutohet pak a shumë si versioni C#, ndërsa në kompjuterin tënd pak a shumë si versioni C++ (tingëllon e çuditshme që JRE në një kompjuter të bëjë ‘bound-checking’ dhe në një tjetër jo), më bën të dyshoj se s’ka të bëjë me verifikimin nëse indeksi i ‘buffer’ është brenda kufijve.

Unë nuk doja të testoja skenarët kur programet që ekzekutohen në një VM performojnë më keq se ato ‘native’ (autokton). Në fakt doja t’i shmangja. Për këtë arsye versionin C# u përpoqa ta shkruaj duke përdorur pointer ‘fixed (Int64* pBuffer = buffer)’, për të eliminuar ‘bounds-checking’ që supozova se mund të kryente .NET-i.

Mbasi të shmangja pikat e dobëta të VM, synoja të bëja disa eksperimente duke shkruar fragmente të ndryshme kodi brenda loop-it për të parë se sa qëndronin pohimet se JIT mund të optimizonte në funksion të procesorit ‘host’, si dhe çfarë avantazhi mund të kishte fakti se JIT zotëronte metadata, përkundrejt optimizuesve ‘offline’ të C++ që kanë gjithë natën në dispozicion për të optimizuar. Jo se këto programe të vegjël kërkojnë shumë kohë për t’u optimizuar, por gjithsesi kisha ndërmend të fusja më shumë “mish” brenda loop-it.



Duke “gugluar” gjeta (ndër të tjera) disa gjëra humoristike.

http://www.youtube.com/watch?v=xF0-LGoXtaw
http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html
http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html
http://steve-yegge.blogspot.com/2008/10/programmers-view-of-universe-part-1.html

E fundit nuk është humoristike, gjithsesi është shkruar mjeshtërisht. Ja vlen ta lexoni.

[hot_prinz]

Pershendetje Neritan,


per VB, eshte e vertete se Decimal nuk mund te krahasohet, por me Int64 ose Long nuk funksiononte, prandaj e testova me Decimal.

Duket shume interesante, une nuk i testova ne kompjutera tjere, perpos VB.Net ne pune dhe e shof se ketu ne shtepi ecen me shpejte, ja njehere specifikacioni i kompjuterit tim me Speccy dhe vlerat e ekzekutimeve me radhe.

Mund te jete qe JRE eshte optimuar posaqerisht per tipat e ri te kompjutereve (une kam Intel i5) kurse ne ata me te vjeter kodi i C++ eshte me i shpejte!

[Neritan Hyso]

Kompjuterat ku i testova unë kishin procesor 64-bit, por Windows 32-bit. Gjithashtu, të dy programet: C# & C++ ishin kompiluar për 32-bit. Dyshoj se kjo është arsyeja kryesore pse versioni në C# ngelet aq mbrapa versionit në Java. Do ishte kurioze ti kompiloje edhe ato për 64-bit.

[Uke Topalli]

Unë nuk doja të testoja skenarët kur programet që ekzekutohen në një VM performojnë më keq se ato ‘native’ (autokton). Në fakt doja t’i shmangja. Për këtë arsye versionin C# u përpoqa ta shkruaj duke përdorur pointer ‘fixed (Int64* pBuffer = buffer)’, për të eliminuar ‘bounds-checking’ që supozova se mund të kryente .NET-i.

NET dhe jvm overhead verehet qysh nga alokimi i memories. Ne "unmanaged" code programi ne menyre direkte kerkon nga SO alokimin e memories, ndersa ne managed code kjo kalon neper disa shtresa, njera prej tyre sic e permenda me heret eshte GC (garbage collector) i cili e mban listen e vet te referencave ne menyre qe te dije se kur mundet te liroj nje bllok te memories dhe tja kthej ne disponim te SO.

Nuk ka lidhje se cfar fute ne loop. Vet deklarimi dhe incializimi i variablave eshte me natyre te ndryshme mes managed dhe unmanaged code

[Neritan Hyso]

Për këtë arsye të gjithë objektet krijohen përpara ‘timer. Restart()’ dhe eliminohen mbas ‘timer.Stop()’ – që koha e tyre të mos matet.
Madje, për ta bërë versionin C++ sa më të ngjashëm me atë C#, përdora
std: : vector<__int64> buffer(buffsize);

që krijohet në 'heap', si në rastin e C#. Fillimisht e kisha
__int64 buffer[buffsize];

Gjithashtu, as ‘just-in-time-compilaton’ s’do duhej të ndikonte, sepse kompilimi ndodh me “granularity” (imtësi?) e një funksioni, dhe asnjë funksion nuk thirret në intervalin e kohës që matet.

[Uke Topalli]

Une shqip po mundohem me ju tregue se ku eshte dallimi mes managed dhe unmanaged code, e ju apet po vazhdoni me JIT pallavra. ...

JIT penaltia haset vetem ne lansimin e pare te programit dhe nuk ka lidhje me ekxekutimin e tij. Edhe nje her po ju tregoj:
Dallimi mes managed code dhe unmanaged eshte se ne managed code cdo sherbim kalon neper nje shtrese te NET (ose JVM) dhe percillet tek SO. Ne rastin e NET kjo shtrese quhet CLR, dhe tere kohen e mbikqyre perdorimin e resurseve te kompjuterit (memorien etj.). Tek unmanaged code, CLR anashkalohet dhe programi eshte pergjegjes per alokimin/dealokimin e resurseve!

Mjaft tjerrem lesh per kete ceshtje te thjeshte!