Lust auf einen kleinen Rechner-Test (Java)?
-
Test V 0.01 Sum32 Test...best time is 890 ms Sum64 Test...best time is 3078 ms Mem Test...best time is 1437 msIntel C2D E6600 @ 2,4 GHz, 2GB DDR2 @ 800
Unter XP 32bit und Java 1.6.0_03-b05PS: CPU war aber nur zu 51% ausgelastet. Wieso das?
-
LeGaN schrieb:
PS: CPU war aber nur zu 51% ausgelastet. Wieso das?
Du weißt schon, dass du eine CPU mit 2 Kernen hast?
Das Programm hat nur einen Thread und der kann nur auf einem Kern laufen => ~50% Gesamtauslastung.
-
LeGaN schrieb:
PS: CPU war aber nur zu 51% ausgelastet. Wieso das?
Weil du ein Dual Core hast ...
-
robot schrieb:
Ich kann Dir ein paar Zeilen für eine Batch-Datei anbieten
javac Test.java
java Test >> results.txt
pauseWers Ergebnis dirket sehen will lässt ">> results.txt" weg.
Achja, habe es hier mit JRE 1.5.0 getestet.
Ich habe kein Java SDK.
-
this->that schrieb:
Ich habe kein Java SDK.
Aber wenn hier wildfremde Leute Executables hochladen, führst Du sie aus?
Test V 0.01 Sum32 Test...best time is 5593 ms Sum64 Test...best time is 36139 ms Mem Test...best time is 14799 ms866MHz G4, 640MB RAM.
-
nman schrieb:
Aber wenn hier wildfremde Leute Executables hochladen, führst Du sie aus?
Da ich den Thread kenne und die Gefahr einigermaßen einschätzen kann: Ja.
-
Wie willst Du die Gefahr einschätzen können, wenn Du die Executable bekommst? Was hindert uns daran, da irgendwo einen recursiveDeleteRootDir()-Aufruf reinzupacken? (Oder führst Du sowas in einer Sandbox aus?)
-
schirrmie schrieb:
LeGaN schrieb:
PS: CPU war aber nur zu 51% ausgelastet. Wieso das?
Weil du ein Dual Core hast ...
Das ist mir klar. Ich meinte auch, 51% auf _einem_ Kern.
-
nman schrieb:
Wie willst Du die Gefahr einschätzen können, wenn Du die Executable bekommst? Was hindert uns daran, da irgendwo einen recursiveDeleteRootDir()-Aufruf reinzupacken? (Oder führst Du sowas in einer Sandbox aus?)
Ganz einfach: Ich gehe davon aus, dass robot kein gemeiner Sack ist und jetzt extra für mich einen Virus schreibt und den dann anstelle seines Benchmarks hochlädt.
-
LeGaN schrieb:
schirrmie schrieb:
LeGaN schrieb:
PS: CPU war aber nur zu 51% ausgelastet. Wieso das?
Weil du ein Dual Core hast ...
Das ist mir klar. Ich meinte auch, 51% auf _einem_ Kern.
Ich habs grad nochmal laufen lassen. Nun ist wies es soll auf einem Kern 100%, auf dem andrem nüscht. Nach ein paar weiteren Male kam wieder das vor, dass auf einem Kern nicht die vollen 100% waren. Der Teil, der auf dem einen bis zu den 100% gefehlt haben, waren auf dem anderen Kern zu sehen. Zeigt da der Taskmanager was falsch an, oder trickst da die VM etwas rum?
-
Damit die Multi-Core Besitzer auch auf ihre Kosten kommen, habe ich noch einen Test mit Threads eingebaut (siehe erstes Posting).
@this->that: Wenn Du mir sagst, wo ich die Files uploaden kann, ohne viel Aufwand zu haben (Zwangsregistrierung, Werbe-Schrott, ...), dann lad ich das auch gerne hoch. Ansonsten schnell das SDK installieren, sonst kommst Du nicht in den (J)Himmel
: http://java.sun.com/javase/downloads/?intcmp=1281
-
... oder im Weltnetz übersetzen lassen:
http://www.innovation.ch/java/java_compile.html
hab "Optimize" und 1.5.0 eingestellt.
Ergebnisse auf einem AthlonX2 4200+
Test V 0.02 Test loops: 5
Sum32 Test... best time: 1828 ms
Sum64 Test... best time: 4484 ms
Sum64 Test using 10 Threads... best time: 2390 ms
RAM Test... best time: 2125 ms
Prim Test (SOE)... best time: 8281 msDurchlauf Nr. 2:
Test V 0.02 Test loops: 5
Sum32 Test... best time: 1828 ms
Sum64 Test... best time: 4813 ms
Sum64 Test using 10 Threads... best time: 2547 ms
RAM Test... best time: 2172 ms
Prim Test (SOE)... best time: 8188 msWobei da nischt mit Multiprozessor uns so zu merken ist, das Ganze läuft auf einem Kern mit 100%
-
Intel P4 @ 3 Ghz:
Sum32 Test... best time: 1031 ms Sum64 Test... best time: 4125 ms Sum64 Test using 10 Threads... best time: 4781 ms RAM Test... best time: 4499 ms Prim Test (SOE)... best time: 9390 msSo Leute und jetzt portieren wir das Ding auf C++ und gucken welche Sprache besser ist
Bitte beachten sie die Sicherheitslinie. Betreten der Zone auf eigenes Risiko!
-----------------------------------
you are entering the flamewars zone
-
Intel C2D @ 3,33GHz, Vista 64, erstellt mit dem Webcompiledingens mit gleichen Einstellungen wie F98.
Sum32 Test... best time: 639 ms Sum64 Test... best time: 2315 ms Sum64 Test using 10 Threads... best time: 1123 ms RAM Test... best time: 1184 ms Prim Test (SOE)... best time: 2162 ms
-
F98 schrieb:
... oder im Weltnetz übersetzen lassen:
Ah, Danke für den Tipp.
F98 schrieb:
Wobei da nischt mit Multiprozessor uns so zu merken ist, das Ganze läuft auf einem Kern mit 100%
Ja, nutzt auch alles nur einen Thread, bis auf den "Sum64 Test using 10 Threads". Dort werden bis zu 10 Kerne genutzt. Das siehst Du auch daran, dass auf Deinem X2 der Sum64 mit 10 Threads fast doppelt so schnell ist wie der Sum64 Test ohne Threads.
Cpp_Junky schrieb:
So Leute und jetzt portieren wir das Ding auf C++ und gucken welche Sprache besser ist
Hab es mal fix umgematscht und mit dem VC++ kompiliert (Datentyp __int64 für sum64). Die Ergebnisse beim Rechnen sind etwa um den Faktor 1,1 - 1,8 schneller. Der RAM Test war fast exakt gleich schnell wie unter Java (ohne speziell optimierten Code, einfach nur so wie in Java gelassen). Ich finde es aber trotzdem interessanter den Test unter Java mit der JVM zu machen, da dies (bei gleicher Version) einheitlichere Ergebnisse liefert. Die C++ Ergebnisse sind sicher stark vom jeweiligen Kompiler + Einstellungen abhängig. Wenn wer unbedingt will, kann ich den Code ja trotzdem mal posten.
-
16:20:37 mastercpp@chi ~ % javac -O JBench.java 16:20:46 mastercpp@chi ~ % java JBench JBench V 0.02 Test loops: 5 Sum32 Test... best time: 0 ms Sum64 Test... best time: 1280 ms Sum64 Test using 10 Threads... best time: 1729 ms RAM Test... best time: 1854 ms Prim Test (SOE)... best time: 5103 ms16:21:51 mastercpp@chi ~ % gcj -O3 --main=JBench JBench.java 16:22:03 mastercpp@chi ~ % ./a.out JBench V 0.02 Test loops: 5 Sum32 Test... best time: 0 ms Sum64 Test... best time: 0 ms Sum64 Test using 10 Threads... best time: 865 ms RAM Test... best time: 1941 ms Prim Test (SOE)... best time: 5495 ms16:24:51 mastercpp@chi ~ % java -version java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)16:24:55 mastercpp@chi ~ % gcj --version gcj (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.0 ms?
-
mastercpp schrieb:
16:20:37 mastercpp@chi ~ % javac -O JBench.java 16:20:46 mastercpp@chi ~ % java JBench JBench V 0.02 Test loops: 5 Sum32 Test... best time: 0 ms Sum64 Test... best time: 1280 ms Sum64 Test using 10 Threads... best time: 1729 ms RAM Test... best time: 1854 ms Prim Test (SOE)... best time: 5103 ms0 ms?
Das mit dem 0 ms ist mir unter Java auch noch nicht passiert. Ich vermute, dass die aktuelle Version von javac das kaputt optimiert, weil er merkt, dass das Ergebnis (sum) nicht weiter verwertet wird. Dass er so schlau ist und die Summenformel sum = (max+1)*max/2 anwendet kann ich mir noch nicht vorstellen.
Ich hab das Ergebnis mal einer Membervariablen zugewiesen, so dass er eigentlich zum Ausführen der Schleife gezwungen sein müsste. Kannst Dus evtl. nochmal testen? (siehe erstes Posting)
-
@robot: Hol Dir mal ein aktuelles JDK und vergleiche Deine Java 5 Ergebnisse damit. Die behaupten doch tatsächlich schon wieder, dass das aktuelle Java 6 teilweise schneller als Java 5 sein soll:
http://java.sun.com/performance/reference/whitepapers/6_performance.html
-
Unglaublich. Die Ergebnisse von Java 1.6.0_03 im Vergleich zu Java 1.5.0 sind tatsächlich deutlich besser:
Auf Intel Pentium M 1500 MHz
Sum32 Test... 73% schneller Sum64 Test... 26% schneller Sum64 Test using 10 Threads... 37% schneller Sum64 Double Test... 54% schneller RAM Test... 6% schneller Prim Test (SOE)... 24% schneller
-
robot schrieb:
Das mit dem 0 ms ist mir unter Java auch noch nicht passiert. Ich vermute, dass die aktuelle Version von javac das kaputt optimiert, weil er merkt, dass das Ergebnis (sum) nicht weiter verwertet wird. Dass er so schlau ist und die Summenformel sum = (max+1)*max/2 anwendet kann ich mir noch nicht vorstellen.
Ich hab das Ergebnis mal einer Membervariablen zugewiesen, so dass er eigentlich zum Ausführen der Schleife gezwungen sein müsste. Kannst Dus evtl. nochmal testen? (siehe erstes Posting)
21:16:33 mastercpp@chi ~ % javac -O JBench.java 21:17:37 mastercpp@chi ~ % java JBench JBench V 0.022 Test loops: 1 Sum32 Test... best time: 1207 ms Sum64 Test... best time: 3063 ms Sum64 Test using 10 Threads... best time: 1918 ms Sum64 Double Test... best time: 7770 ms RAM Test... best time: 1946 ms Prim Test (SOE)... best time: 4942 ms21:18:08 mastercpp@chi ~ % gcj -O3 --main=JBench JBench.java 21:19:46 mastercpp@chi ~ % ./a.out JBench V 0.022 Test loops: 1 Sum32 Test... best time: 1905 ms Sum64 Test... best time: 0 ms Sum64 Test using 10 Threads... best time: 865 ms Sum64 Double Test... best time: 2615 ms RAM Test... best time: 2082 ms Prim Test (SOE)... best time: 6099 msThreading und das Rechnen mit Doubles scheint in der VM nicht ganz so effizient zu sein. Bei Integern ist die VM hingegen schneller.