benchmarking von handies auf der Ebene der JVM

Java Micro Edition
Benchmarking
Mirko Schmitt, Mat.-Nr.: 191959, [email protected]
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), XMLParser 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 AWTSchnittstelle.[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), NumberFormatKlassen, 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-GUIElemente, 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 BytecodeBeschleunigung. 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
ARM9E-Familie 200 MHz
Speicherausstattung
RAM nicht ermittelbar
34 MB nichtflüchtig fest im
Gehäuse
512 MB entfernbar, Mini-SD-Card
Display
176x220 Pixel
Firmware[13]
R1AA008
Betriebssystem
Sony Ericsson eigenes OS
Version des OS über die FirmwareVersion 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 ARM9EJ-S 200 MHz
Speicherausstattung
64 MB RAM
128 MB ROM
Erweiterbar durch SD-Card
Display
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 JavaBytecode 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 ARMCode 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 ThumbBefehlssatz. 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-BitAdressierung. 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 BytecodeAusfü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 EchtzeitInterruptbehandlung 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 ARMModus. 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-BytecodeBeschleunigung. 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 BytecodeBeschleunigung 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.
Modell
Pixelanzahl
Durchlauf 1
Durchlauf 2
Durchlauf 3
Durchlauf 4
Durchlauf 5
Durchlauf 6
Durchlauf 7
Durchlauf 8
Durchlauf 9
Durchlauf 10
Durchlauf 11
Durchlauf 12
Durchlauf 13
Durchlauf 14
Durchlauf 15
Durchlauf 16
Durchlauf 17
Durchlauf 18
Durchlauf 19
Durchlauf 20
Absolute Messung
Umrechnung relativ zur Pixelanzahl
QTek-S200
SE-W800i
QTek-S200
SE-W800i
76800 p
76800 p
38720 p
38720 p
3703 ms
3289 ms
0,0956 ms/p
0,0428 ms/p
3784 ms
3293 ms
0,0977 ms/p
0,0429 ms/p
3659 ms
3320 ms
0,0945 ms/p
0,0432 ms/p
3689 ms
3281 ms
0,0953 ms/p
0,0427 ms/p
3710 ms
3330 ms
0,0958 ms/p
0,0434 ms/p
3732 ms
3301 ms
0,0964 ms/p
0,0430 ms/p
3670 ms
3347 ms
0,0948 ms/p
0,0436 ms/p
3727 ms
3363 ms
0,0963 ms/p
0,0438 ms/p
3703 ms
3332 ms
0,0956 ms/p
0,0434 ms/p
3673 ms
3334 ms
0,0949 ms/p
0,0434 ms/p
3749 ms
3348 ms
0,0968 ms/p
0,0436 ms/p
3718 ms
3294 ms
0,0960 ms/p
0,0429 ms/p
3736 ms
3334 ms
0,0965 ms/p
0,0434 ms/p
3688 ms
3331 ms
0,0952 ms/p
0,0434 ms/p
3664 ms
3337 ms
0,0946 ms/p
0,0435 ms/p
3676 ms
3333 ms
0,0949 ms/p
0,0434 ms/p
3669 ms
3359 ms
0,0948 ms/p
0,0437 ms/p
3690 ms
3329 ms
0,0953 ms/p
0,0433 ms/p
3679 ms
3288 ms
0,0950 ms/p
0,0428 ms/p
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
Qtek S200
750 ms
500 ms
Sony Ericsson
W800i
250 ms
0 ms
1
2
3
4
5
6
7
8
Artihmetisches Mittel
Varianz
Standardabweichung
9 10 11 12 13 14 15 16 17 18 19 20
SE-W800i
3701 ms
1051 ms²
32,42 ms
QTek-S200
3326 ms
687,1 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
Qtek S200
0,0200 ms/p
0,0100 ms/p
Sony Ericsson
W800i
0,0000 ms/p
1
2
3
4
5
6
7
8
Artihmetisches Mittel
Varianz
Standardabweichung
9 10 11 12 13 14 15 16 17 18 19 20
SE-W800i
0,09557 ms
7,012*10-7 ms²/p²
8,374*10-4 ms
QTek-S200
0,04330 ms
1,165*10-7 ms²/p²
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
Durchlauf 1
Durchlauf 2
Durchlauf 3
Durchlauf 4
Durchlauf 5
Durchlauf 6
Durchlauf 7
Durchlauf 8
Durchlauf 9
Durchlauf 10
Durchlauf 11
Durchlauf 12
Durchlauf 13
Durchlauf 14
Durchlauf 15
Durchlauf 16
Durchlauf 17
Durchlauf 18
Durchlauf 19
Durchlauf 20
SE-W800i
QTek-S200
17211 d/s
28011 d/s
16583 d/s
25773 d/s
17699 d/s
25380 d/s
17699 d/s
28985 d/s
17761 d/s
24875 d/s
17793 d/s
25252 d/s
17793 d/s
29254 d/s
17857 d/s
26455 d/s
17761 d/s
27624 d/s
17761 d/s
25974 d/s
17730 d/s
25641 d/s
16778 d/s
27855 d/s
16722 d/s
25706 d/s
17825 d/s
28985 d/s
17761 d/s
28490 d/s
17761 d/s
24691 d/s
17667 d/s
27932 d/s
17761 d/s
26246 d/s
17667 d/s
25839 d/s
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
Qtek S200
5000 d/s
Sony Ericsson
W800i
2500 d/s
0 d/s
1
2
3
4
5
6
7
8
Artihmetisches Mittel
Varianz
Standardabweichung
9
10 11 12 13 14 15 16 17 18 19 20
SE-W800i
17566 d/s
158,85*103 d2/s2
398,56 d/s
QTek-S200
26822 d/s
1289,5*103 d2/s2
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 BytecodeBeschleunigung 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)
Primitives Drawing (Zeit)
(Berechnung: Qtek-S200 / SE-W800i)
152,69%
89,87%
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