2008-08-20T17:00:00+01:00
Applet zum Testen einer gewissen relativen Belastung durch
Java Operationen als Benchmark
{ Inhalte sind randomized }
dieses kleine beispiel zeigt, das man mit java und
der virtuellen maschine (jvm/vm) durchaus einen
performanceanteil der cpu vorher sagen kann
oder die leistung.s.messung bestimmen zu können. durch die umstellung
der architekturen auf mehrkern (dual.core/multi.core)
systeme, wird eine verlagerung und ein neu.design
der software notwendig um den workload zu optimieren.
mit java programmiert man die virtuelle maschine für
aufgabenstellungen mit komplexem anspruch im business.
hier nun ein paar dummy aufgaben für den prozessor
der in einer schleife aufgaben abarbeitet, die teilweise
parallelisiert und im quelltext zu sehen sind.
da der großteil der aufgaben im generieren (secure.random) von zeichen
im zufall generator liegen, wird der zeichensatz
anschließend mit sha1 verschlüsselt,umkopiert und wieder ausgelesen.
ein stress test für die cpu mit einstellbarer schleifenlänge (faktor)
um die anforderung zu variieren und die leistung zu messen .
die tabelle mit den ergebnissen sind richtwerte, die
nach system konfiguration unterschiedlich sind und
kann daher variieren. ein wiederholtes starten kann
die performance verbessern, jedoch wird die systemzeit des
rechners benutzt und das ergebnis kann schwanken.
einzelne thread sowie - multithreading programmierung - wird zwar benutzt
aber wer weiß schon ob es so etwas bringt ?
die entwicklung wird weiter gehen, mal sehen wann wieder zeit ist.
man kann leider auch sehen, das der benchmark in dem jetzigen design
nicht gut skaliert, ich brauche echt landsam ne neue kiste um
multi.thread.programmierung zu lernen.
die verwendete cache.größe bestimmmt massgeblich die
unterschiede unter faktor, die resultierenden ergebnisse
des benchmark sind durch das rechenwerk und die architektur
bestimmt.
als schlussfolgerung kann man sagen, das rechner unter
1000 ops keinen spass machen -.- und auch zum alten
eisen gehören sollten. ich hoffe weiterhin ergebnisse
liefern zu können um das wirrwar der bezeichnungen
ein wenig trennen zu können |o]
die angaben der dualcore prozessoren beziehen sich auf jeweils
eine logische cpu, die angegebenen werten können also doppelt
genommen werden, um die physikalische cpu zu schätzen.
höhere werte, bei geringerem takt, führen sich auf ein
höheren takt des speicherinterfaces oder einen verbesserten
speichercontroller zurück.
die aktuellen klassen wurden nun mit java 1.5 (j2se) kompiliert,
die werte aus der version 1.4.2 sind nun nicht mehr reproduzierbar
und können auf wunsch selbst nachgebaut werden.
es wird deutlich sichtbar, dass die java 1.6 nochmal 50% schneller ist.
durch die hohen ergebnisse der übertaktung ist nun der faktor 8 & 16 eingeführt.
[{( rechner als synonym für computer )}]
der virtuellen maschine (jvm/vm) durchaus einen
performanceanteil der cpu vorher sagen kann
oder die leistung.s.messung bestimmen zu können. durch die umstellung
der architekturen auf mehrkern (dual.core/multi.core)
systeme, wird eine verlagerung und ein neu.design
der software notwendig um den workload zu optimieren.
mit java programmiert man die virtuelle maschine für
aufgabenstellungen mit komplexem anspruch im business.
hier nun ein paar dummy aufgaben für den prozessor
der in einer schleife aufgaben abarbeitet, die teilweise
parallelisiert und im quelltext zu sehen sind.
da der großteil der aufgaben im generieren (secure.random) von zeichen
im zufall generator liegen, wird der zeichensatz
anschließend mit sha1 verschlüsselt,umkopiert und wieder ausgelesen.
ein stress test für die cpu mit einstellbarer schleifenlänge (faktor)
um die anforderung zu variieren und die leistung zu messen .
die tabelle mit den ergebnissen sind richtwerte, die
nach system konfiguration unterschiedlich sind und
kann daher variieren. ein wiederholtes starten kann
die performance verbessern, jedoch wird die systemzeit des
rechners benutzt und das ergebnis kann schwanken.
einzelne thread sowie - multithreading programmierung - wird zwar benutzt
aber wer weiß schon ob es so etwas bringt ?
die entwicklung wird weiter gehen, mal sehen wann wieder zeit ist.
man kann leider auch sehen, das der benchmark in dem jetzigen design
nicht gut skaliert, ich brauche echt landsam ne neue kiste um
multi.thread.programmierung zu lernen.
die verwendete cache.größe bestimmmt massgeblich die
unterschiede unter faktor, die resultierenden ergebnisse
des benchmark sind durch das rechenwerk und die architektur
bestimmt.
als schlussfolgerung kann man sagen, das rechner unter
1000 ops keinen spass machen -.- und auch zum alten
eisen gehören sollten. ich hoffe weiterhin ergebnisse
liefern zu können um das wirrwar der bezeichnungen
ein wenig trennen zu können |o]
die angaben der dualcore prozessoren beziehen sich auf jeweils
eine logische cpu, die angegebenen werten können also doppelt
genommen werden, um die physikalische cpu zu schätzen.
höhere werte, bei geringerem takt, führen sich auf ein
höheren takt des speicherinterfaces oder einen verbesserten
speichercontroller zurück.
die aktuellen klassen wurden nun mit java 1.5 (j2se) kompiliert,
die werte aus der version 1.4.2 sind nun nicht mehr reproduzierbar
und können auf wunsch selbst nachgebaut werden.
es wird deutlich sichtbar, dass die java 1.6 nochmal 50% schneller ist.
durch die hohen ergebnisse der übertaktung ist nun der faktor 8 & 16 eingeführt.
[{( rechner als synonym für computer )}]
2.6.17.13-kanotix-2 |
||||||||||
| 1MB = 1024kB | 1kB = 1024 Byte |
die testergebnisse für den/der/die/das Java.Performance.Test.Applet.class v.0.43
die verwendete messgrösse / maßzahl (spec/specs) ist synthetisch und von der jeweiligen java vm abhängig
ich suche noch ergebnisse für: solaris | ultra.sparc | niagara | T1 | T2 | opteron | barcelona | phenom | power.pc | xbox | ps3 | exotic.machines
weitere testergebnisse bitte an markus.schulz[at]maniac-capacity[dot]de schicken
Java.Performance.Test.Applet.java (source)
Java.Performance.Test.Applet.txt (quelltext)
try mandelbrot fractal
