C#: C# vs andre språk, hurtighet

[Jim Rager]

Jeg er litt evneveik akkurat nå, å trenger diagrammer som viser ytelsesforskjellen på noen typiske programmeringsspråk vs C#. Jeg bryr meg lite om hvilken tester det er, trenger bare noen tester.

[audun1]

har nok ikke akurat noe test, men en liten tur på google ga noen resultat men hvor gode de er er en annen sak

 

http://www.google.com/search?client=opera&...=utf-8&oe=utf-8

[wolf5]

Vet ikke om noe slikt finnes. I så fall må det være noe sinnsykt omfattende arbeid å gjøre. Ørten tusen faktorer å ta inn i en benchmark.

 

Men tommelfinger regel er vel at jo nærmere maskinspråk du kommer, jo raskere går det.

 

Rekkefølge fra raskest til seinest.

1. Assembly er nærmest maskinspråk og det aller raskeste.

2. C/C++ tror jeg kommer som en fin #2

3. Andre språk som kompilerer til maskinkode (vb6,pascal,delphi?)

4. Språk som kompilerer til mellomkode. (Java/C#/VB.NET)

5. Script språk. (Javascript, VBScript, Python, Pearl)

[nOne]

Vet ikke om noe slikt finnes. I så fall må det være noe sinnsykt omfattende arbeid å gjøre. Ørten tusen faktorer å ta inn i en benchmark.

 

Men tommelfinger regel er vel at jo nærmere maskinspråk du kommer, jo raskere går det.

 

Rekkefølge fra raskest til seinest.

1. Assembly er nærmest maskinspråk og det aller raskeste.

2. C/C++ tror jeg kommer som en fin #2

3. Andre språk som kompilerer til maskinkode (vb6,pascal,delphi?)

4. Språk som kompilerer til mellomkode. (Java/C#/VB.NET)

5. Script språk. (Javascript, VBScript, Python, Pearl)

5756595[/snapback]

 

 

c# lager da ikke mellomkode? den kompilerer til mil, som igjen kompileres til maskinkode i kjøretid. dvs at maskinen jobber mot maskinkode , ikke det samme som java der man jobber mot en virituell maskin =)

 

 

hastigheten kommer minst like mye an på bruksområder og de bibliotekene du bruker som hvilket språk du bruker. Som oftest har man tidsfrister på det man skal levere og det er ofte lettere å lage kjappe, stabile og gode programmer i noe annet en c og assambly. Dersom man tar ett program lagd i c# og ett lagd i c++ som har hatt like lang utvilkingstid tror jeg ikke forskejellen er så stor som noen vil ha det til =)

 

Når det er sagt vil optimal kode på c++ være kjappere en c# for eksempel. Det er dog svært få programmer utover enkle komandolinjeprogrammer som kan kalles optimalt kodet...

 

 

Den tommelfinger regelen er jeg ikke nødvendig vis enig i =) assambly er for eksempel svært vrient å lage applikasjoner som er brukende med. Koden vil bli stygg og jeg tror faktisk at c ol er bedre til å skrive assambly en det mennesker er , nettop fordi det er utrolig mye assambly som er strukturbasert.

 

Eksempler på at dette ikke bare er meg er jo feks HLSL som kan skrives i c lignende kode, her er dette mer effektivt fordi det er for lett å gjøre ting tregt/ tungvint i assambly når man jobber direkte med dette.

 

 

Det er dog untak som for eksempel drivere. Her jobber man direkte mot propritær maskinvare og det vil nok derfor potensielt være bedre å skrive assembly(kommer an på hvor gode komilatorer du har og kompleksitet)

Endret 5. april 2006 av nOne

[budda]

wolf5 vet hva han prater om når det gjelder hvor raskt kode lar seg kjøre. Hvor raskt man kan kode funksjonalitet eller gui er en helt annen sak.

 

c# lager da ikke mellomkode? den kompilerer til mil, som igjen kompileres til maskinkode i kjøretid. dvs at maskinen jobber mot maskinkode , ikke det samme som java der man jobber mot en virituell maskin =)

 

Helt uenig. msil ER mellomkode på lik linje som bytekode. JVM er skrevet i native kode på lik linje som CLR. Dette går like raskt men jvm er litt tregere i oppstart.

[nOne]

wolf5 vet hva han prater om når det gjelder hvor raskt kode lar seg kjøre. Hvor raskt man kan kode funksjonalitet eller gui er en helt annen sak.

 

c# lager da ikke mellomkode? den kompilerer til mil, som igjen kompileres til maskinkode i kjøretid. dvs at maskinen jobber mot maskinkode , ikke det samme som java der man jobber mot en virituell maskin =)

 

Helt uenig. msil ER mellomkode på lik linje som bytekode. JVM er skrevet i native kode på lik linje som CLR. Dette går like raskt men jvm er litt tregere i oppstart.

5881715[/snapback]

 

 

tviler ikke på at wolf5 vet hva han/hun snakker om =) Det jeg prøvd å skrive var at det er mer rundt hastigheten til ett program er litt mer nyansert en hvilket som er nermest assambly.

 

det du sier om msil er faktis kikke helt riktig:

 

MSDN om JIT og MSIL

 

som du ser her vil koden ved første eksekvering kompileres til systemkode. i java er det etter det jeg forstår iallefall ikke slik, der vil koden altid gå igjenom JVM.

 

Dette kan dog unngås med å kompilere java filer til å ikke bruke JVM

 

IBM om java uten JVM

 

Det er derfor ikke altid helt enkelt å gi ett svar som assambly er raskes, så c/c++ osv. dette tar ikke tilstrekkelig hensyn til ting mer moderne språk benytter som intern gjennbruk av data osv. Dette gjelder også fing som cpu cashe osv.

 

Det er absolutt en kjerne av sannhet i det wolf5 sier, men effektiviteten på koden er i bunn og grunn avhengig av hvordan resursbruken i programmet blir når det er ferdig, ikke hvilket språk man benytter. Her er det ting som skiller språkene.

 

For eksempel kan man lage en egen tilkobling til databaser i assambly, eller man kan bruke en som er skrevet i java. Forskjellen i ytelse vil nok stort sett gå i favør for java sin dersom du skal ha ett litt kompleks system og ikke vil ha mange, mange programmerere til å knote ivei på assambly i lange tider =)

 

Dette kommer jo også selvsagt an på bibiotekene man bruker, men å si at assambly altid er kjappest blir bare for enkelt dersom vi snakker om reelle programmer som skal inneholde en del funksjonalitet.

 

ja det vil kjøre kjappest om du skriver god assambly, men dette har man ikke anledning til stort sett(med mindre vi snakker om svært spesialserte programmer til for eksempel medisinsk utstyr eller kommunikasjonsutstyr )

 

man vil derfor som oftest få ett kjappere program i c++ en i dårligere assambly, og det er også godt mulig at programmet går kjappere i c# en ikke optimal c++.

 

Det jeg vil frem til er at dersom koden er tilnermet optimal vil det wolf skisserer være mer eller mindre rett, men svært sjelden er dette tilfellet. Dette gjelder for eksempel interne optimaliseringer i språket/kompiler so mman ikke får dersom man skriver skriver for eksempel ren asambly(her adreserer man jo ting mer eller mindre direkte. Det er noen få unntak som assambly direktiver, men disse hjelper som regel ikke stort på dette =P)

[Hårek]

... i java er det etter det jeg forstår iallefall ikke slik, der vil koden altid gå igjenom JVM.

5886967[/snapback]

Tror ikke det. Når bytekode er kompilert av JIT så er det maskinkode, og skal jo ikke gjennom JVM en gang til.

Kan ikke se at det er noen særlig forskjell på C# og Java rundt dette.

 

Fordelen med å kompilere native er at du får maskinkode fra første stund. JIT må jo kompilere koden første gang den kjører, så ytelsen er dårligere i begynnelsen av applikasjonen.

[cyberpet]

Vet ikke om noe slikt finnes. I så fall må det være noe sinnsykt omfattende arbeid å gjøre. Ørten tusen faktorer å ta inn i en benchmark.

 

Men tommelfinger regel er vel at jo nærmere maskinspråk du kommer, jo raskere går det.

 

Rekkefølge fra raskest til seinest.

1. Assembly er nærmest maskinspråk og det aller raskeste.

2. C/C++ tror jeg kommer som en fin #2

3. Andre språk som kompilerer til maskinkode (vb6,pascal,delphi?)

4. Språk som kompilerer til mellomkode. (Java/C#/VB.NET)

5. Script språk. (Javascript, VBScript, Python, Pearl)

5756595[/snapback]

 

Nå er ikke jeg noen ekspert på dette, men mener helt klart jeg har hørt at Python/(Pearl) er en god del raskere enn f.eks. JAVA på tilsvarende oppgaver..

 

Søkte litt rundt, og fant at det visstnok varierer en del.. den største fordelen er nok at man kan gjøre mer med mindre kode..

twistedmatrix.com/~glyph/rant/python-vs-java.html

Endret 8. april 2006 av cyberpet

[abcd423417984]

Jeg leste en artikkel jeg fant på osnews.com en gang som sammenlignet C# og java. Der gikk Microsoft sin C# implementasjon av med en relativt klar seier, men Sun sin java hang ikke langt bak. Mono og andre C# og java implementasjoner derimot var laaaaangt unna.

 

Det er jo klart at å oppnå samme hastighet i C# som du har i native x86 assembly eller x86 kompilert C/C++ er ganske vanskelig, men C# er definitivt raskt nok til å gjøre de fleste jobbene det er lagd for. Forskjellen er ikke så enorm som mange tror.

Endret 8. april 2006 av invictus

[wolf5]

Jeg sa det bare var en tommelfinger regel. Og nevnte at det er ørten 1000 faktorer inni bildet :-)

 

Ta for eksempel

for(int i=0;i<1000;i++){
// do nothing
}

 

Jeg tror den listen vil stemme godt mot denne koden. Men igjen, det er ørten 1000 måter å programmere på.

 

Jo lengre ned på listen, jo enklere å kode (som oftest) da man per kodelinje har stadig mer tilsvarende maskinkode.

 

Enkelthet går som oftest ut over performance. Om ikke mye, så uansett litt.

Endret 8. april 2006 av wolf5

[budda]

Søkte litt rundt, og fant at det visstnok varierer en del.. den største fordelen er nok at man kan gjøre mer med mindre kode..

twistedmatrix.com/~glyph/rant/python-vs-java.html

5887163[/snapback]

 

Hellooo world!

 

Jeg er neppe noen java fanatiker, men artikkelen kan ikke bli mer missvisende. Vi prater benchmarking fra april år 2000 med jdk vs. 1.1 beta. og en os test-platform som er utdatert.

 

Kan denne sammenlignelsen bli verre..? Svaret er ja; Forfatteren åpner artikkelen med å si at testen er subjektiv, og avslutter artikkelen ved å fortelle hva han digger med phyton og hva han mener er negativt med java.

 

Ta en ekstra søkerunde!

[Gråskjegg]

Ta for eksempel

for(int i=0;i<1000;i++){
// do nothing
}

 

Jeg tror den listen vil stemme godt mot denne koden. Men igjen, det er ørten 1000 måter å programmere på.

5887248[/snapback]

Neppe et godt eksempel; moderne kompilatorer analyserer den koden, finner (enkelt) ut at den ikke gjør noenting, og optimaliserer den bort.

Så sånn sett kjører den like fort i alle kompilerte språk. (I release modus, naturligvis)

 

- grå -

[wolf5]

kverrulering :-P

 

Det vil alltid forekomme større og større overhead før koden kjøres hvor lengre bort du går fra kildekode. Gode kompilatorer vil fjerne mye, men det vil alltid forekomme diverse initieringer av diverse slag. Mindre av dette jo nærmere maskinkode du kommer.

 

Til eksempel. Kompiler en kildekode som ikke inneholder noe annet enn "END" (dvs avslutt som første kodelinje).

 

EXE/COM størrelse vil da være minst på 1. og størst på 5. i listen.

 

ASM kode vil kunne inneholde 2 bytes (int 20) mens C++ vil inneholde en del mer. C# vil inneholde enda mer, mens script språk vil eksekveres gjennom en annen EXE/DLL igjen.

 

Basert på det initielle vil listen holde mål. Da overhead blir større. Så kan man diskutere hvor mye den overheaden har å si men det er noe annet. Overhead er overhead :-)

Endret 12. april 2006 av wolf5