John Carmack über J2ME
31-03-05 10:25 Filed in: Java
Nach langer Abstinenz bei den .plan files, den Vorgängern des modernen Blog, meldet sich die "Programmierer-Legende" John Carmack jetzt mit einem neuen Blog zurück. Und gleich im zweiten Beitrag spricht er auch noch über J2ME. Endlich einmal etwas was ich vollständig verstehe! 
Auch wenn ich nicht in allen Punkten Carmacks Meinung teile ist es doch interessant eine Legende wie ihn darüber schreiben zu sehen. Was er besonders bemängelt ist natürlich die Geschwindigkeit von Java auf den Handsets, was er aber vollends auf die Interpreter-Natur von Java schiebt, was ich ein wenig engstirnig finde. Natürlich läuft native kompilierter Code schneller auf jeder Art von Prozessor, wenn man ihn mit einem einfachen Interpreter vergleicht. Besonders wenn man an in Ehren ergraute 16 Cores denkt, auf denen die 32 Bit basierte Java VM nur mehr schlecht als recht läuft, geschweige denn, das sie hier überhaupt schnell werden könnte. Nimmt man jedoch ein vernünftiges System, einen schnellen ARM Core, schnelle Anbindung an Speicher und Display sowie die moderne Hotspot Implementierung der CLDC VM sieht die Sache schon wesentlich besser aus. Leider sind solche Systeme schwer mit reinem native Code zu vergleichen, da man keine Möglichkeit hat solchen darauf auszuführen. Ich denke aber der Vorsprung dürfte, wie heute auf den PCs, nicht mehr ganz so groß sein wie Carmack es anprangert. Aber vielleicht hat er ja einfach nur die falschen Geräte ausprobiert. Immerhin gibt es momentan schon Geräte am Markt, die den anderen in Punkto Java-Geschwindigkeit deutlich davon laufen.
Was seinen Kommentar über das benutzen von reinem native Code und einer MMU anstatt eines Interpreters angeht bin ich gar nicht seiner Meinung. Würde man mit native Code und der MMU als Speichermanager arbeiten, währen einige Features von Java gar nicht machbar, und genau diese Features sind die Kernkomponenten von Java, die es überhaupt von C++ abhebt. Namentlich geht es hier um das Speichermanagement, die Benutzung von Referenzen anstatt von Zeigern, sowie die Garbage Collection. Und interessanter weise sehe ich hier gerade auch die Stärken von Java. Nicht nur bei den Sprachfeatures, sondern auch bei der Implementierung der neueren Systeme. Immerhin allokiert eine VM mit einem Generational Garbage Collector Speicher wie auf einem Stack, was eine Laufzeit von O(1) bedeutet, solange man nicht an die Grenze des momentan verfügbaren Speichers kommt. Und gerade C/C++ hat genau hier so seine Probleme. Muss man bei einem normalen malloc() doch in der Regel mit einer Laufzeit zwischen O(1) und O(n) im Worst Case rechnen. Je schlimmer desto länger das System schon läuft und umso mehr der Heap schon fragmentiert ist.
Betrachtet man Carmacks Kommentare mal aus der selben Sicht, fällt sein Resume meiner Meinung nach sogar eher positiv aus. Immerhin ist Carmack ein Hardcore-C-Programmierer. Da ist es kein Wunder das er sich, wie schon so viele vor ihm, erst einmal über die Einschränkungen beschwert, die einem C-Programmierer in Java auferlegt werden. Und dafür, das er sich erst seit kurzer Zeit mit der Thematik auseinander setzt hat er ziemlich schnell verstanden was Sache ist. Sein (relativ langer) Beitrag ist es definitiv wert gelesen zu werden, und ich hoffe schon insgeheim das auch einige Verantwortliche von Geräteherstellern ihn lesen und sich zu Herzen nehmen werden. Ein schnelles System ohne Flaschenhälse und eine für das System optimierte Java VM, das ist es was wir in zukünftigen Mobiltelefonen sehen wollen!
http://www.armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295
-Daniel
Auch wenn ich nicht in allen Punkten Carmacks Meinung teile ist es doch interessant eine Legende wie ihn darüber schreiben zu sehen. Was er besonders bemängelt ist natürlich die Geschwindigkeit von Java auf den Handsets, was er aber vollends auf die Interpreter-Natur von Java schiebt, was ich ein wenig engstirnig finde. Natürlich läuft native kompilierter Code schneller auf jeder Art von Prozessor, wenn man ihn mit einem einfachen Interpreter vergleicht. Besonders wenn man an in Ehren ergraute 16 Cores denkt, auf denen die 32 Bit basierte Java VM nur mehr schlecht als recht läuft, geschweige denn, das sie hier überhaupt schnell werden könnte. Nimmt man jedoch ein vernünftiges System, einen schnellen ARM Core, schnelle Anbindung an Speicher und Display sowie die moderne Hotspot Implementierung der CLDC VM sieht die Sache schon wesentlich besser aus. Leider sind solche Systeme schwer mit reinem native Code zu vergleichen, da man keine Möglichkeit hat solchen darauf auszuführen. Ich denke aber der Vorsprung dürfte, wie heute auf den PCs, nicht mehr ganz so groß sein wie Carmack es anprangert. Aber vielleicht hat er ja einfach nur die falschen Geräte ausprobiert. Immerhin gibt es momentan schon Geräte am Markt, die den anderen in Punkto Java-Geschwindigkeit deutlich davon laufen.
Was seinen Kommentar über das benutzen von reinem native Code und einer MMU anstatt eines Interpreters angeht bin ich gar nicht seiner Meinung. Würde man mit native Code und der MMU als Speichermanager arbeiten, währen einige Features von Java gar nicht machbar, und genau diese Features sind die Kernkomponenten von Java, die es überhaupt von C++ abhebt. Namentlich geht es hier um das Speichermanagement, die Benutzung von Referenzen anstatt von Zeigern, sowie die Garbage Collection. Und interessanter weise sehe ich hier gerade auch die Stärken von Java. Nicht nur bei den Sprachfeatures, sondern auch bei der Implementierung der neueren Systeme. Immerhin allokiert eine VM mit einem Generational Garbage Collector Speicher wie auf einem Stack, was eine Laufzeit von O(1) bedeutet, solange man nicht an die Grenze des momentan verfügbaren Speichers kommt. Und gerade C/C++ hat genau hier so seine Probleme. Muss man bei einem normalen malloc() doch in der Regel mit einer Laufzeit zwischen O(1) und O(n) im Worst Case rechnen. Je schlimmer desto länger das System schon läuft und umso mehr der Heap schon fragmentiert ist.
Betrachtet man Carmacks Kommentare mal aus der selben Sicht, fällt sein Resume meiner Meinung nach sogar eher positiv aus. Immerhin ist Carmack ein Hardcore-C-Programmierer. Da ist es kein Wunder das er sich, wie schon so viele vor ihm, erst einmal über die Einschränkungen beschwert, die einem C-Programmierer in Java auferlegt werden. Und dafür, das er sich erst seit kurzer Zeit mit der Thematik auseinander setzt hat er ziemlich schnell verstanden was Sache ist. Sein (relativ langer) Beitrag ist es definitiv wert gelesen zu werden, und ich hoffe schon insgeheim das auch einige Verantwortliche von Geräteherstellern ihn lesen und sich zu Herzen nehmen werden. Ein schnelles System ohne Flaschenhälse und eine für das System optimierte Java VM, das ist es was wir in zukünftigen Mobiltelefonen sehen wollen!
http://www.armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295
-Daniel
|