Trenger litt hjelp til valg av programeringsspråk

siDDis · 16. mai 2008

OpenGL kan brukes til mykje rart, grunnen til at OpenGL er poplært i Java er at ytelsen er god og at utviklingstida er langt betre.

Når ein har mindre antall timer å bruke på eit prosjekt og ytelsen er ikkje ein superviktig faktor så er OpenGL med Java eit godt valg.

Er ytelse ikkje ein faktor så er OpenGL med Python eit godt valg.

Kenjuudo · 16. mai 2008

Jeg ønsker ikke å være vanskelig, men Java kan ikke engang komme i _nærheten_ av C når det gjelder ytelse

Fleire implementasjoner har vist at Java kan være raskere enn C, men det er veldig sjeldent. Du kan også kompile Java rett til maskinkode med f.eks GCJ og då reduserer ein *oppstarts* tiden betraktelig som er ein kjempefordel for GUI programmer.

Men ein utviklingshastigheit som meir enn dobles samanlikna mot C som har bare *litt* betre ytelse er etter min meining mykje meir attraktivt. Men C er enda kongen på haugen om ytelse er ein viktig faktor, som til f.eks spel.

Dessuten så blir fleire og fleire spel idag utvikla i fleire språk, LUA har blant anna blitt veldig populært i fleire kommersielle spel.

Ja, på konseptet utviklingshastighet, ruler Java stort over både C og C++... Men helst på GUI applikasjoner, hvor C og C++ er temmelig kjipe. (I disse språkene går alt an, men å utvikle GUI er stress uten sidestykke)

Nå er det imidlertid slik at alle C/C++ programmerere med respekt for seg selv, bygger seg personlige bibliotek over tid. Bibliotekene inneholder etterhvert store mengder gjenbrukbar kode som dessuten blir optimert med jevne mellomrom. En erfaren C/C++ programmerer vil således ha bygget seg de rammeverkene som skal til for å lage applikasjoner kjappt. Har man hovedvekt på spillutvikling, ser en C++ programmerer initialisering av vinduer, messageloops og hardware API, kun én gang. Til slutt kan en spillengine se slik ut:

#include "gamelib.h"

class HalfLife8Engine : GameEngine
{
protected:
   void LoadResources() override
   {
       LoadModel("helten", "c:\models\mann.3ds");
       LoadTexture("heltetexture", "c:\textures\asfalt.png");
   }
   void InitScene() override
   {
       ApplyTexture("helten", "heltetexture");
       PositionEntity("helten", 0f, 0f, 0f);
   }
   void Update() override
   {
       RotateEntity("helten", 0.1f, 0f, 0f);
   }
   void Render() override
   {
       if (BeginScene(GetBackBuffer()))
       try
       {
           DrawEntity("helten");
       }
       finally
       {
           EndScene(true); //hvor false eventuellt ville betydd avbryt
       }
   }
};

HalfLife8Engine* HL8Engine = NULL;

int main()
{
   int dwExitCode = 0;

   try
   {
       HL8Engine = new HalfLife8Engine();
       HL8Engine.Run();
   }
   finally
   {
       dwExitCode = HL8Engine.GetExitCode();
       delete HL8Engine;
   }

   return dwExitCode;
}

Skrev denne koden direkte her på forumet, så beklager hvis den inneholder feil.

-Kenjuudo

GeirGrusom · 16. mai 2008

OpenGL kan brukes til mykje rart, grunnen til at OpenGL er poplært i Java er at ytelsen er god og at utviklingstida er langt betre.

Når ein har mindre antall timer å bruke på eit prosjekt og ytelsen er ikkje ein superviktig faktor så er OpenGL med Java eit godt valg.

Er ytelse ikkje ein faktor så er OpenGL med Python eit godt valg.

Bah! Python er et latterlig språk, ser INGEN fordeler med Python, det har en rotete syntaks, inneffektive programmer, og de er ikke blitt enige om hvordan GUI skal fungere der, dermed har du egen for gtk og egen for Qt som gjør at de som bruker programmet kanskje må laste ned ekstra GUI biblioteker for hvert program.

Det tar ikke kortere tid å utvikle programmer i Python eller Java, du har ingen fordeler i Python fremfor Java eller C#, og i tillegg har Python er dårlig gjennomtenkt API for C programmer.

Dessuten kommer jeg aldri over hvor UTROLIG STYGT språket ser ut, det er like estetisk som QuickBasic.

Når det gjelder spill, så skrives motorene som regel i C++, kanskje også litt assembly, men for selve dynamikken i spillet, så brukes som regel et scriptspråk, oftest LUA. Men det finnes tonnevis med andre. Selv liker jeg Squirrel ganske godt, fordi det har C++ syntaks, og fordi det er ikke laget med tanke på å være et general purpose språk (som Python) men nettopp for å være et scriptspråk til spill. Det er veldig enkelt å implementere, og syntaksen er enkel.

siDDis · 16. mai 2008

Tviler ikkje eit sekund på at ein erfaren C/C++ kan utvikle ein heil del forskjellige applikasjoner raskare enn ein middels erfaren Javautvikler.

Er ein dritgod i C/C+, liker å programmere i C/C++ og har eit solid bibliotek så trenger ein jo ikkje Java

Men dei aller fleste er ikkje akkurat dritgode i C/C++, og ikkje minst er læringskurven eindel brattare.

Kenjuudo · 16. mai 2008

Tviler ikkje eit sekund på at ein erfaren C/C++ kan utvikle ein heil del forskjellige applikasjoner raskare enn ein middels erfaren Javautvikler.

Er ein dritgod i C/C+, liker å programmere i C/C++ og har eit solid bibliotek så trenger ein jo ikkje Java

Men dei aller fleste er ikkje akkurat dritgode i C/C++, og ikkje minst er læringskurven eindel brattare.

Du har helt rett... Men jeg vil allikevel si at C# er et bedre førstevalg enn Java, nettopp fordi Java innholder så vanvittig mye 3dje parts ting... I C# har du et standard .NET bibliotek ferdig laget for deg, og kan sette deg ned og skrive programmer fra dag 1.

steingrim · 16. mai 2008

Jeg synes det er voldsomt fokus på GUI i denne diskusjonen, det blir litt latterlig å sammenligne C# som så og si er laget for GUI-applikasjoner, med språk som ikke er det. Hvor mange lager egentlig GUI-applikasjoner til daglig? Og da mener jeg ikke GUI'er i web, men eget-vindu-med-X-i-hjørnet.

GeirGrusom · 16. mai 2008

Egentlig helt enig.

C++ er uegnet for GUI rett og slett, men er helt ypperlig til å skrive biblioteker og slikt i.

Spill er også noe C++ er veldig godt egnet til.

C++ kan noen ganger være vanskelig å debugge også, fordi stack feil kan føre til at programmet ikke kræsjer, men oppfører seg helt mongoloid, og da kan det ofte være mye jobb for å finne ut hva som er galt, f.eks. en header fil som ikke er helt oppdatert kan føre til slikt har jeg erfart.

Jeg er ikke en erfaren C++ kar egentlig, jeg har jobbet mye med C++ men lite med MFC, QT eller Gtk.

Mye fordi jeg finner det så uintuitivt, og at det kreves mye kode for å gjøre veldig lite.

Kenjuudo · 16. mai 2008

Egentlig helt enig.
C++ er uegnet for GUI rett og slett, men er helt ypperlig til å skrive biblioteker og slikt i.

Spill er også noe C++ er veldig godt egnet til.

C++ kan noen ganger være vanskelig å debugge også, fordi stack feil kan føre til at programmet ikke kræsjer, men oppfører seg helt mongoloid, og da kan det ofte være mye jobb for å finne ut hva som er galt, f.eks. en header fil som ikke er helt oppdatert kan føre til slikt har jeg erfart.

Jeg er ikke en erfaren C++ kar egentlig, jeg har jobbet mye med C++ men lite med MFC, QT eller Gtk.

Mye fordi jeg finner det så uintuitivt, og at det kreves mye kode for å gjøre veldig lite.

Og jeg er igjen enig med deg. Men når det gjelder at det kreves mye for å gjøre "lite", så gjelder det hvis alt du skal gjøre er "lite". Dersom du skal gjøre "mye", kan jeg garantere deg at all koden som skulle til for å gjøre "lite" kan nå brukes hver gang du skal adde samme funksjonalitet et annet sted i programmet. Det vil altså balansere seg. Problemet med C++ er at det i grove trekk *krever* et egendefinert bibliotek for å lage noe som ligner på noe annet enn en console applikasjon. Det tar altså veldig lang tid før du får visuell feedback på alt arbeidet ditt. Det er også dette som er hovedgrunnen til at man normalt ikke bruker C++ som begynnerspråk.

-Kenjuudo

Mr.Garibaldi · 16. mai 2008

Java blir (på lik linje med C#) imidlertid kompilert til IL kode i dag, som gjør at man nødvendigvis må miste oversikten over hvordan programmet blir optimert av JIT'ens optimizer. Dette gjør at mange av de gamle optimeringsteknikkene ikke lenger fungerer som forventet, og man må settle med å stole på JIT'en... (Java.NET lager samme type IL som C# og VB.NET, mens standard Java lager sin egen)

C og C++ lager derimot (i utgangspunktet) maskinkode direkte og du har dermed full (Ja, hvis du er guru...) oversikt over hvordan den ferdige maskinkoden skal se ut. Dermed kan man sitte og flikke på koden for å eliminere ticks både her og der. For ikke å snakke om at slike språk som oftest støtter inline assembly direkte i kildekoden.

Hvorfor har du full oversikt over C/C++ kode som er blitt kompilert til maskinkode, forutsatt at du er en guru, og ikke har full oversikt over javakode som er blitt kompilert til IL, selv om du er en guru? Kode er da kode, enten det er maskin, IL, eller java, det eneste som kreves er at du har kunnskapen til å tolke den.

Når jeg tok INF1010 (med Steingrim som gruppelærer) var det en som leverte inn en løsning på dronningoppgaven som etter sigende var en blanding av javakode og IL. Så det skulle være fullt mulig å endre på den kompilerte koden for å øke effektiviten uavhengig av hvilket språk som er brukt.

Forskjellen er vel heller sannsynligheten for å finne en javaprogrammerer som har dyp nok kunnskap til å gjøre den type optimisering kontra en cpp-programmerer...

GeirGrusom · 17. mai 2008

Å skrive/endre et program i IL er jo egentlig betydelig enklere, men fremgangsmåten er mindre dokumentert en for x86 maskinkode.

Kenjuudo · 17. mai 2008

Java blir (på lik linje med C#) imidlertid kompilert til IL kode i dag, som gjør at man nødvendigvis må miste oversikten over hvordan programmet blir optimert av JIT'ens optimizer. Dette gjør at mange av de gamle optimeringsteknikkene ikke lenger fungerer som forventet, og man må settle med å stole på JIT'en... (Java.NET lager samme type IL som C# og VB.NET, mens standard Java lager sin egen)

C og C++ lager derimot (i utgangspunktet) maskinkode direkte og du har dermed full (Ja, hvis du er guru...) oversikt over hvordan den ferdige maskinkoden skal se ut. Dermed kan man sitte og flikke på koden for å eliminere ticks både her og der. For ikke å snakke om at slike språk som oftest støtter inline assembly direkte i kildekoden.

Hvorfor har du full oversikt over C/C++ kode som er blitt kompilert til maskinkode, forutsatt at du er en guru, og ikke har full oversikt over javakode som er blitt kompilert til IL, selv om du er en guru? Kode er da kode, enten det er maskin, IL, eller java, det eneste som kreves er at du har kunnskapen til å tolke den.

Når jeg tok INF1010 (med Steingrim som gruppelærer) var det en som leverte inn en løsning på dronningoppgaven som etter sigende var en blanding av javakode og IL. Så det skulle være fullt mulig å endre på den kompilerte koden for å øke effektiviten uavhengig av hvilket språk som er brukt.

Forskjellen er vel heller sannsynligheten for å finne en javaprogrammerer som har dyp nok kunnskap til å gjøre den type optimisering kontra en cpp-programmerer...

Du har full oversikt i C og C++' genererte maskinkode fordi den koden ikke behøver å forandres mer. IL kode, derimot, må igjennom enda et layer før det blir til maskinkode. Det er dette layeret du ikke har oversikt over. Hva slags optimeringer som blir gjort her, ligger utenfor din rekkevidde fordi det er avhengig av platformen JIT'en er installert på.

GeirGrusom · 17. mai 2008

Joda, men IL koden som blir generert er ganske spesifikk for hvilken operasjon som skal skje, så det er lite rom for å optimalisere fordi JIT-en forhåpentligvis velger den beste løsningen.

Kubisk bezier funksjon i C#:

public static float CubicBezierInterpolate(float a, float b, float c, float d, float t)
{
return (1f - t) * (1f - t) * (1f - t) * a + 3 * t * (1f - t) * (1f - t) * b + 3 * t * t * (1f - t) * c + t * t * t * d;
}

Den genererte IL-en for samme koden:

.method public hidebysig static float32  CubicBezierInterpolate(float32 a,
															float32 b,
															float32 c,
															float32 d,
															float32 t) cil managed
{
 .maxstack  4
 ldc.r4	 1.
 ldarg.s	t
 sub
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldarg.0
 mul
 ldc.r4	 3.
 ldarg.s	t
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldarg.1
 mul
 add
 ldc.r4	 3.
 ldarg.s	t
 mul
 ldarg.s	t
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldarg.2
 mul
 add
 ldarg.s	t
 ldarg.s	t
 mul
 ldarg.s	t
 mul
 ldarg.3
 mul
 add
 ret
}

Og den ferdig genererte maskinkoden:

push		ebp  
mov		 ebp,esp 
push		edi  
push		esi  
push		ebx  
sub		 esp,30h 
xor		 eax,eax 
mov		 dword ptr [ebp-10h],eax 
xor		 eax,eax 
mov		 dword ptr [ebp-1Ch],eax 
cmp		 dword ptr ds:[009697F4h],0 
je		  00000021 
call		79477097 
fldz			 
fstp		dword ptr [ebp-3Ch] 
nop			  
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fmul		dword ptr [ebp+18h] 
fld		 dword ptr [ebp+8] 
fmul		dword ptr ds:[00CB1350h] 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fmul		dword ptr [ebp+14h] 
faddp	   st(1),st 
fld		 dword ptr [ebp+8] 
fmul		dword ptr ds:[00CB1358h] 
fmul		dword ptr [ebp+8] 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fmul		dword ptr [ebp+10h] 
faddp	   st(1),st 
fld		 dword ptr [ebp+8] 
fmul		st,st(0) 
fmul		dword ptr [ebp+8] 
fmul		dword ptr [ebp+0Ch] 
faddp	   st(1),st 
fstp		dword ptr [ebp-3Ch] 
nop			  
; Denne er merkelig, denne hopper til neste linje
; Skjønner ikke hva den er til
jmp		 00000090
fld		 dword ptr [ebp-3Ch] 
lea		 esp,[ebp-0Ch] 
pop		 ebx  
pop		 esi  
pop		 edi  
pop		 ebp  
ret		 14h

For meg ihvertfall er IL koden spesifikk nok til at en kan optimalisere, hvis det hadde vært nødvendig.

Fordelen med IL også er at den kan utnytte fremtidig hardware uten å måtte generere IL-en på nytt.

Endret 17. mai 2008 av GeirGrusom

Jaffe · 17. mai 2008

OpenGL kan brukes til mykje rart, grunnen til at OpenGL er poplært i Java er at ytelsen er god og at utviklingstida er langt betre.

Når ein har mindre antall timer å bruke på eit prosjekt og ytelsen er ikkje ein superviktig faktor så er OpenGL med Java eit godt valg.

Er ytelse ikkje ein faktor så er OpenGL med Python eit godt valg.

Bah! Python er et latterlig språk, ser INGEN fordeler med Python, det har en rotete syntaks, inneffektive programmer, og de er ikke blitt enige om hvordan GUI skal fungere der, dermed har du egen for gtk og egen for Qt som gjør at de som bruker programmet kanskje må laste ned ekstra GUI biblioteker for hvert program.

Det tar ikke kortere tid å utvikle programmer i Python eller Java, du har ingen fordeler i Python fremfor Java eller C#, og i tillegg har Python er dårlig gjennomtenkt API for C programmer.

Dessuten kommer jeg aldri over hvor UTROLIG STYGT språket ser ut, det er like estetisk som QuickBasic.

Når det gjelder spill, så skrives motorene som regel i C++, kanskje også litt assembly, men for selve dynamikken i spillet, så brukes som regel et scriptspråk, oftest LUA. Men det finnes tonnevis med andre. Selv liker jeg Squirrel ganske godt, fordi det har C++ syntaks, og fordi det er ikke laget med tanke på å være et general purpose språk (som Python) men nettopp for å være et scriptspråk til spill. Det er veldig enkelt å implementere, og syntaksen er enkel.

Dette innlegget sier mer om din trangsynthet enn noe annet. Har du prøvd Python? Da mener jeg om du faktisk har prøvd å lage noe i det og ikke bare prøvd det i noen minutter før du gav opp fordi ting ikke fungerte akkurat slik du var vant med fra C#.

Angående GUI ser jeg ikke helt hva du vil frem til. Såvidt jeg vet må du vel installere GTK eller Qt dersom du ikke har disse fra før, uansett om programmet er skrevet i C# eller Python. Eller mener du kanskje at C# allerede har GUI-støtte "innebygd" og derfor ikke trenger GTK eller Qt? Vel, det trenger ikke Python heller.

og i tillegg har Python er dårlig gjennomtenkt API for C programmer.

Dette kan du vel utdype.

Og til slutt: syntaksen til Python er minst like logisk oppbygd som den vi finner i C#. Kan du peke ut hva som er så stygt at det minner om QuickBasic?

teflonpanne · 17. mai 2008

Hehe, argumentene går stort sett i subjektive meninger om estetikk og ikke om funksjonaliteten. Det samme har man jo hørt om emacs osv, "ser ut som det er fra 1970" etc. Velvel, er vel miljøskade fra windows Selv syns jeg python er ganske pent og kraftig lite språk med en del kule ting. Men nå skal jeg ut og feire nasjonaldagen så jeg har ikke tid til å bli med på denne diskusjonen

Kenjuudo · 17. mai 2008

Joda, men IL koden som blir generert er ganske spesifikk for hvilken operasjon som skal skje, så det er lite rom for å optimalisere fordi JIT-en forhåpentligvis velger den beste løsningen.

Kubisk bezier funksjon i C#:

public static float CubicBezierInterpolate(float a, float b, float c, float d, float t)
{
return (1f - t) * (1f - t) * (1f - t) * a + 3 * t * (1f - t) * (1f - t) * b + 3 * t * t * (1f - t) * c + t * t * t * d;
}

Den genererte IL-en for samme koden:

.method public hidebysig static float32  CubicBezierInterpolate(float32 a,
															float32 b,
															float32 c,
															float32 d,
															float32 t) cil managed
{
 .maxstack  4
 ldc.r4	 1.
 ldarg.s	t
 sub
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldarg.0
 mul
 ldc.r4	 3.
 ldarg.s	t
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldarg.1
 mul
 add
 ldc.r4	 3.
 ldarg.s	t
 mul
 ldarg.s	t
 mul
 ldc.r4	 1.
 ldarg.s	t
 sub
 mul
 ldarg.2
 mul
 add
 ldarg.s	t
 ldarg.s	t
 mul
 ldarg.s	t
 mul
 ldarg.3
 mul
 add
 ret
}

Og den ferdig genererte maskinkoden:

push		ebp  
mov		 ebp,esp 
push		edi  
push		esi  
push		ebx  
sub		 esp,30h 
xor		 eax,eax 
mov		 dword ptr [ebp-10h],eax 
xor		 eax,eax 
mov		 dword ptr [ebp-1Ch],eax 
cmp		 dword ptr ds:[009697F4h],0 
je		  00000021 
call		79477097 
fldz			 
fstp		dword ptr [ebp-3Ch] 
nop			  
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fmul		dword ptr [ebp+18h] 
fld		 dword ptr [ebp+8] 
fmul		dword ptr ds:[00CB1350h] 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fmul		dword ptr [ebp+14h] 
faddp	   st(1),st 
fld		 dword ptr [ebp+8] 
fmul		dword ptr ds:[00CB1358h] 
fmul		dword ptr [ebp+8] 
fld		 dword ptr [ebp+8] 
fld1			 
fsubrp	  st(1),st 
fmulp	   st(1),st 
fmul		dword ptr [ebp+10h] 
faddp	   st(1),st 
fld		 dword ptr [ebp+8] 
fmul		st,st(0) 
fmul		dword ptr [ebp+8] 
fmul		dword ptr [ebp+0Ch] 
faddp	   st(1),st 
fstp		dword ptr [ebp-3Ch] 
nop			  
; Denne er merkelig, denne hopper til neste linje
; Skjønner ikke hva den er til
jmp		 00000090
fld		 dword ptr [ebp-3Ch] 
lea		 esp,[ebp-0Ch] 
pop		 ebx  
pop		 esi  
pop		 edi  
pop		 ebp  
ret		 14h

For meg ihvertfall er IL koden spesifikk nok til at en kan optimalisere, hvis det hadde vært nødvendig.

Fordelen med IL også er at den kan utnytte fremtidig hardware uten å måtte generere IL-en på nytt.

Klart du *kan* optimalisere IL'en slik at x86 koden blir kjappere, men hva skjer da om du plutselig finner ut at du skal kjøre koden på en prosessor som ikke støtter halvparten av alle instruksjonene som x86 gjør? IL koden blir definitivt optimalisert videre mot eventuell maskinkode på eventuell platform. Og hva disse optimaliseringene går ut på, er det umulig å ha oversikt over fordi alle platformer er forskjellige. Derfor er de mange av de gamle optimaliseringsteknikkene i dag stort sett uten generell virkning. En automatisert optimalisering klarer ikke nødvendigvis å gjøre koden kjappere og så så spesifikk som du vil ha den.

Mr.Garibaldi · 18. mai 2008

Klart du *kan* optimalisere IL'en slik at x86 koden blir kjappere, men hva skjer da om du plutselig finner ut at du skal kjøre koden på en prosessor som ikke støtter halvparten av alle instruksjonene som x86 gjør? IL koden blir definitivt optimalisert videre mot eventuell maskinkode på eventuell platform. Og hva disse optimaliseringene går ut på, er det umulig å ha oversikt over fordi alle platformer er forskjellige. Derfor er de mange av de gamle optimaliseringsteknikkene i dag stort sett uten generell virkning. En automatisert optimalisering klarer ikke nødvendigvis å gjøre koden kjappere og så så spesifikk som du vil ha den.

Noe av det samme problemet har du jo også med maskinkode. En optimalisering for en cpu gir nødvendigvis ikke en bedring av effektiviteten for andre cpuer og kan faktisk være tregere på noen cpuer. Videre kan du finne at en cpu støtter noen spesielle operasjoner som gjør at den vil være bedre skikket til å løse en oppgave enn hva en annen cpu, uten denne støtten, er.

Med IL kan du foreta generelle optimaliseringer slik at den generellt sett blir raskere, og hvis du møter en plattform som har noe ekstra funksjoner kan VMen optimalisere for dette. Dermed får du en bedre ytelse jevnt over, noe som ikke vil være mulig i maskinkode, uten å skrive forskjellige kodeveier.

berland · 18. mai 2008

I disse tider der det er en monoton stigende utvikling blant fri programvare, så hadde jeg aldri i verden startet med å lære meg programmeringsspråk som er tuftet på en proprietær grunntanke (les: alt fra Microsoft). Min anbefaling er å holde seg unna det som ikke gir deg plattformuavhengighet, skal man se 10 år framover i tid så er det lite tvil om at det vil lønne seg (kun på kort sikt er det klart det fortsatt kan være økonomi i proprietære systemer).

siDDis · 18. mai 2008

Vell C# er ein veldig åpen plattform, Microsoft har implementert det bare til Windows men også gitt ut ein åpen spesifikasjon som andre bruker for å implementere alternativet som har namnet Mono til andre plattformer.

Kenjuudo · 18. mai 2008

Klart du *kan* optimalisere IL'en slik at x86 koden blir kjappere, men hva skjer da om du plutselig finner ut at du skal kjøre koden på en prosessor som ikke støtter halvparten av alle instruksjonene som x86 gjør? IL koden blir definitivt optimalisert videre mot eventuell maskinkode på eventuell platform. Og hva disse optimaliseringene går ut på, er det umulig å ha oversikt over fordi alle platformer er forskjellige. Derfor er de mange av de gamle optimaliseringsteknikkene i dag stort sett uten generell virkning. En automatisert optimalisering klarer ikke nødvendigvis å gjøre koden kjappere og så så spesifikk som du vil ha den.

Noe av det samme problemet har du jo også med maskinkode. En optimalisering for en cpu gir nødvendigvis ikke en bedring av effektiviteten for andre cpuer og kan faktisk være tregere på noen cpuer. Videre kan du finne at en cpu støtter noen spesielle operasjoner som gjør at den vil være bedre skikket til å løse en oppgave enn hva en annen cpu, uten denne støtten, er.

Med IL kan du foreta generelle optimaliseringer slik at den generellt sett blir raskere, og hvis du møter en plattform som har noe ekstra funksjoner kan VMen optimalisere for dette. Dermed får du en bedre ytelse jevnt over, noe som ikke vil være mulig i maskinkode, uten å skrive forskjellige kodeveier.

Du har rett, men misforstår samtidig hva jeg mener: De automatiserte og generelle optimeringene vi her snakker om, kan ikke måle seg med spesifikk håndoptimert maskinkode når det gjelder ytelse. Men mens IL kan compiles mot hvilket som helst instruksjonssett, er den klassiske metoden å holde seg innenfor et spesifikt et. Jeg kommer aldri til å påstå at IL ikke har flere fordeler enn maskinkode. Men når det gjelder rå kraft vinner maskinkode i min bok.

Giddion · 18. mai 2008

Vell C# er ein veldig åpen plattform, Microsoft har implementert det bare til Windows men også gitt ut ein åpen spesifikasjon som andre bruker for å implementere alternativet som har namnet Mono til andre plattformer.

Vel du har rett, men også litt feil (etter mitt syn), windows forms er f. eks. ikke åpen. Det ville forundret meg stor hvis microsoft hadde brukt så mye tid og penger på en platform som uten videre kan overføres til *nix systemer.

Trenger litt hjelp til valg av programeringsspråk

Anbefalte innlegg

Lenke til kommentar

Videoannonse

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Hvem er aktive 0 medlemmer