Java Micro Edition Benchmarking

Java Micro Edition Benchmarking Mirko Schmitt, Mat.-Nr.: 191959, mirkoschmitt@freenet.de

Inhaltsverzeichnis 1. Bestandteile von Java ME 3 1.1. Personal Java 3 1.2. Embedded Java 4 1.3. Connected Limited Device Configuration 4 1.4. Mobile Information Device Profile 5 1.5. Connected Device Configurations 5 1.6. Foundation Profile 6 1.7. Personal Basis Profile 6 1.8. Personal Profile 6 2. Testumgebung 7 2.1. Testgerät - Sony Ericsson W800i 7 2.2. Testgerät - Qtec S200 8 2.3. ARM Jazelle-Technologie 8 2.3. Jazelle DBX 9 3. Benchmarks 11 3.1. Primitives Drawing 11 3.1.1. Auswertung 12 3.1.2. Auswertung - Zeit relativ zur Pixelanzahl 13 3.2. Dhrystone 14 4. Fazit 16 5. Quellenverzeichnis 17 Seite 2 / 17

1. Bestandteile von Java ME Java ME wurde konzipiert um auf PDAs und Handys oder Geräten mit geringem Speicher und Rechenleistung plattformübergreifende Software zu entwickeln. Zu den Hauptkomponenten von Java 2 Platform, Micro Edition (J2ME-Plattform) gehören CDC (Connected Device Configurations), CLDC (Connected Limited Device Configurations) und MIDP (Mobile Information Device Profiles). Die Entwicklungsumgebung dazu heißt Sun Java Wireless Toolkit. [17] Sun verfolgt bei Java ein Konzept, das auf Configurations und Profiles basiert. Dazu können noch spezielle APIs geladen werden. Configurations sind sehr stark von der zur Verfügung stehenden Prozessorleistung, dem ROM und dem RAM abhängig. Die Configuration beinhaltet den passenden Interpreter für die jeweiligen Bedingungen. Die Profiles beinhalten Bibliotheken, die Funktionen auf die Schnittstellen des Gerätes bereitstellen. Die Auswahl des passenden Profiles läßt sich durch Fragen wie "Besitzt mein Gerät einen Bildschirm?", "Wie performant ist dieser?", "Kann ich Eingaben mit der Tastatur oder Maus machen?", "Brauche ich Userinteraktion?", usw. beantworten. Einige optionale APIs sind: SIP-Telefonie, Bluetooth, OBEX (Object Exchange), JDBC (Java Database Connectivity), OpenGL, Messaging-API(SMS), XML- Parser und der Security-API. Seite 3 / 17

1.1. Embedded Java Embedded Java gehört nicht direkt zu Java ME, aber hat den Grundgedanken von Java ME, nämlich Java Anwendung auf Geräten mit stark begrenzten Resourcen zu laufen, gemeinsam. Deswegen wird es hier trotzdem aufgeführt. Es beinhaltet fast alle Klassen der Standard Edition. Die Virtual Machine ist auf einen kleine Speicherverbrauch optimiert und ist auch auf Geräten ohne Tastatur, Maus und Bildschirm lauffähig. Der Speicherverbrauch für den Interpreter beläuft sich auf 30MB für Java SE 5.0 und 24MB für Java 1.4.2. Von Sun wird behauptet, daß Embedded Java generell auf jedem Gerät, das 32MB ROM und 32MB RAM bereitstellt, lauffähig ist.[1] 1.2. Personal Java Personal Java gehört auch nicht direkt zu Java ME, aber es war der Vorgänger des Personal Profiles, welches zu Java ME gehört. Aus historischen Gründen wird deshalb Personal Java hier aufgelistet. Es wurde einst für PDAs und Geräten mit ähnlicher Speicherausstattung entwickelt. Es basiert auf Java 1.1.8 und stellt somit nur die AWT- Schnittstelle.[2] Die Entwicklung und Support wurde schon seit längerem eingestellt. Von Sun wird geraten, möglichst schnell auf Java ME umzusteigen, vermutlich, weil Java ME sehr modular aufgebaut ist und die persönlichen Bedürfnisse maßgeschneidert werden kann, anstatt wie bei Personal Java viele Klassen zu besitzen und damit auch viel Speicher auf dem ROM zu verbrauchen, wovon man nur einige benötigt. 1.3. Connected Limited Device Configuration CLDC stellt dabei die untere Schicht dar und stellt grundlegende Funktionen bereit, wie sie auch in der Java Standard Edition vorhanden sind. Dazu gehören Streams, Zufallszahlengenerator, Threads. Bibliotheken zur Erstellung einer grafischen Oberfläche gehören nicht mit zum Umfang der CLDC. CLDC benötigt einen 16 oder 32-Bit Prozessor, mindestens 160KB nicht-flüchtigen Speicher und 32KB flüchtigen Speicher. Die Klassen sind zwar an die Java Standard Edition angelehnt, jedoch fehlen einige Streams, wie z.b. die FileInput- und FileOutputStreams und gepufferte Streams. Es gibt zwei verschiedene Interpreter, zum einen den KVM und den CLDC Hotspot Interpreter. Letzterer ist eine modifizierte Version des Hotspot-Interpreters, wie er in der Java Standard Edition benutzt wird und ist deshalb leistungsfähiger als der ressourcenschonende KVM. CLDC 1.0 unterstützt keine Gleitkommadatentypen wie float oder double. Will man sich dieser Datentypen bedienen, muß man CLDC in der Version 1.1 benutzen.[3] Seite 4 / 17

1.4. Mobile Information Device Profile MIDP ist eine Erweiterung von CLDC und beinhaltet Bibliotheken zur Erstellung von grafischen Oberflächen auf Geräten mit sehr kleinem Display oder starker Einschränkungen bezüglich der Grafikleistung. Die Streams aus dem CLDC werden um TCP-Fähigkeit erweitert. In Version 2 wurden einige neue Features eingebracht, die vorallem von der Handybranche inspiriert wurden, wie die Klasse GameCanvas mit Double-Buffering und eine sehr einfache und flexible Möglichkeit Grafikelemente auf diesem GameCanvas darzustellen. Um die Spiele mit Sound zu untermalen wurde auch eine neue Mobile Media API hinzugefügt, die z.b. erlaubt verschiedene Codecs zu laden und die Laustärke zu kontrollieren.[4] 1.5. Information Module Profile IMP ist ein noch eher unbekanntes Profile. Es besteht aus genau den gleichen Klassen wie das MIDP und ist auch genau wie dieses mit den optionalen Paketen erweiterbar, mit einer Ausnahme. IMP besitzt keine GUI-Fähigkeiten, und ist im Grunde für Geräte geeignet, die einem Mobiltelefon ähnlich sind, aber ohne Display. Denkbar sind hier zum Beispiel Notrufsäulen, wie sie an Autobahnen zu finden sind, oder Alarmanlagen, die dann den Notruf selbstständig über das Mobilfunknetz tätigen. 1.5. Connected Device Configuration CDC ist sozusagen der große Bruder von CLDC, es benötigt 2MB RAM und 2,5MB ROM. Als Virtual Machine steht ausschließlich die Java Hotspot VM, wie sie auch in der Standard Edition benutzt wird, zur Verfügung. Die Klassen des CDC beinhalten im Grunde alle Klassen aus CLDC, zusätzlich die Reflection-Klassen, alle Referenz-Klassen der Standard Edition (ReferenceQueue, SoftReference, WeakReference), NumberFormat- Klassen, Kryptographische Klassen zur Schlüsselerstellung und -verwaltung, CRC32, Java Native Interface(JNI) und Remote Method Invocation(RMI). Als typisches Beispiel werden hier immer Navigationssysteme erwähnt oder Leistungsstarke PDAs genannt. Das ist jedoch nicht ohne weiteres nur mit dem CDC möglich. Das CDC enthält keinerlei grafische Oberfläche und Bedienelemente. Der Vorteil von CDC ist, daß Anwendungen vollständig kompatibel zu der Java Standard Edition sind. Auf das CDC können dann noch Profiles aufgesetzt werden, Java Foundation Profile, Java Personal Basis Profile oder Java Personal Profile, die die Funktionalität erweitern.[5] Seite 5 / 17

1.6. Foundation Profile Das Java Foundation Profile(FP) ist als Erweiterung für CDC gedacht. Es beinhaltet Sockets, HTTP-Verbindungen, Reader und Writer, Code Signaturen, Zertifikate. Pakete zur GUI-Erstellung (z.b. aus dem Paket javax.swing oder javax.microedition.lcdui) sind auch hier nicht vorhanden. Das Foundation Profile wird deswegen meist nur für Geräte ohne Bildschirm verwendet. Einsatzgebiete sind hier vorallem Netzwerkdrucker und Router.[6] 1.7. Personal Basis Profile Das Personal Basis Profile(PBP) ermöglich die Entwicklung von Anwendungen mit Leightweight-Grafikkomponenten. Es liefert dazu grundlegende Klassen des Abstract Window Toolkit(AWT) wie Canvas oder MouseListener. HTTP-Streams stehen jetzt zur Verfügung und damit die Möglichkeit, Klassen über ein Netzwerk nachzuladen.[7] 1.8. Personal Profile Als drittes Profile für CDC ist das Personal Profile(PP) verfügbar. Es erweitert das Personal Basis Profile um komplette AWT-Funktionalität, also Heavyweight-GUI- Elemente, MouseListeners und Applet-Fähigkeiten. Das Personal Profile dient als Ersatz für das eingestellte Personal Java. Das Portieren von Anwendungen von Personal Java zum Personal Profile ist sehr leicht, da dort praktisch alle Funktionalitäten, die es in Personal Java gibt auch vorhanden sind, nur geringfügig anders implementiert und in das Konzept Configurations and Profiles eingefügt.[8] Seite 6 / 17

2. Testumgebung Auf dem Markt sind derzeit zahlreiche Hersteller, wie Motorola, Nokia, LG, BenQ Siemens, Samsung und Sony Ericsson vertreten, die ihre Mobiltelefone vertreiben. In der Regel wird dabei auf schon etablierte Hardware zurückgegriffen. In den neueren Mobiltelefonen finden sich häufig Prozessoren der ARM-Familie. Die ARM-Prozessoren bieten eine hohe Flexibilität, weil sie ideal für das Einsatzgebiet ausgesucht werden können. Einige mögliche Eigenschaften sind zum Beispiel Energieeffizienz oder Bytecode- Beschleunigung. Den folgenden Tests ist dabei die Auswirkung der dieser Beschleunigung gewidmet und wieviel davon beim Verbraucher ankommt. 2.1. Testgerät Sony Ericsson W800i Das erste Testgerät ist das W800i von Sony Ericsson. Leider sind zu diesem Gerät sehr wenig Informationen verfügbar. Während man überall Informationen über Ausstattungsumfang (Bluetoothfähigkeit, Displaygröße, usw.) finden kann, gestaltet sich die Suche nach verwendeter Architektur und zum Prozessor schwierig. Auch in Sony Ericssons Developer Forum bekommt man keine Informationen über das Innenleben des Mobiltelefons. In einschlägigen Foren konnte man jedoch die wesentlichen Details der verwendete Architektur erfahren.[12][21] Prozessor und Architektur Speicherausstattung Display Firmware[13] Betriebssystem ARM9E-Familie 200 MHz RAM nicht ermittelbar 34 MB nichtflüchtig fest im Gehäuse 512 MB entfernbar, Mini-SD-Card 176x220 Pixel R1AA008 Sony Ericsson eigenes OS Version des OS über die Firmware- Version festgelegt Seite 7 / 17

2.2. Testgerät - Qtek S200 Das zweite Gerät ist das S200 von Qtek. Die Informationen über das Gerät waren einfach vom Hersteller über die firmeneigene Website zu bekommen. Die Bedienung erfolgt über ein Touchpad. In dem Smartphone ist der OMAP850 von Texas Instruments verbaut.[14] Prozessor und Architektur Speicherausstattung Display ARM9EJ-S 200 MHz 64 MB RAM 128 MB ROM Erweiterbar durch SD-Card 240x320 Pixel Firmware 2.15.4.47 Betriebssystem Windows Mobile 5.0 2.3 ARM Jazelle-Technologie Der OMAP850 Chip besitzt als Prozessor einen ARM926EJ-S. Das Besondere daran ist, daß, im Vergleich zum Sony Ericsson W800i, Hardwarebeschleunigung für Java- Bytecode benutzt wird. Die Technologie, die verwendet wird, heißt ARM Jazelle. Die Technologie basiert zum einen auf Jazelle DBX (Direct Bytecode Execution) Erweiterung. Der Bytecode wird hier direkt ausgeführt. Der zweite Bestandteil der Erweiterung ist die Jazelle RCT (Runtime Compilation Target). Die RCT beschleunigt Aufgaben wie Just-In-Time-Compilation(JIT), bei der häufig genutzter Bytecode in nativen ARM- Code compiliert werden. Alternativ zu JIT steht Ahead-of-Time(AOT) zur Verfügung. Bei diesem Verfahren wird der der Bytecode schon bei der Installation der Java-Anwendung in ARM-Instruktionen compiliert.[15] Seite 8 / 17

2.4 Jazelle DBX ARM Prozessoren unterstützten bisher 32-Bit Instruktionen, sowie den Thumb- Befehlssatz. Der Thumb-Befehlssatz packt die häufigsten ARM-Befehle in 16-Bit Instruktionen. Das führt in der Regel zu einer 35-40% höheren Codedichte. Mit Jazelle DBX wird ein dritter Befehlssatz eingeführt. In diesem Modus kann die CPU Java-Bytecode laden und dekodieren. Für die Java-Objekte wird auch ein Operand-Stack angelegt, der zur Verwaltung der Java-Objekte dient. Um Größe und Performance zu reduzieren ist Jazelle DBX als Finite-State-Machine in die ARM-Pipeline implementiert anstatt als Microcode-Engine. Um in den DBX-Modus zu wechseln, wird ein neuer Befehl "Branch-to-Java" benutzt. Es wird eine Einstiegsadresse für das Programm übergeben. Danach arbeitet der Prozessor mit 32-Bit Addressierung und nicht wie im ARM oder Thumb-Modus mit 16-Bit- Adressierung. Es werden immer 4 Bytecodes auf einmal geladen. Ein neues Register, das Current Processor State Register (CPSR) ist für die Behandlung von Interrupts und Exceptions zuständig. Dadurch ist jede Interrupt-Routine, die den Machine-State beim Eintritt speichert und beim Beenden wieder lädt, kompatibel zu Jazelle DBX. Jazelle DBX ist so implementiert, daß ein Interrupt während der Bytecode- Ausführung behandelt werden kann und die Latenz der Interruptbehandlung nicht beinflusst wird. Nach der Behandlung der Interrupts wird der Bytecode weiter ausgeführt. Es soll damit auch während der Ausführung von Bytecode eine Echtzeit- Interruptbehandlung möglich sein. Seite 9 / 17

Während der Prozessor im Java-Modus ist, werden einige ARM-Register für Javaspezifische Aufgaben benutzt. Der Stackpointer und die oberen 4 Stackeinträge werden in jeweils einem ARM-Register abgelegt. Die meisten Programme arbeiten nur mit einer geringen Stacktiefe. Dadurch, daß die 4 oberen Einträge in Registern gespeichert werden, wird die Jazelle DBX noch performanter, weil dadurch der Speicherzugriff reduziert wird. Jazelle DBX implementiert 134 (bei ARM926EJ-S) der Java-Bytecodes in Hardware. Dazu werden nur 12000 zusätzliche Gates benötigt. Bei herkömmlichen bytecodeausführenden Prozessoren liegt die Anzah der benötigten Gates bei 60000-100000. Die geringe Anzahl an Gates reduziert den Energieverbrauch und hat nur wenig Einfluß auf die Performance. Trifft der Prozessor auf einen unbekannten Bytecode, dann tritt eine Exception auf. Er wechselt vom Java-Modus in den ARM- Modus. Hier kann dann zum Beispiel eine Virtual Machine aufgerufen werden, die den Bytecode interpretiert. Um das Zusammenspiel zwischen Jazelle DBX und der Virtual Machine zu ermöglichen, benötigt man den Jazelle Support Code. Dieser ist schon für verschiedene Betriebsysteme von ARM implementiert worden. Darunter Linux, PalmOS, SymbianOS und WindowsCE.[20] Seite 10 / 17

3.0 Benchmarks Für die Java Standard Edition gibt es einen SPEC JVM98 sowie einen Java Business Benchmark (JBB2005), einen Anwendungstest. Leider hat sich für die Microedition noch kein standardisierter Test etabliert.[18][19] Beide Prozessoren der Testgeräte sind ein ARMv9 Modell mit der gleichen Taktfrequenz (200MHz). Der Prozessor des Qtek-S200 besitzt jedoch eine Java-Bytecode- Beschleunigung. Natürlich spielen auch andere Faktoren eine wichtige Rolle, z.b. Betriebssystem, Firmware und Speicherausstattung. Die beiden Geräte wurden hart resettet, also alle Daten gelöscht und in den Auslieferungszustand gebracht. Danach wurde die jeweils aktuelle Firmware aufgespielt. Die folgenden Tests können einen Eindruck vermitteln, wieviel von der Bytecode- Beschleunigung letzten Endes beim Verbraucher ankommen. 3.1. Primitives Drawing In dem Test werden 20000 immer gleich große, farbige Rechtecke an zufälligen Positionen auf den Bildschirm gezeichnet. Gemessen wird indirekt auch die Zeit, die die Java-Methode "repaint()" benötigt um den Bildschirm neu zu zeichnen, sowie die Geschwindigkeit des Zufallszahlengenerators. Absolute Messung Umrechnung relativ zur Pixelanzahl Modell SE-W800i QTek-S200 SE-W800i QTek-S200 Pixelanzahl 38720 p 76800 p 38720 p 76800 p Durchlauf 1 3703 ms 3289 ms 0,0956 ms/p 0,0428 ms/p Durchlauf 2 3784 ms 3293 ms 0,0977 ms/p 0,0429 ms/p Durchlauf 3 3659 ms 3320 ms 0,0945 ms/p 0,0432 ms/p Durchlauf 4 3689 ms 3281 ms 0,0953 ms/p 0,0427 ms/p Durchlauf 5 3710 ms 3330 ms 0,0958 ms/p 0,0434 ms/p Durchlauf 6 3732 ms 3301 ms 0,0964 ms/p 0,0430 ms/p Durchlauf 7 3670 ms 3347 ms 0,0948 ms/p 0,0436 ms/p Durchlauf 8 3727 ms 3363 ms 0,0963 ms/p 0,0438 ms/p Durchlauf 9 3703 ms 3332 ms 0,0956 ms/p 0,0434 ms/p Durchlauf 10 3673 ms 3334 ms 0,0949 ms/p 0,0434 ms/p Durchlauf 11 3749 ms 3348 ms 0,0968 ms/p 0,0436 ms/p Durchlauf 12 3718 ms 3294 ms 0,0960 ms/p 0,0429 ms/p Durchlauf 13 3736 ms 3334 ms 0,0965 ms/p 0,0434 ms/p Durchlauf 14 3688 ms 3331 ms 0,0952 ms/p 0,0434 ms/p Durchlauf 15 3664 ms 3337 ms 0,0946 ms/p 0,0435 ms/p Durchlauf 16 3676 ms 3333 ms 0,0949 ms/p 0,0434 ms/p Durchlauf 17 3669 ms 3359 ms 0,0948 ms/p 0,0437 ms/p Durchlauf 18 3690 ms 3329 ms 0,0953 ms/p 0,0433 ms/p Durchlauf 19 3679 ms 3288 ms 0,0950 ms/p 0,0428 ms/p Durchlauf 20 3691 ms 3367 ms 0,0953 ms/p 0,0438 ms/p Abk ürzungen: p= pixel Seite 11 / 17

3.1.1 Auswertung 4000 ms 3750 ms 3500 ms 3250 ms 3000 ms 2750 ms 2500 ms 2250 ms 2000 ms 1750 ms 1500 ms 1250 ms 1000 ms 750 ms 500 ms 250 ms 0 ms 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Qtek S200 Sony Ericsson W800i SE-W800i QTek-S200 Artihmetisches Mittel 3701 ms 3326 ms Varianz 1051 ms² 687,1 ms² Standardabweichung 32,42 ms 26,21 ms Seite 12 / 17

3.1.2 Auswertung - Zeit relativ zur Anzahl der Pixel des Displays 0,1000 ms/p 0,0900 ms/p 0,0800 ms/p 0,0700 ms/p 0,0600 ms/p 0,0500 ms/p 0,0400 ms/p 0,0300 ms/p 0,0200 ms/p 0,0100 ms/p 0,0000 ms/p 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Qtek S200 Sony Ericsson W800i SE-W800i QTek-S200 Artihmetisches Mittel 0,09557 ms 0,04330 ms Varianz 7,012*10-7 ms²/p² 1,165*10-7 ms²/p² Standardabweichung 8,374*10-4 ms 3,413*10-4 ms Seite 13 / 17

3.2. Dhrystone Um eine Vorstellung von der Prozessorleistung, ohne die Grafikleistung dabei zu berücksichtigen, zu bekommen, wurde Dhrystone-Benchmark benutzt. Dieser war nicht für Java ME verfügbar, so daß er erst für Java ME umgeschrieben werden musste. Als Referenz dafür diente die Version 2.1 im C-Quellcode.[16] Modell SE-W800i QTek-S200 Durchlauf 1 17211 d/s 28011 d/s Durchlauf 2 16583 d/s 25773 d/s Durchlauf 3 17699 d/s 25380 d/s Durchlauf 4 17699 d/s 28985 d/s Durchlauf 5 17761 d/s 24875 d/s Durchlauf 6 17793 d/s 25252 d/s Durchlauf 7 17793 d/s 29254 d/s Durchlauf 8 17857 d/s 26455 d/s Durchlauf 9 17761 d/s 27624 d/s Durchlauf 10 17761 d/s 25974 d/s Durchlauf 11 17730 d/s 25641 d/s Durchlauf 12 16778 d/s 27855 d/s Durchlauf 13 16722 d/s 25706 d/s Durchlauf 14 17825 d/s 28985 d/s Durchlauf 15 17761 d/s 28490 d/s Durchlauf 16 17761 d/s 24691 d/s Durchlauf 17 17667 d/s 27932 d/s Durchlauf 18 17761 d/s 26246 d/s Durchlauf 19 17667 d/s 25839 d/s Durchlauf 20 17730 d/s 27472 d/s Abkürzungen: d= Dhrystones Seite 14 / 17

30000 d/s 27500 d/s 25000 d/s 22500 d/s 20000 d/s 17500 d/s 15000 d/s 12500 d/s 10000 d/s 7500 d/s 5000 d/s 2500 d/s 0 d/s 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Qtek S200 Sony Ericsson W800i SE-W800i QTek-S200 Artihmetisches Mittel 17566 d/s 26822 d/s Varianz 158,85*10 3 d 2 /s 2 1289,5*10 3 d 2 /s 2 Standardabweichung 398,56 d/s 1479,7 d/s Seite 15 / 17

4. Fazit Die Java Bytecode-Beschleunigung ist zwar zu bemerken, jedoch für den Endverbraucher wohl kaum spürbar. Vor allem die Grafikleistung wird nur gering von der Bytecode- Beschleunigung beinflusst, betrachtet man den kompletten Bildschirm und nicht nur einzelne Pixel. Die Schwankungen, die beim Dhrystone-Benchmark unter Windows Mobile auftraten lassen vermuten, daß der Prozess-Scheduler des Betriebssystems die Java Virtual Machine, die ja auch als Prozess läuft, zwischendurch unterbricht und einem anderen Prozess die CPU kurzzeitig zuteilt, was zu einer sprunghaft wechselnden Performance führt, wie man sie im Dhrystone-Benchmark sieht. Die Ergebnisse des Benchmarks des W800i von Sony Ericsson schwanken weniger stark. Die Performance liegt beim Dhrystone-Benchmark unter der des S200, dafür liefert der Interpreter aber eine konstantere Performance. Leider scheinen auch Grafikoperationen nur wenig von der Bytecodebeschleunigung zu profitieren. Man kann das Anhand der Ergebnisse beider Benchmarks sehen. Betrachtet man den prozentualen Performanceunterschied beider Geräte, so profitieren einfache Rechenoperationen mehr davon. Dhrystone (Dhrystones/Sekunde) 152,69% Primitives Drawing (Zeit) 89,87% (Berechnung: Qtek-S200 / SE-W800i) Auf den Ersten Blick bewirkt die Bytecodebeschleunigung eine ca. 50% schnellere Ausführung beim Dhrystone und eine ca. 10% schnellere Ausführung beim Primitives Drawing. Jedoch sind die Betriebssysteme sehr unterschiedlich, was die Aussagekraft der Testergebnisse einschränkt. Windows Mobile bietet wesentlich mehr Funktionen, als das Betriebssystem von Sony Ericsson. Diese Funktionalität benötigt auch Systemresourcen. Es ist zu erwarten, daß die Unterschiede zwischen nicht-beschleunigtem und beschleunigtem Bytecode bei gleichem Betriebssystem noch deutlicher werden. Man kann aber sagen, daß einfache Rechenoperationen stärker von der Bytecodebeschleunigung profitieren als sehr dynamische Grafikausgaben. Der Verbraucher wird die zusätzliche Leistung der Bytecode-Beschleunigung des S200 wahrscheinlich nur in Ausnahmefällen bemerken, bei denen die reine Rechenleistung im Vordergrund steht, bei Spielen wohl eher weniger. Seite 16 / 17

5. Quellenverzeichnis 1 http://java.sun.com/j2se/embedded/faq.html 2 Eigene Erfahrung mit Personal Java, zwecks mangelnder Informationen auf der Sun-Homepage 3 http://java.sun.com/products/cldc/overview.html 4 http://java.sun.com/products/midp/overview.html 5 http://java.sun.com/products/personaljava/ 6 http://java.sun.com/products/foundation/overview.html 7 http://java.sun.com/products/personalbasis/overview.html 8 http://java.sun.com/products/personalprofile/overview.html 9 http://java.sun.com/javame/technology/index.jsp 10 http://java.sun.com/products/imp/overview.html 11 http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateid=6123&na vigationid=12000&contentid=4679 12 http://forum2.mobile-review.com/showthread.php?t=41590 13 ermittelt über tastencode: rechts, *, links, links, *, links, * 14 http://www.qtek.no/germany/produkte/s200.aspx 15 http://www.arm.com/products/esd/jazelle_architecture.html 16 http://www.netlib.org/benchmark/dhry-c 17 http://java.sun.com/javame/technology/index.jsp 18 http://www.spec.org/jvm98/ 19 http://www.spec.org/jbb2005/ 20 http://www.arm.com/pdfs/jazellewhitepaper.pdf 21 SE-W800i Bildquelle: http://www.xonio.com/features/feature_16235408.html Seite 17 / 17