Der Siegeszug der .Net Plattform
-
gerade .NET programme wird man nicht wollen. auf einer monster CPU wie sie zZ jeder PC hat macht es einem wenig aus wenn die programme tonnenweise speicher rumschieben, auslagern etc.
aber selbst mit XNA merkt man schon wie schlecht es auf xbox laeuft, man hat nur 2 der 3 cores zur verfuegung weil ein ganzer core fuer den garbage collector noetig ist und selbst microsoft sagt in papern, dass man auf dinge wie 'accessor functions', operatoren usw. moeglichst verzichten soll etc.
Lass einfach mal windows auf einem atom notebook laufen und probier es aus, und die ARM cpus schaffen mit dual core vielleicht, bei gleichem takt, was ein singlecore atom leistet.und nein,ich bin nicht gegen .NET,JVM ist ebenfalls, trotz cross plattform, ziemlich langsam. Ich habe kein problem mit Eclipse auf meinem PC zuhause, aber auf dem netbook (obwohl ich die java version auf Sun's gewechselt habe wie mir empfohlen wurde), suckt es ziemlich rum. ich nutze meist VI zum editieren und eclipse nur zum debuggen.
auf android, wenn du dir ein paar entwickler foren anschaust, siehst du auch wie die leute zum teil gegen java/jvm/gc kaempfen. wenn du willst, dass dein spiel nicht ruckelt oder dein programm nicht ab und zu stallt, musst du dein programm sehr bewust, was speichermanagement angeht, programmieren. einfach nur ein port von einer platform mit x86 ist da garantiert der tod. sehr viel software nutzt mittlerweile das NDK,weil viele dinge mit java,trotz des JITs seit 2.2. nicht zu machen sind.und wenn du desktop programme mal auf dem netbook laufen laesst, merkst du dass sie oft absolut nicht angepasst sind. um wieder eclipse als beispiel zu nehmen, manche dialoge haben soviel gui, dass man sie so gross sind, dass man nicht an die untersten elemente kommt, geschweige den 'ok' oder 'cancel'(obwohl das ueber das X oben rechts geht) klicken kann.
es ist also nicht mit einmal neu kompilieren getan. als windows nutzer wird man sich vielleicht nicht so sehr an stalls stoeren (in relation zu recht fluessig arbeitenden phone interfaces), aber user interfaces sind ziemlich schlecht 1:1 zu uebernehmen. sowas mit fingern zu bedienen ist erst recht grausam (hatte mal ein tablet mit WinXP, das war selbst mti dem Pen noch unbrauchbar).
edit: ich beziehe mich hier natuerlich auf die besagte portierung existierender programme. nicht auf fuer die platformen angepasst software.
-
letztendlich werden die VMs gewinnen, wann immer es nicht um direkte Hardware-Ansteuerung geht.
Die Tendenz zur Virtualisierung von allem und jedem, sobald dies technisch ohne besondere Nachteile möglich ist, ist zwangsläufig und unaufhaltbar.
-
Ich glaube nicht, dass jetzt eine Revolution deswegen ausbricht. Auch wegen den von rapso genannten Punkten. Die ganz normalen Desktop-PCs werden weiterhin eine x86 CPU nutzen. Und wenn nicht kann man immer noch, wie hier schon genannt wurde, neucompilieren. Was dann ARM Prozessoren angeht: Ein Programm kann man nicht einfach so für eine mobile Plattform neucompilieren.
Aber ich würde auch sagen, dass die Programm-Ansprüche für mobile Geräte auch anders ist. Z.B. möchte wahrscheinlich kein Mensch unterwegs ein Textdokument schreiben wenn er keine ordentlich Tastatur hat.
-
!rr!rr_. schrieb:
letztendlich werden die VMs gewinnen, wann immer es nicht um direkte Hardware-Ansteuerung geht.
Die Tendenz zur Virtualisierung von allem und jedem, sobald dies technisch ohne besondere Nachteile möglich ist, ist zwangsläufig und unaufhaltbar.
schon seit 20 Jahren...
-
Leider werden solche Mutmassungen oft von Leuten angestellt, die in ihrem Leben nicht viel mehr als Java oder C# gesehen haben.
-
mindestens schrieb:
!rr!rr_. schrieb:
letztendlich werden die VMs gewinnen, wann immer es nicht um direkte Hardware-Ansteuerung geht.
Die Tendenz zur Virtualisierung von allem und jedem, sobald dies technisch ohne besondere Nachteile möglich ist, ist zwangsläufig und unaufhaltbar.
schon seit 20 Jahren...
Virtualisierung in der Form von Emulation ist schon einige Jahrzehnte älter, z.B. in der Großrechnerwelt. Bytecode-VMs für OO-Sprachen gibt es seit mind. 1980 oder Ende der '70er Jahre, Java ist nur die bekannteste, aber weder die einzige noch die erste.
-
hier ein paar Stichworte zu dem Thema:
p-Code (Pascal, mind. 1973),
O-code (BCPL, späte 1960er Jahre),
Warren abstract machine (Prolog, 1980er Jahre),
System 360,
...
-
Also schrieb:
wie bei x86 auch, oder?
Nein.
Bei x86 gibt es zwischen Intel und AMD ein Wissensaustauschprogramm.
SSE* wandert also auch in AMD und AMD64 wandert in Intel.
Das einzigste wo das nicht passierte, war bei 3dNow, aber das wurde ja kaum benutzt.Bei ARM SOCs ist das ganze viel gravierender.
Denn hier braucht man aus Performancegründen oft die zusätzlichen Einheiten wie z.b. MPEG4 Dekoder, FPU für eine effizientere Gleitkommaberechnung usw.
-
rapso schrieb:
und nein,ich bin nicht gegen .NET,JVM ist ebenfalls, trotz cross plattform, ziemlich langsam. Ich habe kein problem mit Eclipse auf meinem PC zuhause, aber auf dem netbook (obwohl ich die java version auf Sun's gewechselt habe wie mir empfohlen wurde), suckt es ziemlich rum. ich nutze meist VI zum editieren und eclipse nur zum debuggen.
Es kommmt ja leider auch noch auf die Qualität der JVM an.
Eine JVM für x86 ist auf die CPU hoch optimiert, so wie z.B. das Flashplugin für Windows auf x86 auch.
Aber das muß noch längst nicht für eine JVM für ARM bedeuten. Davon könnte auch die VM von .NET betroffen sein. Da gehen noch ein paar Jahre ins Land, bis die VM für ARM CPUs optimiert ist.
Sieht man ja auch am Flashplugin, daß auf ARM CPUs unter Linux z.b. ganz mieß ist.
-
Windows @ ARM schrieb:
Es kommmt ja leider auch noch auf die Qualität der JVM an.
wurde mir auch gesagt, und dass ich nur von der sun JVM was erwarten kann (obwohl ich persoenlich finde, dass die JIT-VM im IE recht gut ist, aber eben nure fuer applets).
Eine JVM für x86 ist auf die CPU hoch optimiert, so wie z.B. das Flashplugin für Windows auf x86 auch.
mein NetBook benutzt ja auch x86, Atom 270.
Aber du sprachst ja davon dass .NET auf ARM gut sein wird und ich hab als gegenbeispiel gesagt, dass die VMs (bzw JIT-VMs) selbst auf dem optimalen instruction set (wie gesagt, weiterhin x86) auf kleinen platformen total probleme macht. und mein zweites gegenbeispiel ist, dass MS ja wohl sehr faehig sein sollte seine eigene .NET VM auf seine eigene konsole optimal zu portieren. Aber leider laeuft es auf der xbox sehr langsam, nicht uebertrieben langsam, aber faktoren langsammer als was ich sonst gewohnt bin. auf windows, da laeuft .NET schneller, aber es zieht schon massig resourcen, ich wuerde da also das lob an massen an speicher und brutal schnelle cpus schieben.Aber das muß noch längst nicht für eine JVM für ARM bedeuten. Davon könnte auch die VM von .NET betroffen sein. Da gehen noch ein paar Jahre ins Land, bis die VM für ARM CPUs optimiert ist.
ja, aber in diesen jahren werden die leute ihre applikationen schon laengst entwickelt haben. schau dir apples move von PowerPC zu x86, das hat vielleicht ein jahr gedauert bis es alles gab. Und wie gesagt, es laufen zu lassen ist wirklich das kleinste portierungs problem. Usability ist ein viel viel viel ernsteres problem. Apple hat ja auch nicht OSX-lite auf phones und ipad gebracht, sondern ein dediziertes system, nicht wegen dem code (wer weiss, vielleicht basiert der iOS kernel sogar auf dem osx), aber wegen user interface etc.
Sieht man ja auch am Flashplugin, daß auf ARM CPUs unter Linux z.b. ganz mieß ist.
auf meinem netbook ist es auch ganz mies. wenn ich auf gamesindeustry.biz oder gametrailers.com gehe und auf manchen unterseiten dann (neben dem video auf gametrailers) die ganzen flash ads bekomme, macht sich das deutlich bemerkbar. wenn ich das java und flash plugin ausschalte, kann ich locker 20 tabs in firefox aufhaben, im hintergrund compilieren und musik hoeren ohne das kleinste ruckeln.