Xamarin ontwikkelt port van Android naar C#
Xamarin, de ontwikkelaar van de opensource .Net-versie Mono, heeft Android naar C# geport. Volgens benchmarks van Xamarin zelf is de port naar C# stukken sneller dan Android in Java. De port, bijgenaamd XobotOS, is beschikbaar op Github.
Xamarin kon de miljoen regels Java-code van het Android-besturingssysteem porten naar C# met behulp van de tool Sharpen. Daarmee wordt een zogeheten machine translation gedaan die de Java-code naar C#-code vertaalt. De Android-port die nu op de virtuele machine van Mono draait, is volgens de ontwikkelaars veel sneller dan de standaard Java-achtige Dalvik VM.
Dat zou niet zo verwonderlijk zijn aangezien Dalvik nog vrij jong is en .Net al tien jaar ontwikkeld wordt, terwijl Mono bovendien uitgebreid geoptimaliseerd kan worden. Opvallend is de mogelijkheid om op de port de grafische engine van Android, Skia, direct aan te spreken in plaats van via Java. Het skunkworks-project ligt in lijn met de andere software van het bedrijf: Versies van Mono voor iOS en Android. Toch heeft het bedrijf gekozen om XobotOS niet verder te ontwikkelen en spreekt het van een onderzoeksproject. XobotOS is te downloaden van Github.
De port naar een andere taal dan Java komt op een moment dat Google en Oracle een hevig juridisch gevecht voeren. Laatstgenoemde beschuldigt Google ervan doelbewust geen licentie te hebben genomen op Java en dat Google derhalve Oracles copyright schendt met de Dalvik VM. Die VM gebruikt een taal en api die sterk op Java lijkt.
De snelheidswinst die Xamarin boekte met de port van Android naar C#.
Reacties (65)
Hmm, toch even kijken of dit gemerged kan worden met CM7 sources!, zou heerlijk zijn 
Holy shit! Dat verschil is wel heel erg groot!
Met een overstap van Java naar C# kan een single core dus best een quad core eruitrennen...
Met een overstap van Java naar C# kan een single core dus best een quad core eruitrennen...
Waarom denk je dat Windows Phone geen Dual/Quad Core nodig heeft om lekker te lopen?
OT: Het ziet er wel interesant uit. Helaas dat ze het niet verder zullen ontwikkelen. Ben benieuwd of er nog wat dev's verder zullen gaan nu het op github staat.
OT: Het ziet er wel interesant uit. Helaas dat ze het niet verder zullen ontwikkelen. Ben benieuwd of er nog wat dev's verder zullen gaan nu het op github staat.
Of bijvoorbeeld iOS met zijn Objective-C...
Ik persoonlijk vind dit niet verwonderlijk; Java is en was nooit de snelste programmeertal/ontwikkeltaal. C# / C++ zijn veel sneller, om al helemaal niet te spreken van assembly.
Java heeft daartentegen een groot voordeel van gemak, en interoperabiliteit en/of OS onafhankelijkheid.
In dit geval denk ik dat de keuze voor Java als basis voor Android een tradeoff geweest is tussen de verschillende zaken.
Java heeft daartentegen een groot voordeel van gemak, en interoperabiliteit en/of OS onafhankelijkheid.
In dit geval denk ik dat de keuze voor Java als basis voor Android een tradeoff geweest is tussen de verschillende zaken.
tja, het ligt allemaal aan de 'interpreter' niet aan de programmeertaal zelf, Java kan in principe net zo snel zijn als C#.
Niet dus, lees het artikel maar eens goed. Java heeft in het kader van OO purisme en backward compatibility de nodige steken laten vallen ten aanzien van performance, en dat probleem zit op het niveau van de JVM. Er is een flinke overhaul nodig van de JVM om dezelfde snelheid mogelijk te maken die de CLR inmiddels heeft.
[edit]
Correctie, ik had niet goed gelezen. Mea culpa.
[edit]
Correctie, ik had niet goed gelezen. Mea culpa.
[Reactie gewijzigd door Devil N op 3 mei 2012 15:18]
Welk artikel? Dit artikel gaat over de Google implementatie van een VM wat geen Java code zou moeten zijn.
Het artikel gelinkt onder het woordje "kon".
Niet helemaal. In .NET zijn generics ondersteund in de intermediate language, terwijl dat in Java niet het geval is. Generics zijn in Java enkel syntactic sugaring in de compiler (tenzij ze dat ondertussen veranderd hebben). .NET heeft dus ook al op intermediate language niveau enorme potentie voor snellere executie.
Hoe je het ook went of keert, het ligt allemaal bij de compiler/interpreter, niet de taal zelf.
Dat is in principe onzin. De JVM is inmiddels ongelooflijk geoptimaliseerd en wordt beschouwd als een efficiënter "beest" dan de c# vm. Alleen is Davik een eigen implementatie van Google. Dus daar zit waarschijnlijk minder optimalisatie in.
En iedereen maar zeggen dat alle javagrapjes over de snelheid outdated zijn in de 21e eeuw. 
Er zijn heel veel Java VM's. Dalvik is er maar eentje van. En hij's redelijk jong nog.
Het plaatje is wel een voorbeeld van een benchmark die maar een heel klein deel van de code tests. Ja, in het omgaan met structs en generics lijkt er flink wat te wat winnen, maar hoe veel resultaat er in een echt programma overblijft (waar meer gedaan wordt dan enkel een struct vullen) kun je hieruit niet afmeten.
Ook zegt dit niet veel over de snelheid van een Java VM aangezien de Dalvik VM zelf geen Java is (althans niet volgens Google) en in ieder geval een andere implementatie heeft dan bv de standaard Java VM. Mogelijk zou je dezelfde performance kunnen halen door de code om te zetten naar een standaard Java VM.
Ook zegt dit niet veel over de snelheid van een Java VM aangezien de Dalvik VM zelf geen Java is (althans niet volgens Google) en in ieder geval een andere implementatie heeft dan bv de standaard Java VM. Mogelijk zou je dezelfde performance kunnen halen door de code om te zetten naar een standaard Java VM.
Klopt, maar om even een simpel voorbeeld te geven. 3D spellen barsten van de structs (vectices) voor de modellen die gebruikt worden. Dus daar zou het bijvoorbeeld een welkome verbetering zijn.
Ik las het gister op Phoronix. Toch wel enigzins opvallend aangezien ik dacht dat mono vrij traag was vergeleken met de windows .net implementatie, maar blijkbaar is de dalvik VM nog trager.
[Reactie gewijzigd door A Noniem op 3 mei 2012 12:30]
Mono is al weer enkele jaren verder dan eerst, en in veel gevallen is het verschil praktisch te verwaarlozen.
Dat valt wel mee. Mono is niet gelijk aan .NET, waardoor ze in sommige tests langzamer zijn dan de "echte" .NET, maar in andere tests zijn ze juist weer sneller. Ze ontlopen elkaar niet zo heel veel.
Eigenlijk niet. In 1997 wou Microsoft namelijk aan de Java runtime al een aantal extenties toevoegen waarmee Java onder Windows een betere performance zou krijgen. Uiteindelijk heeft Sun via de rechter Microsoft verboden om een eigen java runtime machine te maken welke afwijkt van de java specificaties.
Twee jaar later kwam Microsoft met .NET waarvan de CLR (virtual machine) al een betere performance heeft dan java (maar code efficienter schrijven levert een veel betere performance winst op) en eveneens de taal heeft verbeterd met onder andere de introductie van properties.
Nu ChevronWP7 is gestopped wat eveneens betekend dat maatwerk applicaties niet meer mogelijk zijn omdat deze applicaties niet thuis horen in de marketplace.
Bedrijven gaan geen 100 dollar per jaar per toestel extra uitgeven voor een development licentie zodat op het toestel maatwerk applicaties geïnstalleerd kunnen worden. Echter als straks Android applicaties in zowel Java als C# (of andere .NET taal) geschreven kunnen worden is de kans groot dat een groot deel van de Windows Phone developers zal overstappen. Zeker omdat Microsoft ook al had aangegeven dat er geen nieuwe Silverlight versies meer komen.
Als je als developer dan toch moet switchen van Silverlight naar iets anders, waarom dan geen .NET applicaties voor Android schrijven? Daarbij mag Google zowel de CLR als C# gebruiken zonder licentie kosten omdat beide als standaard zijn gedeponeerd bij zowel ECMA (bij de meeste vooral bekend van Javascript) en ISO.
Een andere interessante vraag is natuurlijk dat als je niet de Valvik VM pakt, maar de standaard Oracle (Sun) Java VM of je dan ook al een betere performance hebt. Maar ik moet wel zeggen dat het verschil tussen de Dalvik en Mono VM heel erg groot is, zelfs als ze een aantal extremen hebben gebruikt voor de statistieken.
Maar ik zou weleens een vergelijking met 'standaard' benchmark tools willen zien..
Twee jaar later kwam Microsoft met .NET waarvan de CLR (virtual machine) al een betere performance heeft dan java (maar code efficienter schrijven levert een veel betere performance winst op) en eveneens de taal heeft verbeterd met onder andere de introductie van properties.
Nu ChevronWP7 is gestopped wat eveneens betekend dat maatwerk applicaties niet meer mogelijk zijn omdat deze applicaties niet thuis horen in de marketplace.
Bedrijven gaan geen 100 dollar per jaar per toestel extra uitgeven voor een development licentie zodat op het toestel maatwerk applicaties geïnstalleerd kunnen worden. Echter als straks Android applicaties in zowel Java als C# (of andere .NET taal) geschreven kunnen worden is de kans groot dat een groot deel van de Windows Phone developers zal overstappen. Zeker omdat Microsoft ook al had aangegeven dat er geen nieuwe Silverlight versies meer komen.
Als je als developer dan toch moet switchen van Silverlight naar iets anders, waarom dan geen .NET applicaties voor Android schrijven? Daarbij mag Google zowel de CLR als C# gebruiken zonder licentie kosten omdat beide als standaard zijn gedeponeerd bij zowel ECMA (bij de meeste vooral bekend van Javascript) en ISO.
Een andere interessante vraag is natuurlijk dat als je niet de Valvik VM pakt, maar de standaard Oracle (Sun) Java VM of je dan ook al een betere performance hebt. Maar ik moet wel zeggen dat het verschil tussen de Dalvik en Mono VM heel erg groot is, zelfs als ze een aantal extremen hebben gebruikt voor de statistieken.
Maar ik zou weleens een vergelijking met 'standaard' benchmark tools willen zien..
Je kan al een tijd C#/.Net gebruiken als taal voor Android, dat is 1 van de producten van Xamarin. Wat hier het verschil is is dat heel Dalvik en Android's java code was vervangen door C#, en niet alleen per applicatie zelf.
Bedrijven betalen inderdaad geen $100 per Windows Phone per jaar voor Windows Phone bedrijfsapps. Want dat is helemaal niet nodig.
Als bedrijf betaal je slechts eenmaal $100 voor 1 developer account. Met dat account publiceer je een onbeperkt aantal bedrijfsapps voor een onbeperkt aantal Windows Phones naar een Private Marketplace.
Installaties en updates via dergelijke Private Marketplaces werken net zoals op de Public Marketplace. Medewerkers hebben geen developer accounts nodig. Alleen verwijzingen naar de bedrijfsapps. Want die zijn niet zichtbaar in de Public Marketplace.
Afhankelijk van of en hoe bedrijfsapps bedrijfsnetwerken benaderen kunnen ze authenticatie en autorisatie regelen. Zodat niet iedereen met een verwijzing naar zo'n bedrijfsapp op een Private Marketplace overal toegang toe heeft.
C# en XAML vaardigheden komen prima van pas voor WinRT Metro apps. Deze draaien op Windows 8, Windows RT en Windows Phone 8. Waarschijnlijk volgend jaar ook op de opvolger van de Xbox 360.
Ondanks dat Windows Phone 7 apps op Windows Phone 8 blijven werken lijkt het mij juist verstandiger om je minstens ook op WinRT en Metro apps te richten.
Als bedrijf betaal je slechts eenmaal $100 voor 1 developer account. Met dat account publiceer je een onbeperkt aantal bedrijfsapps voor een onbeperkt aantal Windows Phones naar een Private Marketplace.
Installaties en updates via dergelijke Private Marketplaces werken net zoals op de Public Marketplace. Medewerkers hebben geen developer accounts nodig. Alleen verwijzingen naar de bedrijfsapps. Want die zijn niet zichtbaar in de Public Marketplace.
Afhankelijk van of en hoe bedrijfsapps bedrijfsnetwerken benaderen kunnen ze authenticatie en autorisatie regelen. Zodat niet iedereen met een verwijzing naar zo'n bedrijfsapp op een Private Marketplace overal toegang toe heeft.
C# en XAML vaardigheden komen prima van pas voor WinRT Metro apps. Deze draaien op Windows 8, Windows RT en Windows Phone 8. Waarschijnlijk volgend jaar ook op de opvolger van de Xbox 360.
Ondanks dat Windows Phone 7 apps op Windows Phone 8 blijven werken lijkt het mij juist verstandiger om je minstens ook op WinRT en Metro apps te richten.
Nee, ik gebruik voor mijn games onder Mac OS-X Mono, en onder Windows .NET. Er is geen merkbaar verschil in performance tussen de twee.
Hmm.. Betekent dit nu ook dat Android bv. naar x86(thuiscomputers) gecompiled kunnen worden, of dat deze versie enkel door een betere compiler gegooid kan worden voor android devices?
(Niet dat ik Android op mijn PC zou willen hebben
(Niet dat ik Android op mijn PC zou willen hebben
Dit was al mogelijk zoek maar eens op Android x86
Nee. Android is Java, dus dat kon al naar x86.
Dit betekent dat in plaats van Dalvik de Mono runtime gebruikt kan worden en dat die ook nog een veel sneller blijkt te zijn. Nadeel is dat 99% van de apps Dalvik nodig heeft (in java is geschreven).
Dit betekent dat in plaats van Dalvik de Mono runtime gebruikt kan worden en dat die ook nog een veel sneller blijkt te zijn. Nadeel is dat 99% van de apps Dalvik nodig heeft (in java is geschreven).
Niet geheel correct. Android heeft een C-basis en de apps draaien vervolgens met Java boven op dat platform.
Het enige verschil wat je zal zien is dus de performance van de apps, waaronder dus ook de Launchers en overige interface elementen vallen.
Het enige verschil wat je zal zien is dus de performance van de apps, waaronder dus ook de Launchers en overige interface elementen vallen.
Nee het wordt er niet makkelijker op. Deze optimalizatie werkt alleen op applicatie niveau. Niet op kernel niveau, en heeft dus geen invloed op wat voor instructieset Android kan draaien.
Sterker nog, Mono compileert naar bytecode ipv binary dus zou de executable gewoon compatible moeten zijn. Lijkt me niet dat het nu al werkt, maar als het werkt zou het dus met een enkele executable moeten kunnen.
Nou is dit niet Android dat ze geport hebben maar Darvik, dus de kans zit er eerder in dat we Android applicaties kunnen draaien onder onze bestaande OS'en.
Nou is dit niet Android dat ze geport hebben maar Darvik, dus de kans zit er eerder in dat we Android applicaties kunnen draaien onder onze bestaande OS'en.
Dit is uitermate interessant! Ik vraag me dan ook echt af hoe effectief Java-code nu is met hardware. Ik hoop wel dat Google dit onderzoek onder ogen krijgt en eventueel de code in een andere taal gaat schrijven. Misschien zou Android in C# wel beter renderen dan iOS.
Weet iemand in welke taal Windows Phone is geschreven? WP draait namelijk ook vele malen soepeler dan Android op dezelfde processor...
Weet iemand in welke taal Windows Phone is geschreven? WP draait namelijk ook vele malen soepeler dan Android op dezelfde processor...
Apps worden geschreven in C# en sommige in C++. Ik denk. weet dit alles behalve zeker, dat de OS laag in C/C++ geschreven is.
Na wat Google werk ga ik toch twijfelen, is heel android geschreven in Java of alleen Dalvik? (Ik neem aan dat deze los van elkaar staan)
Na wat Google werk ga ik toch twijfelen, is heel android geschreven in Java of alleen Dalvik? (Ik neem aan dat deze los van elkaar staan)
Je hebt gelijk, via de sdk is het c# of vb.net en sommige apps zijn ism Microsoft als native app ontwikkeld.
Dalvik is geschreven in C/C++, en is het stukje dat de java-achtige bytecode van SDK dus non-NDK)-apps uitvoert, en veel van de standaard Android-apps (launcher, contacts, phone app, etc) vallen daar ook gewoon onder.
Als het goed is(correct me if i'm wrong) is android deels in c geschreven, waaronder het deel dat opstart en de dalvik VM, maar is een groot deel van de android functionaliteit in Dalvik geschreven
Zo iets dacht ik al, leek me vrij onlogisch om een vrij langzame taal als Java te gebruiken om een OS op te bouwen.
Een beetje verwarrende titel, daardoor lijkt het net alsof Android in zijn geheel in Java is geschreven en in het artikel zelf worden Android en Dalvik ook door elkaar gebruikt.
@hiostu, dat was het gedeelte wat ik zeker wist. Ook ik heb wat appjes geschreven voor WP, welliswaar niet in de Marketplace gegooid
Een beetje verwarrende titel, daardoor lijkt het net alsof Android in zijn geheel in Java is geschreven en in het artikel zelf worden Android en Dalvik ook door elkaar gebruikt.
@hiostu, dat was het gedeelte wat ik zeker wist. Ook ik heb wat appjes geschreven voor WP, welliswaar niet in de Marketplace gegooid
Het is op applicatie- en kernel-laag verdeeld.
De kernel is op basis van Linux (dus C) en de applicatielaag is hoofdzakelijk Java, maar biedt ook mogelijkheid tot gebruik van C/C++ met de NDK.
De kernel is op basis van Linux (dus C) en de applicatielaag is hoofdzakelijk Java, maar biedt ook mogelijkheid tot gebruik van C/C++ met de NDK.
'heel' android is een linux dstro met een aangepaste (android) kernel.
Middleware, libs en API zijn in C geschreven.
Het applicatieplatform gebruikt de Davlik VM
Middleware, libs en API zijn in C geschreven.
Het applicatieplatform gebruikt de Davlik VM
Dalvik zelf zal geschreven zijn in C of C++. Dalvik is namelijk de VM waarin de Java code draait. As you may know wordt Java gecompileerd naar een bytecode, net zoals C#. Deze bytecode is onafhankelijk van besturingssysteem en platform (ARM, x86, x86_64). Op het moment dat je een Java applicatie (of C# for that matter) opstart draait dat programma in zo'n VM (Java Runtime, wat bij Android dus Dalvik is, en bij C# is dat bv. "het .NET framework" of Mono). Deze VM, wat wel afhankelijk van het besturingssysteem is, compileert vervolgens de bytecode naar native code. Dit is de JIT-compilation, waarbij JIT Just In Time betekend. Dus een "setje" bytecode instructies worden pas daadwerkelijk gecompileerd naar de instructieset van de huidige processor als het nodig is.
Wat er in dit geval aan de hand kan zijn zijn drie dingen:
De MSIL (Microsoft Intermediate Language, de bytecode van .NET) is veel efficiënter dan de bytecode van Java (dus MSIL heeft meer instructies in de bytecode bv. waardoor iets efficienter plaats kan vinden onder bepaalde native architecturen).
De compiler van Mono/.NET is efficiënter dan die van Java, waardoor de MSIL efficiënter is (betere paden door de code doorloopt bv.).
De Mono of .NET runtime is sneller dan Dalvik. Dus dat Dalvik langer nodig heeft om een blok bytecode te compilen naar de native code dan dat Mono/.NET dat heeft.
Edit:
@Novermans hieronder
Natuurlijk kan het ook de combinatie van zijn. Dus efficiëntere instructies in de bytecode, en efficiënter gecombineerd naar de bytecode, en daarnaast een betere runtime die de bytecode beter/sneller omzet naar de native code. Daarnaast kan het ook nog zijn dat de .NET runtime bv. beter gebruikt maakt van de processor. Dus dat bv. de Dalvik VM een bepaalde instructieset van de processor helemaal niet gebruikt, waar de Mono VM dat wel doet. Ook kan er intern in de VM een betere werking zijn. Beide talen doen zelf aan garbage collecting. Geheugen wat door de applicatie gebruikt wordt wordt dan beheerd door de VM, in plaats van door de applicatie (in tegenstelling tot native talen als C(++) waar de applicatie zelf om geheugen moet vragen en ook zelf moet vrijgeven). Het kan dus zijn dat de garbage collecting van Mono efficienter is dan de implementatie in Dalvik. (denk aan het "bij gebruik" opruimen van iets waardoor de app. "wacht" totdat het geheugen is opgeruimd tegenover het opruimen als de app. idle is)
Wat er in dit geval aan de hand kan zijn zijn drie dingen:
De MSIL (Microsoft Intermediate Language, de bytecode van .NET) is veel efficiënter dan de bytecode van Java (dus MSIL heeft meer instructies in de bytecode bv. waardoor iets efficienter plaats kan vinden onder bepaalde native architecturen).
De compiler van Mono/.NET is efficiënter dan die van Java, waardoor de MSIL efficiënter is (betere paden door de code doorloopt bv.).
De Mono of .NET runtime is sneller dan Dalvik. Dus dat Dalvik langer nodig heeft om een blok bytecode te compilen naar de native code dan dat Mono/.NET dat heeft.
Edit:
@Novermans hieronder
Natuurlijk kan het ook de combinatie van zijn. Dus efficiëntere instructies in de bytecode, en efficiënter gecombineerd naar de bytecode, en daarnaast een betere runtime die de bytecode beter/sneller omzet naar de native code. Daarnaast kan het ook nog zijn dat de .NET runtime bv. beter gebruikt maakt van de processor. Dus dat bv. de Dalvik VM een bepaalde instructieset van de processor helemaal niet gebruikt, waar de Mono VM dat wel doet. Ook kan er intern in de VM een betere werking zijn. Beide talen doen zelf aan garbage collecting. Geheugen wat door de applicatie gebruikt wordt wordt dan beheerd door de VM, in plaats van door de applicatie (in tegenstelling tot native talen als C(++) waar de applicatie zelf om geheugen moet vragen en ook zelf moet vrijgeven). Het kan dus zijn dat de garbage collecting van Mono efficienter is dan de implementatie in Dalvik. (denk aan het "bij gebruik" opruimen van iets waardoor de app. "wacht" totdat het geheugen is opgeruimd tegenover het opruimen als de app. idle is)
[Reactie gewijzigd door RobertMe op 3 mei 2012 13:12]
Kijk, dat is verhelderend! Helaas kan ik je geen +3 geven dus dat zullen andere mensen maar moeten doen.
Maar ik vraag me af, de verschillen zijn zo enorm groot. Is het dan niet waarschijnlijk een combinatie van die 3 factoren? Het verschil is, met het blote oog geschat, ongeveer een factor 20 bij 4.03 (laatste grafiek), dat is echt enorm veel. Zeker in een omgeving waar UX enorm belangrijk is (zie het succes van Apple).
Maar ik vraag me af, de verschillen zijn zo enorm groot. Is het dan niet waarschijnlijk een combinatie van die 3 factoren? Het verschil is, met het blote oog geschat, ongeveer een factor 20 bij 4.03 (laatste grafiek), dat is echt enorm veel. Zeker in een omgeving waar UX enorm belangrijk is (zie het succes van Apple).
De VM van het .NET framework is CLR - Common Language Runtime.
mono.NET heeft over het algemeen ook beter geheugenmanagement en meerdere engines beschikbaar voor garbage collection.
Het is optie 4: de benchmarks zijn cherry-picked.
In C# is een aantal taalfeatures (strucs en "echte" generics) die vergeleken met ogenschijnlijk dezelfde code in Java sneller kan performen (maar soms ook langzamer). Als je de benchmarks daar helemaal op tuned dan zie je deze verschillen. Een beetje Java ontwikkelaar optimaliseert deze codevoorbeelden bovendien heel anders.
In echte code is dit verschil door taalfeatures marginaal, omdat er veel meer situaties zijn waarbij dit onderscheid geen rol speelt en Java vergelijkbare taalfeatures heeft (C# is ten slotte gebaseerd op Java). Bovendien zijn structs soms langzamer dan objecten en vreet de manier waarop generics in .net werken iets meer geheugen. Voor alles geldt: it depends.
Dit nieuwsbericht is één op één overgenomen van eerdere Xamarin post, de diverse kritiek op het Internet is blijkbaar genegeerd. Er zijn ook diverse goede Android benchmarks beschikbaar, maar die worden hier voor het gemak even niet gebruikt. Het lijkt mij handig om hier eerst even te wachten: als ik Xamarin was had ik me ook niet zo belachelijk gemaakt met deze micro benchmark FUD.
In C# is een aantal taalfeatures (strucs en "echte" generics) die vergeleken met ogenschijnlijk dezelfde code in Java sneller kan performen (maar soms ook langzamer). Als je de benchmarks daar helemaal op tuned dan zie je deze verschillen. Een beetje Java ontwikkelaar optimaliseert deze codevoorbeelden bovendien heel anders.
In echte code is dit verschil door taalfeatures marginaal, omdat er veel meer situaties zijn waarbij dit onderscheid geen rol speelt en Java vergelijkbare taalfeatures heeft (C# is ten slotte gebaseerd op Java). Bovendien zijn structs soms langzamer dan objecten en vreet de manier waarop generics in .net werken iets meer geheugen. Voor alles geldt: it depends.
Dit nieuwsbericht is één op één overgenomen van eerdere Xamarin post, de diverse kritiek op het Internet is blijkbaar genegeerd. Er zijn ook diverse goede Android benchmarks beschikbaar, maar die worden hier voor het gemak even niet gebruikt. Het lijkt mij handig om hier eerst even te wachten: als ik Xamarin was had ik me ook niet zo belachelijk gemaakt met deze micro benchmark FUD.
Dalvik is in C/C++ geschreven en is een virtual machine voor Java. Alle apps die je voor Android in Java schrijft draaien dus in de Dalvik virtual machine.
Dat gaat niet zomaar, omdat alle apps die nu in de market staan dan niet meer werken (die zijn immers op Java gebaseerd). Het bewijst wel dat Dalvik nog stukken sneller kan, wellicht gaan ze wat ideeën afkijken van Mono zodat Dalvik er beter van wordt?
IKVM is een (vrij volledig) compitabele java runtime die boven op Mono of .Net draait., dat zou dus geen enkel probleem
[Reactie gewijzigd door Dykam op 3 mei 2012 13:41]
Wie port Android naar Java?
Ik weet niet of je het sarcastisch bedoeld. Maar het gaat er dus om dat Android juist van Java naar C# is geport .
.
Nee niet sarcastisch... Dalvik is tenslotte niet Java, maar een variant erop. Dus de echte Java VM kan wel eens heel wat efficiënter zijn dan die nieuweling Dalvik...
Een goeie vraag maar wellicht wat verkeerd gesteld.
De onderliggende code voor de Dalvik compiler is gebaseerd op het Apache Harmony project. Deze JVM heeft een eigen implementatie van de standaard. Het schijnt zo te zijn dat de officiele JVM van Oracle toevoegingen hebben die Dalvik/Harmony mist.
Zoals bijvoorbeeld HotSpot; het daadwerkelijk compileren van vaak gebruikte code blokken ipv JIT-compiling toe te passen.
De onderliggende code voor de Dalvik compiler is gebaseerd op het Apache Harmony project. Deze JVM heeft een eigen implementatie van de standaard. Het schijnt zo te zijn dat de officiele JVM van Oracle toevoegingen hebben die Dalvik/Harmony mist.
Zoals bijvoorbeeld HotSpot; het daadwerkelijk compileren van vaak gebruikte code blokken ipv JIT-compiling toe te passen.
Hopenlijk zien we dit snel terug in de custom roms! Ik denk namelijk niet dat apparaten die al Android draaien geupdate worden door de officiele ontwikkelaars, naar een C# gecompileerde Android versie. Dan is er namelijk voorlopig geen reden meer om een nieuw toestel te kopen .
.
Het is geen kwestie van "compilen met C#". De hele applicatielaag draait gewoon binnen de Mono VM ipv binnen de Dalvik VM. Ik kan me voorstellen dat het nog flink wat voeten in de aarde kan hebben om dit fatsoenlijk werkend te krijgen op een telefoon. Apps moeten waarschijnlijk ook worden omgezet naar C# om ze te kunnen draaien, net zoals alle andere systemen in en boven de applicatielaag.
Nee hoor, Mono kan ook java applicaties draaien. Zie:
http://www.mono-project.com/Java
http://www.mono-project.com/Java
Misschien dat ze naast elkaar kunnen draaien, dan zou langzamerhand Dalvik uitgefaseerd kunnen worden.. Ik vindt de verschillen wel echt gigantisch, zo erg zelfs dat er serieus overwogen moet worden om Dalvik te dumpen..
De Playstation-Suite SDK is overigens ook hierop gebasseerd (C#/Mono).
De Playstation-Suite SDK is overigens ook hierop gebasseerd (C#/Mono).
[Reactie gewijzigd door SuperDre op 3 mei 2012 13:30]
Het klink heel spannend maar ik vind de grafiek niet zo heel veel zeggen. Een versnelling van structs en generics betekend niet dat je applicatie ook sneller aanvoelt. Het zou interessanter zijn geweest om de snelheid van een aantal populaire apps te vergelijken, maar ik ben me ervan bewust dat dat het doel niet was.
Sowieso is het natuurlijk zo dat je bij Android niet perse de Java SDK hoeft te gebruiken, je kan ook voor de Android N(ative)DK kiezen en daar (delen van) je applicatie in programmeren.
Sowieso is het natuurlijk zo dat je bij Android niet perse de Java SDK hoeft te gebruiken, je kan ook voor de Android N(ative)DK kiezen en daar (delen van) je applicatie in programmeren.
Runtime Performance: even zoeken leverde de volgende resultaten op:
http://shootout.alioth.de...p;lang=csc&lang2=java
http://shootout.alioth.de...ang=csharp&lang2=java
Dat gaat weliswaar niet over Dalvik, maar het laat zien dat Java op windows sneller draait dan .NET op windows en dat Java op Linux veel sneller draait dan mono op Linux.
Ik ben geen verslaggever maar misschien zouden jullie Xamarin niet op haar blauwe ogen moeten geloven en niet linken naar hun benchmarks zonder enig scepticisme, en alle andere benchmarks betreffende het Java eco-systeem negeren.
http://shootout.alioth.de...p;lang=csc&lang2=java
http://shootout.alioth.de...ang=csharp&lang2=java
Dat gaat weliswaar niet over Dalvik, maar het laat zien dat Java op windows sneller draait dan .NET op windows en dat Java op Linux veel sneller draait dan mono op Linux.
Ik ben geen verslaggever maar misschien zouden jullie Xamarin niet op haar blauwe ogen moeten geloven en niet linken naar hun benchmarks zonder enig scepticisme, en alle andere benchmarks betreffende het Java eco-systeem negeren.
Je moet er rekening met houden dat deze benchmark focust op heel specifieke aspecten die door algoritmen behandeld worden. De implementatie van die algoritmen heeft een veel groter effect op de benchmark dan de snelheid van de engine.
En debian moeten we dan wel op hun blauwe ogen geloven? De bron die je aanhaalt is ook alles behalve ongekleurd.
Daarnaast valt het me altijd op dat applicaties ontwikkeld in Java altijd verschrikkelijk langzaam aanvoelen op windows, terwijl dat met .NET applicaties niet het geval is.
Daarnaast valt het me altijd op dat applicaties ontwikkeld in Java altijd verschrikkelijk langzaam aanvoelen op windows, terwijl dat met .NET applicaties niet het geval is.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Apple Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
