portieren von Programmen auf andere Plattformen [Archiv]

urpils

2009-06-14, 14:54:34

Hallo!

Das ist weniger eine Frage aus dem Bedürfnis etwas selbst zu tun, als vielmehr reine Neugier:

Mich interessiert, wie man ein Programm wie z.B. www.scummvm.org auf eine neue Plattform portiert.
Was muss das geschehen? wie geht man vor? wo sind Grenzen? wie lange dauert so etwas?

mir ist bewusst, dass das nicht in 2 Sätzen zu beantworten ist und ich weiß, dass diese Fragen einigen vielleicht unsinnig erscheint.. mich interessiert es aber irgendwie :D

danke schonmal, falls jemand was beiträgt! :)

Exxtreme

2009-06-14, 14:59:23

Erstmal muss man gucken wieviel plattformspezifisches Zeug benutzt wurde. Wenn man das ermittelt hat dann überlegt man sich ob man das plattformspezifische Zeug plattformunabhängig implementiert und/oder man einen Wrapper drumherum baut.

urpils

2009-06-14, 16:26:06

in dieser Richtung hat sich meine Vorstellung schon etwas ausgetobt... ich würde mich freuen, wenn ich es etwas genauer verstehen könnte... Links/Website/sonstige hinweise nehme ich dankend an :)

was wäre denn z.B. konkret zu tun wenn ich etwas von der bisherien Intelbasis/oder sonstwas auf sagen wir - ARM protieren wollte?

ist das immer Programm- und architekturspezifisch - auch welche librarys benutzt wurden? oder reicht es (wenn ein Programm dahingehend geplant wurde), dass ich dem Compiler sage, dass er einfach für ne andere Plattform kompilieren soll?

Ganon

2009-06-14, 16:26:10

Joahr, je nachdem auf welchem Level man ansetzt. Nehmen wir mal ScummVM als Beispiel.

Dort hat man, wie Exxtreme schon angedeutet hat, "das plattformspezifische Zeug plattformunabhängig implementiert". D.h. für die Grafikausgabe und Steuereingabe nutzt man z.B. SDL.

Das heißt aber nun nicht, dass ScumVM nun überall läuft. Das heißt dann nur soviel: "ScummVM läuft da wo SDL läuft". Also ist es nun die Aufgabe von SDL "überall" zu laufen.

Bei SDL nutzt man dann, wie Exxtreme auch schon sagte, diese Wrapper. Je nach System wird dann die entsprechende Funktion ausgeführt. Für Grafikausgabe unter Windows dann z.B. WinAPI, bei OS X Cocoa, bei Linux X11...

Will man nun eine neue Plattform erschließen braucht man dann logischerweise einen neuen Wrapper dafür.

Ganon

2009-06-14, 16:28:01

was wäre denn z.B. konkret zu tun wenn ich etwas von der bisherien Intelbasis/oder sonstwas auf sagen wir - ARM protieren wollte?

ist das immer Programm- und architekturspezifisch - auch welche librarys benutzt wurden? oder reicht es (wenn ein Programm dahingehend geplant wurde), dass ich dem Compiler sage, dass er einfach für ne andere Plattform kompilieren soll?

Sofern du kein Assembler nutzt, reicht hier meist ein einfaches neukompilieren der Anwendung (vom Endian-Problem mal abgesehen). Nutzt du natürlich eine Bibliothek, die Assembler nutzt und deswegen nur auf bestimmten Plattformen läuft, dann muss die Bibliothek halt erweitert werden.

urpils

2009-06-14, 17:06:29

ah.. sehr gut - das hat mir schon weiter geholfen! vielen Dank! :)

also in Kurzzusammenfassung:
man selbst schraubt im Prinzip daran, ein spezielles Betriebssystem mit vorahndenen APIs zu unterstützen. Die Prozessorarchitekturspezifischen Dinge sollten meistens irrelevant sein, weil das der Compiler für einen erledigt? (sofern man nicht irgendwo Assemblercode für eine spezielle Architektur nutzt)

Exxtreme

2009-06-14, 17:34:21

Der_Donnervogel

2009-06-14, 17:46:24

Richtig. Solange das Programm in einer Hochsprache vorliegt, muss man nur neu kompilieren. Nachdem man den plattformspezifischen Teil entfernt hat oder einen Wrapper drumherum gebaut hat. Über prozessorspezifische Dinge kümmert sich dann der Compiler.Vielleicht noch als kleine Ergänzung:
Bei Sprachen mit Laufzeitumgebung wie Java, muss man nicht mal neu compilieren. Sofern kein plattformabhängiger Code drinn ist, können die überall unverändert laufen, sofern die passende Laufzeitumgebung vorhanden ist. Außerdem sollte man vielleicht anmerken, dass der "plattformspezifische Teil" sehr groß sein kann, sofern man nicht irgend ein Framework verwendet, das auf mehreren Systemen vorhanden ist. Sofern man nicht schon im Vorhinein vorgesehen hat, dass das Programm portiert werden können soll, kann eine Portierung deshalb durchaus sehr "eklig" werden.

urpils

2009-06-14, 19:04:55

Vielleicht noch als kleine Ergänzung:
Bei Sprachen mit Laufzeitumgebung wie Java, muss man nicht mal neu compilieren. Sofern kein plattformabhängiger Code drinn ist, können die überall unverändert laufen, sofern die passende Laufzeitumgebung vorhanden ist. Außerdem sollte man vielleicht anmerken, dass der "plattformspezifische Teil" sehr groß sein kann, sofern man nicht irgend ein Framework verwendet, das auf mehreren Systemen vorhanden ist. Sofern man nicht schon im Vorhinein vorgesehen hat, dass das Programm portiert werden können soll, kann eine Portierung deshalb durchaus sehr "eklig" werden.

ja - das war mir bisher schon bewusst.. mein Interesse bezog sich eher auf Programmiersprachen ohne VM... Es gibt doch dieses interessante Projekt "Open Pandora" mit nem Arm Cortex A8 und nem PowerVR SGR 530, das bald vollendet sein dürfte... und die machen sich ne Menge Arbeit verschiedene Programme und Emulatoren zu portieren - und mich interessierte in dem Zusammenhang vor allem die Vorgehensweise und den Aufwand, den man sich dazu vorstellen muss.

ne Java-Laufzeitumgebung wird es für das Teil wahrscheinlich nciht geben nehme ich an.
Ich weiß, dass das wohl nicht mehr aktuell ist, aber ich bin mit dem Gefühl/Bewusstsein aufgewachsen, dass Java langsam ist - und deswegen kam mir der Gedanke im Zusammenhang mit diesem kleinen Teil gar nicht. (das für seine Größe aber sehr potent ist - vor allem hats ne lange Akkulaufzeit :) )

Der_Donnervogel

2009-06-14, 19:53:25

Ich habe keine Ahnung in wie weit Open Pandora Java unterstützen könnte (Open Pandora interessiert mich nicht wirklich). Allerdings die verwendete Cortex-A8 CPU würde es unterstützen. Die kann Jazelle, ist also in der Lage einen Teil des Java-Bytecodes direkt in Hardware ausführen. Sofern also der fehlende Rest, der in Software umgesetzt werden muss, dazu gebastelt wird ginge das schon.

Flolle

2009-06-14, 23:52:16

Ich weiß, dass das wohl nicht mehr aktuell ist, aber ich bin mit dem Gefühl/Bewusstsein aufgewachsen, dass Java langsam ist - und deswegen kam mir der Gedanke im Zusammenhang mit diesem kleinen Teil gar nicht. (das für seine Größe aber sehr potent ist - vor allem hats ne lange Akkulaufzeit :) )
Sorry für den Offtopic, aber an der Stelle muss ich einfach nachhaken, weil man das immer wieder hört/liest und es heutzutage einfach nicht mehr stimmt.

Die Meinung, dass Java langsam ist stammt aus Zeiten von Java 1.0 bis 1.2. Seitdem nutzt die Java-VM JIT und andere Technologien um mehr Performance aus den Anwendungen zu holen. Da ist verdammt viel Hirnschmalz in die Richtung geflossen und HotSpot (http://en.wikipedia.org/wiki/HotSpot) ist sau gut bei diesen Aufgaben geworden.

Generell ist Java um den Faktor 10 bis 100 schneller als mehr oder weniger all die hippen Scriptsprachen und schafft im Durchschnitt zwischen 90% und 70% der Geschwindigkeit von C++, ist also so schnell das man den Unterschied nur dan merkt wenn es auf jedes bischen Performance ankommt. Ich denke im Normalfall ist nicht mehr Performance der Ausschlag gebene Faktor bei der Auswahl der Sprache für ein Projekt, sondern eher Punkte wie Erfahrung der Entwickler mit der Sprache, schon vorhandene Bibliotheken, Entwicklungs-Tools und so weiter.

Das gleiche gilt im übrigen auch für C#. Nicht umsonst werden viele neue Projekt von Microsoft und generell für Windows mittlerweile mit .Net umgesetzt.

Dieser Post ist nicht böse gemeint, es wird nur langsam Zeit das die Mär vom langsamen Java den Leuten ausgetrieben wird. ;)

urpils

2009-06-15, 06:34:42

Sorry für den Offtopic, aber an der Stelle muss ich einfach nachhaken, weil man das immer wieder hört/liest und es heutzutage einfach nicht mehr stimmt.

Die Meinung, dass Java langsam ist stammt aus Zeiten von Java 1.0 bis 1.2. Seitdem nutzt die Java-VM JIT und andere Technologien um mehr Performance aus den Anwendungen zu holen. Da ist verdammt viel Hirnschmalz in die Richtung geflossen und HotSpot (http://en.wikipedia.org/wiki/HotSpot) ist sau gut bei diesen Aufgaben geworden.

Generell ist Java um den Faktor 10 bis 100 schneller als mehr oder weniger all die hippen Scriptsprachen und schafft im Durchschnitt zwischen 90% und 70% der Geschwindigkeit von C++, ist also so schnell das man den Unterschied nur dan merkt wenn es auf jedes bischen Performance ankommt. Ich denke im Normalfall ist nicht mehr Performance der Ausschlag gebene Faktor bei der Auswahl der Sprache für ein Projekt, sondern eher Punkte wie Erfahrung der Entwickler mit der Sprache, schon vorhandene Bibliotheken, Entwicklungs-Tools und so weiter.

Das gleiche gilt im übrigen auch für C#. Nicht umsonst werden viele neue Projekt von Microsoft und generell für Windows mittlerweile mit .Net umgesetzt.

Dieser Post ist nicht böse gemeint, es wird nur langsam Zeit das die Mär vom langsamen Java den Leuten ausgetrieben wird. ;)

genau deswegen schrieb ich ja auch, dass ich weiß, dass es nciht mehr aktuell ist... ich erinnere mich noch an einen Artikel in der Ct' vor einiger Zeit, indem Java teilweise bei gleicher Problemstellung schneller war als C++. Welche Bereiche das betrifft und ob da wirklich korrekt verglichen wurde weiß ich nicht mehr. ;)

ändert aber ncihts daran, dass ich damit groß geworden bin, dass Java langsam ist :D Das Gefühl "Java ist flott" kommt bei mir einfach nicht auf - egal obs stimmt oder nicht (und obwohl ich weiß, dass das so generell nicht mehr korrekt ist).

C# wird von M$ aber meines Wissens nach nicht primär aus Performancegründen genutzt, sondern da es gewisse Sicherheits und Fehlerschutzmechanismen bietet, die sehr praktisch sind um Bugs,... zu vermeiden.

Exxtreme

2009-06-15, 09:04:53

Die Bytecode-Sprachen wie Java oder C# haben den Nachteil, daß die Programme relativ lange brauchen um zu starten. Zuerst muss nämlich die Runtime gestartet werden und dann wird das Programm auch noch auf die Zielplattform compiliert. Sprich, selbst einfachste Tools brauchen rund 15 - 30 Sekunden. Wenn die Programme aber erstmal laufen dann merkt man kaum noch Unterschiede.

Wer Azureus kennt, der weiss was ich meine. Ist ein Java-Programm. :)

urpils

2009-06-15, 09:33:36

@Exxtreme: das trägt wahrscheinlich auch dazu bei, dass man dieses "Java ist lahm" Gefühl nicht so schnell verliert.

Ist es eigentlich möglich 3D beschleunigte (performante) Grafik mit Java so zu realisieren, dass es weiterhin Plattformunabhänig ist? Oder greift man in diesem Fall z.B. auf OpenGL zurück? Kann man Java mit OpenGL überhaupt vermischen? Fragen über Fragen... :D

Spiele, die auf Java aufsetzen sind ja auch eher selten.. mir fällt da spontan erstmal nur "Edna bricht aus" ein. (ist 2D)

Ganon

2009-06-15, 09:59:27

Ist es eigentlich möglich 3D beschleunigte (performante) Grafik mit Java so zu realisieren, dass es weiterhin Plattformunabhänig ist? Oder greift man in diesem Fall z.B. auf OpenGL zurück? Kann man Java mit OpenGL überhaupt vermischen? Fragen über Fragen... :D

jogl, lwjgl oder Java3D.

Während jogl und lwjgl OpenGL Wrapper sind, ist Java3D afaik eine eigene API.

Marscel

2009-06-15, 10:06:48

@Exxtreme: das trägt wahrscheinlich auch dazu bei, dass man dieses "Java ist lahm" Gefühl nicht so schnell verliert.

Meiner Meinung nach ist selbst Azureus akzeptabel für den Haufen von Features.

Ist es eigentlich möglich 3D beschleunigte (performante) Grafik mit Java so zu realisieren, dass es weiterhin Plattformunabhänig ist? Oder greift man in diesem Fall z.B. auf OpenGL zurück? Kann man Java mit OpenGL überhaupt vermischen? Fragen über Fragen... :D

Ja, überall, wofür z.B. JOGL zur Verfügung steht, kannst du auch plattformunabhängig 3D-Anwendungen schreiben.

Spiele, die auf Java aufsetzen sind ja auch eher selten.. mir fällt da spontan erstmal nur "Edna bricht aus" ein. (ist 2D)

Chrome nutzt, soweit ich gesehen haben, für die Spiellogik Java.

Ganon

2009-06-15, 10:42:44

Das Spiele in Java selten sind liegt wohl hauptsächlich daran, dass alle kommerziellen Engines kein Java nutzen ;)

Und wenn schon auf Managed-Sprachen, dann werden wohl die meisten .NET nutzen, wegen XBOX360 und man kann in .NET/C# die SIMD-Einheiten der Prozessoren direkt nutzen (zumindest in Mono) und trotzdem prozessorunabhängig bleiben (der JiTC passt das entsprechend an).
Bei Java geschieht das zwar auch, aber "nur" automatisch. Man hat keine direkten SIMD-Datentypen.

Dafür ist der HotSpot-Compiler in Java teilweise bis zu 6mal schneller als der Mono-Compiler. Von daher ist es dahingehend egal was man nutzt, wenn man "einfach" plattformunabhängig sein möchte. Da muss man ja zwangsläufig Java oder Mono nehmen. Die Plattformprobleme hat man da ja mehr bei OpenGL und der entsprechenden Treiber ;)

Monger

2009-06-15, 10:56:22

Die Bytecode-Sprachen wie Java oder C# haben den Nachteil, daß die Programme relativ lange brauchen um zu starten. Zuerst muss nämlich die Runtime gestartet werden und dann wird das Programm auch noch auf die Zielplattform compiliert.

Afaik sollte das heute überhaupt kein Problem mehr darstellen. Ein moderner Compiler kann heute etliche MB Code in Sekundenbruchteilen durchrechnen. Etwa die Zeit, die du brauchst um die Assemblies in den Speicher zu kopieren, brauchst du dann auch zum kompilieren. Das ist nix.

Das liegt imho an sprachspezifischen Bremsen. Ich hab z.B. die Erfahrung gemacht, dass das Anbinden von COM Referenzen in .NET ziemlich lange dauert. Da das immer beim Start gemacht wird, fällt das in die Ladezeit hinein.
Bei Java kann ich mich an das Argument erinnern, dass die Kommunikation mit den Windows Grafikbibliotheken unter AWT ziemlich träge ist, weil die keine nativen Calls absetzen können. Deshalb brauchen grafische Anwendungen ewig bis sie sich mal initialisiert haben, und sind auch in der Praxis dann nicht ganz so flott.
In welchem Maße das heute noch gilt, weiß ich nicht.

Aber generell lange Ladezeiten kann ich nicht bestätigen. Bei dem was ich hier an .NET Programmen verwende, geht das in Sekundenbruchteilen.

Kann man Java mit OpenGL überhaupt vermischen?
Es gibt verschiedene Java APIs für OpenGL. Mir fällt spontan Java3D ein, was aber wohl mittlerweile gestorben ist...
Geht also schon.

Exxtreme

2009-06-15, 11:08:59

Afaik sollte das heute überhaupt kein Problem mehr darstellen. Ein moderner Compiler kann heute etliche MB Code in Sekundenbruchteilen durchrechnen. Etwa die Zeit, die du brauchst um die Assemblies in den Speicher zu kopieren, brauchst du dann auch zum kompilieren. Das ist nix.

Das liegt imho an sprachspezifischen Bremsen. Ich hab z.B. die Erfahrung gemacht, dass das Anbinden von COM Referenzen in .NET ziemlich lange dauert. Da das immer beim Start gemacht wird, fällt das in die Ladezeit hinein.
Bei Java kann ich mich an das Argument erinnern, dass die Kommunikation mit den Windows Grafikbibliotheken unter AWT ziemlich träge ist, weil die keine nativen Calls absetzen können. Deshalb brauchen grafische Anwendungen ewig bis sie sich mal initialisiert haben, und sind auch in der Praxis dann nicht ganz so flott.
In welchem Maße das heute noch gilt, weiß ich nicht.

Aber generell lange Ladezeiten kann ich nicht bestätigen. Bei dem was ich hier an .NET Programmen verwende, geht das in Sekundenbruchteilen.

Ich habe auch paar .NET-Tools da und einige haben sogar Splash-Screens eingebaut damit man sieht, daß das Programm tatsächlich startet. ;)

Hier mal so ein Tool:
http://www.codeplex.com/Rawr

Und AWT wird heutzutage nicht mehr wirklich benutzt. Wird nicht umsonst Awful Window Toolkit parodiert. Man setzt eher auf Swing.

Ganon

2009-06-15, 11:09:23

Aber generell lange Ladezeiten kann ich nicht bestätigen. Bei dem was ich hier an .NET Programmen verwende, geht das in Sekundenbruchteilen.

Bei den meisten läuft .NET schon und muss dann, im Gegensatz zu Java, nicht erst gestartet werden.

Es gibt verschiedene Java APIs für OpenGL. Mir fällt spontan Java3D ein, was aber wohl mittlerweile gestorben ist...
Geht also schon.

Wurde vor kurzem wiederbelebt ;)

Ganon

2009-06-15, 11:11:45

Und AWT wird heutzutage nicht mehr wirklich benutzt. Wird nicht umsonst Awful Window Toolkit parodiert. Man setzt eher auf Swing.

Swing setzt bei den Zeichenroutinen auch "nur" auf AWT auf. ;) AWT ist nämlich der native Teil von Java. Da gibt es aber mit jeder Java-Version deutliche Verbesserungen. Von daher keine Ahnung wie es jetzt aussieht. Ich finde Swing recht schnell. Da kenne ich langsamere "native" Bibliotheken.

Exxtreme

2009-06-15, 11:27:17

Swing setzt bei den Zeichenroutinen auch "nur" auf AWT auf. ;) AWT ist nämlich der native Teil von Java. Da gibt es aber mit jeder Java-Version deutliche Verbesserungen. Von daher keine Ahnung wie es jetzt aussieht. Ich finde Swing recht schnell. Da kenne ich langsamere "native" Bibliotheken.
Soviel ich weiss es bei AWT so, daß dieses tatsächlich auf native Controls setzt. Sprich, ein AWT-Button unter Windows ist tatsächlich ein Win32-Button, welcher gekapselt wurde. Swing wiederum zeichnet sich selbst. Es nutzt zwar die "primitiven" Zeichenfunktionen des Betriebssystems aber ein Swing-Button ist was eigenes und kein natives Control.

http://de.wikipedia.org/wiki/Abstract_Window_Toolkit
http://de.wikipedia.org/wiki/Swing_(Java)

Ganon

2009-06-15, 11:55:26

Es nutzt zwar die "primitiven" Zeichenfunktionen des Betriebssystems aber ein Swing-Button ist was eigenes und kein natives Control.

Ja sagte ich ja. Und diese "primitiven Zeichenfunktionen" (btw. OpenGL) sind in AWT-Teil ^^

Der_Donnervogel

2009-06-16, 16:40:00

Aber generell lange Ladezeiten kann ich nicht bestätigen. Bei dem was ich hier an .NET Programmen verwende, geht das in Sekundenbruchteilen.Das gilt aber nur sofern das .Net-Framework schon geladen ist. Ist es geladen starten die Programme schnell. Muss es aber erst geladen werden, dauert das eine gefühlte Ewigkeit. Das selbe gilt auch für die Java-Runtime.
Ja sagte ich ja. Und diese "primitiven Zeichenfunktionen" (btw. OpenGL) sind in AWT-Teil ^^AWT und Swing sind auch im Hinblick auf das eigentliche Topic dieses Threads interessant zu betrachten da sie zwei verschiedene Ansätze mit dem selben Ziel, nämlich Portabilität, fahren. AWT verwendet die nativen Controls des Betriebssystems und ist somit schneller als Swing. Der Nachteil davon ist, dass man einen kleinsten gemeinsamen Nenner suchen mußte, der von allen Betriebssystemen untersützt wird. AWT ist also relativ schnell, kann dafür aber vergleichsweise wenig. Swing wiederum zeichnet seine Controls selber. Das ist etwas langsamer als direkt die Nativen zu verwenden. Dafür ist es möglich praktisch beliebige Controls anzubieten ohne auf die darunter liegende Plattform Rücksicht nehmen zu müssen. Swing ist somit etwas langsamer, dafür aber auch mächtiger.

The_Invisible

2009-06-16, 17:56:57

gibt eh sowas schönes wie qt wenn man es schnell und plattformunabhängig haben will. opengl ist da auch dabei.

mfg

Brillus

2009-06-17, 00:29:10

Für Plattform unabhänigkeit ahbe cih bis jetzt immer Java oder C in zusammenhang mit SDL genutzt. Wobei bei C öfters mal Probleme wenn du mit der Plattform den Compiler wechselst (Win+Visual C++-> Linux und gcc) da gibt es immermal kleine Unterschiede. Zum Beispiel die wenn du dir bei SDL OpenGL Funktionspointer liefern lässt. in Visual C kannst du die dir mit einen reinterpret_cast umwandeln beim gcc ausschließlich mit einem c-cast. Auch andere kleinigkeiten das teilweise bei einem Compiler eine Headerdatei eine andere Includiert und ein anderer Compiler das nciht macht.

Dann Java3D gefällt mir persönlcih nciht habe ich mal an der FH nutzen gemusst und naja fand es nciht so gut würde davon abraten, wobei ich nciht weiß wiegut die OpenGL-Implementierungen sind.

The_Invisible

2009-06-17, 11:30:35

reinterpret_cast ist ja kein C mehr.

aber sonst ja, der compiler kann oft ganz schön reinmurksen.

mfg

Controller Khan

2009-06-17, 12:04:21

gibt eh sowas schönes wie qt wenn man es schnell und plattformunabhängig haben will. opengl ist da auch dabei.

mfg

Qt ist ein Framework fuer C++ analog Class Libraries in .Net.

Mit QtOpenGL hat immer noch die verschiedenen OpenGl-Implementierung am Hals.

@Threadstarter
Was ist mit Plattform eigentlich gemeint ?

The_Invisible

2009-06-17, 12:20:47

Qt ist ein Framework fuer C++ analog Class Libraries in .Net.

Mit QtOpenGL hat immer noch die verschiedenen OpenGl-Implementierung am Hals.

ich meinte damit eher den vorteil das es offiziell für win, lin und mac freigegeben ist und man damit native binaries bekommt.

opengl habe ich nur am rande erwähnt. aber wenns eh immer unterschiedliche implementierungen gibt ist es eh egal.

mfg

Ganon

2009-06-17, 13:03:36

ich meinte damit eher den vorteil das es offiziell für win, lin und mac freigegeben ist und man damit native binaries bekommt.

opengl habe ich nur am rande erwähnt. aber wenns eh immer unterschiedliche implementierungen gibt ist es eh egal.

Jo, bei OpenGL ist die Programmiersprache das geringste Problem bei der Entwicklung ;) Hier prügelst du dich eher mit den Treibern rum und deren Bugs.

PHuV

2009-06-17, 16:37:50

Die Bytecode-Sprachen wie Java oder C# haben den Nachteil, daß die Programme relativ lange brauchen um zu starten. Zuerst muss nämlich die Runtime gestartet werden und dann wird das Programm auch noch auf die Zielplattform compiliert. Sprich, selbst einfachste Tools brauchen rund 15 - 30 Sekunden. Wenn die Programme aber erstmal laufen dann merkt man kaum noch Unterschiede.

Korrekt, und aus dem Grund wurde in meiner vorherigen Firma ein sogenannter JAVA-Deamon geschrieben, bei der die VM ständig läuft. Der JAVA-Deamon nahm dann einfach ständig neue Programme an. Damit war dann die Performance immer hervorragend. Einziger Nachteil, daß irgendwann der Speicher voll war, und das Ding neu gestartet werden mußte. Die Performance von C und Java-Programmen war dann fast gleich.