Hallo,
gibt es eine Funktion, die Mikrosekunden-Auflösung hat und nicht wie currentTimeMillis() „nur“ Millisekunden?
Besten Dank schon mal im Voraus,
Thomas
Moin
gibt es eine Funktion, die Mikrosekunden-Auflösung hat und
nicht wie currentTimeMillis() „nur“ Millisekunden?
Auszug aus der doc zur currentTimeMillis():
„Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger.“
Das 2. Problem ist Definition von Microsekunde: meinst du damit die Microsekunde in der das System angefangen hat den Befehl zu interpretieren ? Die in der der Wert in der Variable angekommt ?
nächstes Problem: Die Zeitscheiben des OS’es würden da eine zu grosse Rolle spielen.
Ausserdem bräuchte man einen 128 Bit Wert um einen vernüftigen Zeitraum abdecken zu können.
Ausweg:
Es gibt einige Real-time-OSe die die Zeit in Mirko über eine API rausgeben. Wenn du an die API über C und JINI kommen kannst würde das schon gehen. Der Werte wäre allerdings exterm ungenau (Rücksprung aus der API, Rücksprung in java aus JINI).
cu
Hallo,
besten Dank für die Antwort.
„Note that while the unit of time of the return value is a
millisecond, the granularity of the value depends on the
underlying operating system and may be larger.“
Ja, das hab ich auch gesehen, verwendetes OS ist VxWorks 5.4
Das 2. Problem ist Definition von Microsekunde: meinst du
damit die Microsekunde in der das System angefangen hat den
Befehl zu interpretieren ? Die in der der Wert in der Variable
angekommt ?
Gute Frage, hab ich mir noch gar nicht überlegt…soooo genau muß es denn nun auch wieder nicht sein 
Ausweg:
Es gibt einige Real-time-OSe die die Zeit in Mirko über eine
API rausgeben. Wenn du an die API über C und JINI kommen
kannst würde das schon gehen. Der Werte wäre allerdings exterm
ungenau (Rücksprung aus der API, Rücksprung in java aus JINI).
Es geht eben darum, die Geschwindigkeit von Java im Vergleich zu C/C++ zu messen. So wie’s aussieht, werde ich den zu messenden Code einfach 1000x durchlaufen, um zu der „gleichen Genauigkeit bzw. Auflösung“ zu kommen. Wär halt fein gewesen, wenn das anders auch ginge…
Viele Grüße,
Thomas
Moin
Es geht eben darum, die Geschwindigkeit von Java im Vergleich
zu C/C++ zu messen. So wie’s aussieht, werde ich den zu
messenden Code einfach 1000x durchlaufen, um zu der „gleichen
Genauigkeit bzw. Auflösung“ zu kommen.
Mach 10000x oder mehr draus. Oder als es exakt 10 min laufen mit einen Counter.
Da kommt doch gleich mal ein kleines Problem auf: Die Geschwindigkeit von Java hängt von vielem ab, u.a. von der JVM. Wenn die VM unter VxWorks ähnlich arbeitet wie das „Orginal“ von Sun wird dir folgendes auffallen:
-
Das Allokieren von neuen Object (equi. new-construktor) läuft unterschiedlich schnell je nachdem wieviele Objecte gc im Moment im Verdacht hat unnütz zu sein
-
In JINI springen um die Zeit abzufragen kommt bei einem Test nicht in Frage da JINI in der Speicherverwaltung von java Amok läuft. übergibt man z.b. ein 1MB grosses buffer-array „by Reference“ so muss beim 1. Aufruf das array kopiert werden. Bei nachfolgenden Aufrufen nicht mehr, bis gc wieder zuschlägt und irgendwas löscht das älter als der srray ist.
-
Der Startup der JVM bist der erste Code überhaupt geladen wird dauert schon.
-
Der Code wird schneller je öfter er ausgeführt wird (burn-in). Unter windows liegt der Speed-up bei einem Faktor um 40-50, Hot-spot-client vorrausgesetzt. hot-spot-server kommt noch weiter, braucht aber mehr burn-in-Zeit. Nur die Inerpreter-only-VM’s haben den Effekt nicht. Die sind allerdings auch so langsam dass sich messsen nicht lohnt.
Dann gibts noch diverse optionen an der JVM mit denen man spielen kann. Brachte bei mir 75 %.
Wär halt fein gewesen,
wenn das anders auch ginge…
Der Verlust an Zeit für den Aufruf der API den Sprung in C ,… ist zu gross für einen kurzen Benchmark. Für einen langen (> 10 min) lohnt es sich nicht.
cu
Hallo,
Mach 10000x oder mehr draus. Oder als es exakt 10 min laufen
mit einen Counter.
Hab ich gerade bemerkt, daß 1000 grad etwas klein ist…
Da kommt doch gleich mal ein kleines Problem auf: Die
Geschwindigkeit von Java hängt von vielem ab, u.a. von der
JVM. Wenn die VM unter VxWorks ähnlich arbeitet wie das
„Orginal“ von Sun wird dir folgendes auffallen:
Die VM ist eine Real-Time-VM von HP, scheint „ziemlich in Ordnung“ zu sein (die wird mir von meiner Firma für meine Diplomarbeit zur Verfügung gestellt).
- Das Allokieren von neuen Object (equi. new-construktor)
- In JINI springen um die Zeit abzufragen kommt bei einem
Test nicht in Frage da JINI in der Speicherverwaltung von java- Der Startup der JVM bist der erste Code überhaupt geladen
- Der Code wird schneller je öfter er ausgeführt wird
(burn-in). Unter windows liegt der Speed-up bei einem Faktor
Dann gibts noch diverse optionen an der JVM mit denen man
spielen kann. Brachte bei mir 75 %.
uff, so weit bin ich noch gar nicht, immer schön mit der Ruhe
Vielen Dank für die prompten Antworten, wahrscheinlich bis bald,
viele Grüße,
Thomas