Discussion:
[LANG] Benchmark von Java, C#, Delphi und C++ in der c't
(zu alt für eine Antwort)
Marco Schmidt
2003-09-06 16:40:55 UTC
Permalink
Ich wollte mal auf den Artikel in der aktuellen c't aufmerksam machen.
Hab ich auch gerade gelesen... Ob hier übrigens einige der Verfasser
der "empörten Leserbriefe der Fangemeinde" mitlesen?! :)

[...]
Für Java wurden die Micro-Benchmarks zum Verhängnis (allerdings nicht
wirklich schlimm). C++ liegt bei den "einfachen" Schleifen immer bei 0
Sekunden (und damit disqualifiziert sich der Test sofort, weil der
schnellste Kandidat immer eine messbare Zeit haben muß - Vergleiche
sind sonst Humbug).
Man hätte statt <= 1000 einfach <= $VARIABLE nehmen sollen und
$VARIABLE über einen Kommandozeilenparameter setzen, oder sowas
Ähnliches, um das Vorberechnen zu verhindern. Kann ja nicht so schwer
sein. :/

[...]
Java wurde nicht die Warmlaufpase für Hotspot gegeben. Das finde ich
für *so* einen Vergleich in Ordnung, halte aber die daraus entstehende
Aussage für Praxisfern. Aber da erzähle ich sicherlich niemanden was
Neues.
Bei einem "arraylastigen" Test hätte Java wahrscheinlich eher
abgestunken.

Zum Vergleich hätte man neben den OOP-Sprachen doch auch mal reines C
verwenden können. Der OOP-Charakter der Sprachen kam ohnehin nirgends
zum Tragen...

[...]

Gruß,
Marco
--
Bitte nur in der Newsgroup antworten, nicht per Email!
de.comp.lang.java Homepage: http://www.dclj.de/
FAQ: http://www.faqs.org/faqs/de/comp-lang-java/faq/
Meine Java-Seiten: http://www.geocities.com/marcoschmidt.geo/java.html
Aljoscha Rittner
2003-09-06 17:00:53 UTC
Permalink
[...]
Post by Marco Schmidt
Java wurde nicht die Warmlaufpase für Hotspot gegeben. Das finde ich
für *so* einen Vergleich in Ordnung, halte aber die daraus entstehende
Aussage für Praxisfern. Aber da erzähle ich sicherlich niemanden was
Neues.
Bei einem "arraylastigen" Test hätte Java wahrscheinlich eher
abgestunken.
Das sehe ich ähnlich. Arrays sind in Java ein Schwachpunkt, wenn man
nur den Performance-Punkt betrachtet. Allerdings gibt es in Java auch
keine Bufferoverflows ;-)
Post by Marco Schmidt
Zum Vergleich hätte man neben den OOP-Sprachen doch auch mal reines C
verwenden können. Der OOP-Charakter der Sprachen kam ohnehin nirgends
zum Tragen...
[...]
Lies nochmal das Abschlußwort, im nächsten Teil wird OOP verglichen.
Und C++ soll wohl recht übel dastehen.

Gruß,
Josch.
--
Weizenbier lässt sich leichter einschenken, wenn Sie statt Reis ein
kleines Seifestück ins Glas tun.
[Haushaltstips - für den nächsten Tip eine Antwort provozieren...]
Sven Köhler
2003-09-06 20:02:40 UTC
Permalink
Hat denn C# keine kontrollmechanismen was Arrays angeht? Oder gibt es
bei C# wieder Bufferoverflows?
In "Unsave Code" Blöcken darfst du alles machen.
Na gut, dann geht's ja noch.
Und diese Blöcke muss ich dann deklarieren, ja?
Aljoscha Rittner
2003-09-06 20:58:57 UTC
Permalink
Post by Sven Köhler
Hat denn C# keine kontrollmechanismen was Arrays angeht? Oder gibt es
bei C# wieder Bufferoverflows?
In "Unsave Code" Blöcken darfst du alles machen.
Na gut, dann geht's ja noch.
Und diese Blöcke muss ich dann deklarieren, ja?
Jepp. Und damit wird das Programm nur unter speziellen
"Konfigurationen" lauffähig. Zum Beispiel durch Zertifikate,
Installation ausschließlich durch Administrator Account und/oder so
weiter.

Gruß,
Josch.
--
... und ich haette da noch 600MB freien Festplattenspeicher auf CD
gebrannt,
natuerlich wenig benutzt und superschnell.
Daniel in goe.kleinanzeigen.allgemein
Marco Schmidt
2003-09-07 03:52:44 UTC
Permalink
Aljoscha Rittner:

[...]
Post by Aljoscha Rittner
Lies nochmal das Abschlußwort, im nächsten Teil wird OOP verglichen.
Und C++ soll wohl recht übel dastehen.
Ich meine auch nur für den aktuellen Teil. Als Vergleich. Gerne auch
noch eine Version in Assembler dazu.

Gruß,
Marco
--
Bitte nur in der Newsgroup antworten, nicht per Email!
de.comp.lang.java Homepage: http://www.dclj.de/
FAQ: http://www.faqs.org/faqs/de/comp-lang-java/faq/
Meine Java-Seiten: http://www.geocities.com/marcoschmidt.geo/java.html
Johann Burkard
2003-09-06 19:49:23 UTC
Permalink
Post by Marco Schmidt
Hab ich auch gerade gelesen... Ob hier übrigens einige der
Verfasser der "empörten Leserbriefe der Fangemeinde"
mitlesen?! :)
Arne Schäpers Behauptung, es gäbe keine großen Java-Programme,
ist angesichts z.B. Eclipse auch etwas denkgebremst.

Johann
--
dieses fuckin beschissene dreckspostin gehört nicht in diese
newsgroup
!!!!!
("a. bach" in <at1a4c$us4g5$***@ID-168860.news.dfncis.de>)
Sven Köhler
2003-09-06 19:50:31 UTC
Permalink
Post by Johann Burkard
Post by Marco Schmidt
Hab ich auch gerade gelesen... Ob hier übrigens einige der
Verfasser der "empörten Leserbriefe der Fangemeinde"
mitlesen?! :)
Arne Schäpers Behauptung, es gäbe keine großen Java-Programme,
ist angesichts z.B. Eclipse auch etwas denkgebremst.
Hatten wie Diskussion nicht schonmal bei einem anderen Artikel von Arne
Schäpers?
Es wurden unzählige Beispiele aufgezählt. Hat Arne denn Gründe genannt?
Oder war dieses Statement einfach nur so aus der Luft gegriffen?

Genausogut könnte ich hier sagen, dass es keine großen Programme in C
geben kann, da ein Modul sich nicht gegen die Schwächen des anderen
absichern kann (seg-fault etc.) und trotzdem gibt es Mozilla, gnome usw.
Lothar Kimmeringer
2003-09-06 21:35:16 UTC
Permalink
Im Artikel wird es an der Stelle interessant, wo dieser Satz
auftaucht: "Als erstes Beispiel für eine halbwegs reale
Problemstellung..." - es geht um eine Entschlüsselung von RSA als
Numbercruncher und in einer rekursiven Variante.
Interessant auch, dass die allen Ernstes behaupten, dass
bei SSL RSA-Schluessel der Laenge 128 Bit verwendet werden.
Da haben die wohl symmetrischer mit asymmetrischer Ver-
schluesselung verwechselt.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Tor-Einar Jarnbjo
2003-09-07 12:39:12 UTC
Permalink
Java wurde nicht die Warmlaufpase für Hotspot gegeben. Das finde ich
für *so* einen Vergleich in Ordnung, halte aber die daraus entstehende
Aussage für Praxisfern. Aber da erzähle ich sicherlich niemanden was
Neues.
Naja, es dauert ja nicht lange bis der Java-Code so oft interpretiert
wurde, dass die VM sich entscheiden den HotSpot einzuschalten, was bei so
wenig Code auch nicht lange dauern wird. Ich habe die Brute-Force-Methode
hier fünf mal Laufen lassen und die Laufzeiten waren:

34,3s, 27,6s, 27,5s, 27,1s, 27,1s

Gut, der zweite Durchlauf war in diesem Fall 20% schneller. Ich habe aber
den Java-Code ein Bisschen optimiert (d.h. eine gewaltige,
offensichtliche Laufzeitbremse ausgebaut und nicht bei jedem Durchlauf
der Schleife die Wurzel von NumberToCrunch neu berechnen lasse) und komme
mit meiner Variante auf folgende Zeiten:

17,3s, 17,8s. 17,8s, 18,1s, 18,3s

Ich war dann neugierig wie die gleiche Optimierung die Laufzeit von dem
C-Programm beeinflüssen wurde, und die Ergebnisse haben mich schon
überrascht. Ich habe hier zwar nur die kostenlose Ausgabe von Borlands
C++-Compiler v5.5.1 (von Jahr 2000), aber das C-Programm hat sowohl mit
als auch ohne meine Optimierung 150 Sekunden gebraucht. Der C-Compiler
wird wahrscheinlich meine Änderung sowieso wegoptimieren. Zusätzliche
Compiler-Optimierungen einzuschalten hat übrigens auch nichts gebracht.

Gruß, Tor
Aljoscha Rittner
2003-09-07 13:48:44 UTC
Permalink
[...]
Post by Tor-Einar Jarnbjo
Gut, der zweite Durchlauf war in diesem Fall 20% schneller. Ich habe aber
den Java-Code ein Bisschen optimiert (d.h. eine gewaltige,
offensichtliche Laufzeitbremse ausgebaut und nicht bei jedem Durchlauf
der Schleife die Wurzel von NumberToCrunch neu berechnen lasse) und komme
17,3s, 17,8s. 17,8s, 18,1s, 18,3s
Das ist schon nett, war mir übrigens nicht aufgefallen. Dabei ist der
Unsinn ziemlich offensichtlich. Allerdings wäre es auch gefundenes
Fressen für HotSpot gewesen. Zumindest häte ich es jetzt erwartet...
Sollte der Parameter als "final long numberToCrunch" nicht Hotspot
animieren können?
Bringt nix. Da ich einen Athlon mit 1GHz habe und ziemlich genau die
Zeiten nachvollziehen kann, habe ich für BruteForce (mit fünf
Durchläufen) als Durchschnitt 13 Sekunden und 353ms anzubieten.
Natürlich mit dem Substituieren der Wurzel.

@Tor-Einar
Damit liegt man mit Java nur wirklich sehr knapp hinter C++ (12
Sekunden), wenn ich davon ausgehe, dass der C++ Compiler selbst
optimiert (wie du es schon mit dem Borland-Compiler beobachtet hast).

Ich habe leider keinen C++ Compiler hier am laufen...

Gruß,
Josch.
--
Volle Abfallsäcke erkennen sie daran, daß sich der Abfallkübel nicht
mehr schließen läßt und der Hauswart stündlich nach Todesfällen im Haus
fragt. Abhilfe schaffen sie, indem sie den Müll in den Kühlschrank werfen.
[Haushaltstips - für den nächsten Tip eine Antwort provozieren...]
Tor-Einar Jarnbjo
2003-09-07 15:54:16 UTC
Permalink
Sollte der Parameter als "final long numberToCrunch" nicht Hotspot
animieren können?
Wäre möglich. Aber woher soll Hotspot wissen, dass die Math.sqrt-Methode
deterministisch ist, also bei jedem Aufruf mit dem gleichen Parameter den
gleichen Rückgabewert hat.

Gruß, Tor
Aljoscha Rittner
2003-09-07 16:25:22 UTC
Permalink
Post by Tor-Einar Jarnbjo
Sollte der Parameter als "final long numberToCrunch" nicht Hotspot
animieren können?
Wäre möglich. Aber woher soll Hotspot wissen, dass die Math.sqrt-Methode
deterministisch ist, also bei jedem Aufruf mit dem gleichen Parameter den
gleichen Rückgabewert hat.
Weil es eine Lang-Methode und static ist ;-) - sprich der Hersteller
selbst. Warum nicht einen Bibliothek von solchen Hinweisen?

Gruß,
Josch.
--
Hähnchen bleiben besonders lange frisch, wenn man sie Leben läßt.
[Haushaltstips - für den nächsten Tip eine Antwort provozieren...]
Tor-Einar Jarnbjo
2003-09-07 16:30:33 UTC
Permalink
Post by Aljoscha Rittner
Weil es eine Lang-Methode und static ist ;-) - sprich der Hersteller
selbst. Warum nicht einen Bibliothek von solchen Hinweisen?
Hmm, ich muss gerade überlegen ob die Methode wirklich deterministisch ist?
Die API-Dokumentation gestattet ja der Math-Klasse einige Freiheiten, um
eine bessere Performance zu erreichen, genau rechnet nur die StrictMath-
Klasse.

Gruß, Tor
Paul Ebermann
2003-09-07 21:31:15 UTC
Permalink
Post by Tor-Einar Jarnbjo
Post by Aljoscha Rittner
Weil es eine Lang-Methode und static ist ;-) - sprich der Hersteller
selbst. Warum nicht einen Bibliothek von solchen Hinweisen?
Hmm, ich muss gerade überlegen ob die Methode wirklich deterministisch ist?
Die API-Dokumentation gestattet ja der Math-Klasse einige Freiheiten, um
eine bessere Performance zu erreichen, genau rechnet nur die StrictMath-
Klasse.
Klar - aber der Hersteller der Klasse ist doch der
selbe wie der Hersteller des Hotspot. Da könnte man
sich doch verabreden :-)


Paul
Tor-Einar Jarnbjo
2003-09-07 21:55:10 UTC
Permalink
Post by Paul Ebermann
Klar - aber der Hersteller der Klasse ist doch der
selbe wie der Hersteller des Hotspot. Da könnte man
sich doch verabreden :-)
Du erwartest, dass zwei Abteilungen bei einer großen Firma sich miteinander
über sowas unterhalten können? Das halte ich für ein Gerücht :)

Ich hatte übrigens ein paar Reaktionen darauf erwartet, dass die uralte
Microsoft-VM immer noch schneller ist als aktuelle Hotspot-VMs von Sun.

Gruß, Tor
Lothar Kimmeringer
2003-09-08 00:53:40 UTC
Permalink
Post by Tor-Einar Jarnbjo
Ich hatte übrigens ein paar Reaktionen darauf erwartet, dass die uralte
Microsoft-VM immer noch schneller ist als aktuelle Hotspot-VMs von Sun.
Hat mich eigentlich nicht gewundert, da die wahrscheinlich immer
noch tiefer ins System reingreift, als die aktuellen VMs.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Tor-Einar Jarnbjo
2003-09-08 07:03:49 UTC
Permalink
Post by Lothar Kimmeringer
Hat mich eigentlich nicht gewundert, da die wahrscheinlich immer
noch tiefer ins System reingreift, als die aktuellen VMs.
Was meinst du damit, dass eine VM "tiefer ins System reingreift?"

Tor
michael paap
2003-09-08 15:24:50 UTC
Permalink
Post by Tor-Einar Jarnbjo
Was meinst du damit, dass eine VM "tiefer ins System reingreift?"
Das weiß er selbst nicht; hört sich nur nach Kenntnis an.
Und was qualifiziert Dich halbanonymes Wesen zu dieser Aussage über Lothar?

Michael, sich fragend, ob der Verein der anonymen Trolloholiker derzeit
mal wieder Öffentlichkeitsarbeit betreibt.
--
Sollte ausnahmsweise eine Mail-Antwort auf ein Posting vonnöten sein,
bitte folgende Adresse verwenden: newsreply@<Absender-Domain>.
michael paap
2003-09-09 03:21:30 UTC
Permalink
Naja, fachlich hat Oliver meiner Meinung nach schon recht.
Wenn Du "fachlich recht haben" so definierst, dass er keine falsche
fachliche Aussage getroffen hat, dann vielleicht. Ich kann nämlich in
"Das weiß er selbst nicht; hört sich nur nach Kenntnis an." beim besten
Willen nicht die geringste fachliche Aussage erkennen.

Gruß,
Michael
--
Sollte ausnahmsweise eine Mail-Antwort auf ein Posting vonnöten sein,
bitte folgende Adresse verwenden: newsreply@<Absender-Domain>.
Lothar Kimmeringer
2003-09-08 16:33:45 UTC
Permalink
Post by Tor-Einar Jarnbjo
Post by Lothar Kimmeringer
Hat mich eigentlich nicht gewundert, da die wahrscheinlich immer
noch tiefer ins System reingreift, als die aktuellen VMs.
Was meinst du damit, dass eine VM "tiefer ins System reingreift?"
Hab auch gerade festgestellt, dass das bloed ausgedrueckt war.
"Eingebettet" wuerde wohl besser passen. IMHO nutzt jview
die vom Betriebssystem angebotenen nativen Funktionalitaeten
exzessiver, als dies die Standard-JVMs auch heute noch tun
(die setzen ja inzwischen mehr auf den Hotspot). Wenn ich
das richtig in den neueren JVMs gesehen habe, wird sogar mehr
Code, der frueher native ausgefuehrt wurde (z.B. die BigInteger-
Rechenoperationen) inzwischen in Java implementiert.

Somit duerfte eine JVM, die direkt die BS-DLLs nutzt bei solchen
Standardsachen, wie diesem Benchmarktest immer noch mit im Rennen
bleiben.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Tor-Einar Jarnbjo
2003-09-08 18:21:54 UTC
Permalink
Post by Lothar Kimmeringer
Somit duerfte eine JVM, die direkt die BS-DLLs nutzt bei solchen
Standardsachen, wie diesem Benchmarktest immer noch mit im Rennen
bleiben.
Und dir ist klar, worum es bei dem Benchmark überhaupt geht? Es ist eine
Schleife wie diese:

long i=...;
long j=...;

for(long k=3; k<j; k+=2) {
if(i%k==0) {
System.out.println(j+" * "+k+" = "+i);
}
}

Die Schleife läuft etwa 2^31 Mal durch und die if-Bedingung trifft drei Mal
zu. Die Konsolenausgabe ist also nicht relevant.

Jetzt darfst du mir gerne erzählen welche undokumentierte Windows-DLL die
Modulo-Berechnung schneller ausführt als wie auch immer Sun das Problem
gelöst hat.

Gruß, Tor
Lothar Kimmeringer
2003-09-08 19:25:25 UTC
Permalink
Post by Tor-Einar Jarnbjo
Und dir ist klar, worum es bei dem Benchmark überhaupt geht? Es ist eine
long i=...;
long j=...;
for(long k=3; k<j; k+=2) {
if(i%k==0) {
System.out.println(j+" * "+k+" = "+i);
}
}
Wobei j in einem Fall ein Methodenaufruf ist, der bei jview
wahrscheinlich direkt ueber einen entsprechenden DLL-Aufruf
stattfindet.
Post by Tor-Einar Jarnbjo
Die Schleife läuft etwa 2^31 Mal durch und die if-Bedingung trifft drei Mal
zu. Die Konsolenausgabe ist also nicht relevant.
Jetzt darfst du mir gerne erzählen welche undokumentierte Windows-DLL die
Modulo-Berechnung schneller ausführt als wie auch immer Sun das Problem
gelöst hat.
Von undokumentierten DLL-Zugriffen habe ich nicht geredet, ich
gehe nur davon aus, dass in jview der Uebergang von Java auf
die entsprechenden nativen Aufrufe nicht ueber JNI, sondern
anders geloest wurde (zumindest bei den im Standard vorhandenen
Sachen, wie eben die mathematischen Geschichten), so dass dort
kein Bottleneck auftritt, wie es beim SUN JDK 1.1 ja bei JNI
gegeben war.

Dass jview bei der Schleife mit konstantem j ebenfalls schneller
ist, mag (vielleicht - so tief habe ich nicht reingeschaut) daher
kommen, dass dieser die Zaehlvariablen gleich in die Register
packt waehrend die SUN VMs da anfangs erst auf dem Stack herum-
wurschteln.

Wie gesagt, meine Aussage bezueglich des tiefer-eingebettet-
seins bezog sich auf die offensive Nutzung bestehender nativer
Funktionen in Windows per DLL (ganz offiziell ueber die
dokumentierten Schnittstellen, an Verschwoerungen glaube ich
da nicht ;-) was den VMs, die fuer mehrere Plattformen konzipiert
wurden, im Prinzip verwehrt ist (oder man programmiert eine
VM nur fuer Windows und eine fuer die anderen Plattformen).


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Lothar Kimmeringer
2003-09-08 21:54:26 UTC
Permalink
Post by Lothar Kimmeringer
Wobei j in einem Fall ein Methodenaufruf ist, der bei jview
wahrscheinlich direkt ueber einen entsprechenden DLL-Aufruf
stattfindet.
Ja, es wird einmalig die Quadratwurzel einer zahl berechnet.
Das war Deine optimierte Version. Ich bezog mich da auf
Deinen "unoptimierten" Test, bei dem der sqrt-Aufruf in
der for-Schleife noch enthalten war.
Post by Lothar Kimmeringer
Von undokumentierten DLL-Zugriffen habe ich nicht geredet, ich
gehe nur davon aus, dass in jview der Uebergang von Java auf
die entsprechenden nativen Aufrufe nicht ueber JNI, sondern
anders geloest wurde (zumindest bei den im Standard vorhandenen
Sachen, wie eben die mathematischen Geschichten), so dass dort
kein Bottleneck auftritt, wie es beim SUN JDK 1.1 ja bei JNI
gegeben war.
Es werden weder Methodenaufrufe per JNI noch irgendwelche solche
Übergänge gemessen. Um an die gemessene Geschwindigkeit überhaupt zu
kommen, muss unbedingt eine komplette Übersetzung schon erfolgt sein und
was abläuft ist nur Maschinencode, der schon vom JIT oder Hotspot erzeugt
wurde.
Hat nichts mit dem vorliegenden Fall zu tun, aber auch bei kompletter
Uebersetzung in Maschinencode duerfte es bei einem Uebergang von
Java zu native ueber JNI zu Zeitverlusten fuehren, weil immer noch
Umwandlungen der verwendeten Datentypen vorgenommen werden muessten.
Eine Iteration der Schleife braucht bei mir nur 45 Prozessortakte
und mit Microsofts VM ist das Java-Programm sogar schneller als das C-
Programm mit Suns VM nur knapp dahinter. Wieso kommst du darauf, dass
hier JNI für das Ergebnis relevant sein kann?
Das mit dem nativen Code war auf die Wurzelberechnung bezogen
(den Fall, dass sie noch in der Schleife mit drin ist vorausgesetzt).
jview mag da eine Windows-DLL ohne den Standard-JNI-Weg direkt
aufrufen, waehrend bei einer "normalen" VM das ganze im Bytecode
vorliegt. Eben weil kein JNI bei jview beteiligt ist, kann es daher
sein, dass die Ausfuehrung letzten Endes immer noch in vergleich-
barer Geschwindigkeit wie bei modernen VMs mit hochgezuechteten
Hotspots ablaeuft.
Post by Lothar Kimmeringer
Dass jview bei der Schleife mit konstantem j ebenfalls schneller
ist, mag (vielleicht - so tief habe ich nicht reingeschaut) daher
kommen, dass dieser die Zaehlvariablen gleich in die Register
packt waehrend die SUN VMs da anfangs erst auf dem Stack herum-
wurschteln.
Das könnte durchaus eine Möglichkeit sein. Dann stellt sich aber die
Frage: Wenn der Programmcode dann 30% schneller läuft, warum macht Sun es
nicht auch so? Schließlich hat Sun seit der letzten Java-VM von Microsoft
noch vier Jahre Zeit gehabt es besser zu machen.
Wie oft werden in Programmen Schleifen verwendet, die ~2^31-mal
durchlaufen werden und in der eine einzelne if-Abfrage vor-
kommt? Bei komplexeren Schleifen duerfte der Laufzeitunterschied
bei den Schleifenvariablen weniger praegnant sein. Man koennte den
gleichen Versuch vielleicht mal mit einer Brute-Force-Attacke auf
einen RC5-Schluessel versuchen. Da sind mehr Rechenoperationen
notwendig als ein einzelner Modulo, die aber alle auf 586-er
Prozessoren mit jeweils einzelnen Maschinenbefehlen abgebildet werden
koennen (ausser AFAIR bei bestimmten AMD-Prozessoren, die kein
bitweises Rechtsrotieren kennen und entsprechend oft nach links
rotieren muessen).
Post by Lothar Kimmeringer
Wie gesagt, meine Aussage bezueglich des tiefer-eingebettet-
seins bezog sich auf die offensive Nutzung bestehender nativer
Funktionen in Windows per DLL (ganz offiziell ueber die
dokumentierten Schnittstellen, an Verschwoerungen glaube ich
da nicht ;-) was den VMs, die fuer mehrere Plattformen konzipiert
wurden, im Prinzip verwehrt ist (oder man programmiert eine
VM nur fuer Windows und eine fuer die anderen Plattformen).
Für welche andere Plattformen (oder besser gesagt Prozessoren) als Intel
ist Suns Hotspot-Compiler für Intel ausgelegt? Das Betriebssystem spielt
bei so einem Benchmark keine relevante Rolle.
Ich habe nicht vom Hotspot, sondern von der VM inkl. der "classes.zip"
geredet. Ich denke, dass bei jview nicht die Standard-ZIP von SUN
beiliegt, sondern dass diese entsprechend angepasst wurde, dass sie
bei bestimmten Operationen (wie eben z.B. die sqrt-Berechnung)
direkt auf die DLLs des Systems zugreift (wenn ich mich an jview
richtig erinnere, war da auch alles notwendige - z.B. auch die JDBC-
Treiber fuer MS-SQL - im jview-Binary mit enthalten). Da MS nur die
eine VM und nur fuer Windows anbietet, koennen die das auch machen. Andere
Anbieter muessen beim Standard-ZIP bleiben. Dass ein Hotspot-
Compiler fuer eine bestimmte Plattform gedacht ist, ist schon klar
(und sieht man sehr leicht, wenn man sich mal die Sourcen gezogen
hat ;-) aber wie gesagt habe ich oben gar nicht vom Hotspot gesprochen.

Um's an ein Beispiel zu haengen. Damit die gleichen Optimierungen
bei einer SUN VM moeglich waeren, wie ich sie mir bei jview
vorstelle, wuerde es im Prinzip keinen common-Ordner mit den
ganzen Klassen des java.*-Packages geben, da jede Klasse, die
Operationen durchfuehrt, fuer die es fertige Libraries auf dem
Zielsystem gibt, jeweils einzeln implementiert werden muesste.

Ob ein Betriebssystem keinen Einfluss auf die Laufzeit eines
Programms hat, wage ich aber mal zu bezweifeln, da deren Memory-
oder Task-Management, ... ja ebenfalls in die Laufzeit eines
Programms mit einfliesst.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Oliver S.
2003-09-09 13:46:30 UTC
Permalink
Post by Lothar Kimmeringer
Ich habe nicht vom Hotspot, sondern von der VM inkl. der "classes.zip"
geredet. Ich denke, dass bei jview nicht die Standard-ZIP von SUN
beiliegt, sondern dass diese entsprechend angepasst wurde, dass sie
bei bestimmten Operationen (wie eben z.B. die sqrt-Berechnung)
direkt auf die DLLs des Systems zugreift ...
Ich denke daß die Quadratwurzel direkt intrinsisch als FSQRT-Instru-
ktion in den Code hineincompiliert wird; machen aktuelle C/C++-Compi-
ler auch.
Post by Lothar Kimmeringer
Ob ein Betriebssystem keinen Einfluss auf die Laufzeit eines
Programms hat, wage ich aber mal zu bezweifeln, da deren Memory-
oder Task-Management, ... ja ebenfalls in die Laufzeit eines
Programms mit einfliesst.
Die Benchmarks aus der aktuellen c't führen keine Speicher-Alloka-
tionen durch und die Performance-Reduktion durch den Scheduler liegt
irgendwo im Promille-Bereich.
Lothar Kimmeringer
2003-09-09 15:12:08 UTC
Permalink
Post by Oliver S.
Post by Lothar Kimmeringer
Ich habe nicht vom Hotspot, sondern von der VM inkl. der "classes.zip"
geredet. Ich denke, dass bei jview nicht die Standard-ZIP von SUN
beiliegt, sondern dass diese entsprechend angepasst wurde, dass sie
bei bestimmten Operationen (wie eben z.B. die sqrt-Berechnung)
direkt auf die DLLs des Systems zugreift ...
Ich denke daß die Quadratwurzel direkt intrinsisch als FSQRT-Instru-
ktion in den Code hineincompiliert wird; machen aktuelle C/C++-Compi-
ler auch.
Glaube ich nicht, da ja erst mal Bytecode erzeugt wird, der nicht
zwangslaeufig auf immer der gleichen Plattform laufen muss. Was die
VM dann zur Laufzeit machen, kann man so pauschal auch nicht sagen.
Post by Oliver S.
Post by Lothar Kimmeringer
Ob ein Betriebssystem keinen Einfluss auf die Laufzeit eines
Programms hat, wage ich aber mal zu bezweifeln, da deren Memory-
oder Task-Management, ... ja ebenfalls in die Laufzeit eines
Programms mit einfliesst.
Die Benchmarks aus der aktuellen c't führen keine Speicher-Alloka-
tionen durch und die Performance-Reduktion durch den Scheduler liegt
irgendwo im Promille-Bereich.
Mein Beispiel war allgemeiner Natur und hatte nichts mit dem
Benchmark in der c't zu tun.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Oliver S.
2003-09-09 19:38:56 UTC
Permalink
... erst mal Bytecode erzeugt wird, der nicht zwangslaeufig
auf immer der gleichen Plattform laufen muss.
Ach, nimmst Du an ich hätte behaupten wollen, die FSQRT-Instruktion
wäre im Bytecode zu finden ?
Was die
VM dann zur Laufzeit machen, kann man so pauschal auch nicht sagen.
Pauschal nicht, aber bei C++-Compilern ist's schon lange üblich, daß
bestimmte mathematische Basisfunktionen (fabs, cos/sin etc) intrinsisch
durch ihre Instruktionsäquivalente im Befehlssatz ersetzt werden. Und
auch für einen JIT-Compiler dürfte es ein Leichtes sein, die entspre-
chenden Aufrufe intrinsisch zu übersetzen.
Lothar Kimmeringer
2003-09-09 22:04:05 UTC
Permalink
Post by Oliver S.
... erst mal Bytecode erzeugt wird, der nicht zwangslaeufig
auf immer der gleichen Plattform laufen muss.
Ach, nimmst Du an ich hätte behaupten wollen, die FSQRT-Instruktion
wäre im Bytecode zu finden ?
Du hast geschrieben
Post by Oliver S.
Post by Oliver S.
Ich denke daß die Quadratwurzel direkt intrinsisch als FSQRT-Instru-
ktion in den Code hineincompiliert wird; machen aktuelle C/C++-Compi-
ler auch.
Da Du nur ueber "Code" und "Compiler" geschrieben hast, war das eben
nicht klar, welchen Code und welchen Compiler Du gemeint hast.
Post by Oliver S.
Was die
VM dann zur Laufzeit machen, kann man so pauschal auch nicht sagen.
Pauschal nicht, aber bei C++-Compilern ist's schon lange üblich, daß
bestimmte mathematische Basisfunktionen (fabs, cos/sin etc) intrinsisch
durch ihre Instruktionsäquivalente im Befehlssatz ersetzt werden. Und
auch für einen JIT-Compiler dürfte es ein Leichtes sein, die entspre-
chenden Aufrufe intrinsisch zu übersetzen.
Nur ob sie's machen, weiss man nicht, weil dem Hotspot ja dann
bekannt sein muesste, dass Math.sqrt() die Wurzelfunktion ist.
Ich habe die aktuellen Sourcen von Math gerade nicht zur Hand,
aber wenn das ein native-Aufruf ist, dann sieht Hotspot AFAIK
nur bis zu JNI-Schicht, was dahinter ablaeuft dann nicht mehr.

Ist Math.sqrt() in Java implementiert, dann kann Hotspot auch
nur die "ueblichen" Optimierungen vornehmen.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Oliver S.
2003-09-10 18:50:06 UTC
Permalink
Post by Lothar Kimmeringer
Da Du nur ueber "Code" und "Compiler" geschrieben hast, war das
eben nicht klar, welchen Code und welchen Compiler Du gemeint hast.
Aber jetzt scheint Dir ja bewusst geworden zu sein, daß der Begriff
"Compiler" in Bezug auf Java kein eindeutiger ist. Aber der Zusammen-
hang klärt ja welchen nur meinen kann - den JIT-Compiler.
Post by Lothar Kimmeringer
Nur ob sie's machen, weiss man nicht, weil dem Hotspot ja dann
bekannt sein muesste, dass Math.sqrt() die Wurzelfunktion ist.
Genauso ist's bei den C/C++-Compilern, die kennen auch die Semantik
bestimmter Funktionen.
Kannst ja einen beliebigen Debugger nehmen (zB den des Watcom-C++,
denn der ist für Lau) mit dem Du einen OS-spezifischen Prozess debug-
gen kannst, die VM in einer Schleife mit ganz viel Math.sqrt()s los-
laufen lasssen und dann während dieser Zeit unterbrehen - dann weißt
Du es.
Post by Lothar Kimmeringer
Ich habe die aktuellen Sourcen von Math gerade nicht zur Hand,
aber wenn das ein native-Aufruf ist, dann sieht Hotspot AFAIK
nur bis zu JNI-Schicht, was dahinter ablaeuft dann nicht mehr.
Bzgl sqrt/sin/cos würde das auch keinen großen Performance-Vorteil
bringen da die entsprechende Instruktion sowieso eine recht lange
Laufzeit hat, aber Funktionen wie abs() würden von der intrinischen
Kompilierung auf jeden Fall profitieren.
Post by Lothar Kimmeringer
Ist Math.sqrt() in Java implementiert, dann kann Hotspot auch
nur die "ueblichen" Optimierungen vornehmen.
Mit Sicherheit ist das nicht in Java implementiert; weil eine
SW-Implementierung um Längen langsamer ist als die einer heutigen
FPU.
Tor-Einar Jarnbjo
2003-09-09 21:32:52 UTC
Permalink
Post by Lothar Kimmeringer
Mein Beispiel war allgemeiner Natur und hatte nichts mit dem
Benchmark in der c't zu tun.
Ist ja schon überhaupt ein Bisschen verwirrend, dass du mit
"Argumentationen allgemeiner Natur" kommst, wenn wir über ein ganz
konkretes Beispiel reden. Wenn du noch dazu über andere VMs (also nicht die
von Microsoft redest) und nebenbei dich auf den Quell-Code einer bestimmten
Version der Java-VM von Sun beziehst, wird es noch schwieriger deine
Argumentation zu folgen.

Gruß, Tor
Lothar Kimmeringer
2003-09-08 16:34:34 UTC
Permalink
Post by Tor-Einar Jarnbjo
Was meinst du damit, dass eine VM "tiefer ins System reingreift?"
Das weiß er selbst nicht; hört sich nur nach Kenntnis an.
Stoer nicht, wenn sich Erwachsene unterhalten.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Cybernd
2003-09-08 08:06:08 UTC
Permalink
Post by Tor-Einar Jarnbjo
Ich hatte übrigens ein paar Reaktionen darauf erwartet, dass die uralte
Microsoft-VM immer noch schneller ist als aktuelle Hotspot-VMs von Sun.
Hi

Naja ich dachte mir dabei schon meinen Anteil, wollte mich aber nicht
damit blamieren (pscht - ich war mir nicht sicher ob damit die MS VM
gemeint war ;o)

Andere Theorie:
Könnte es sein, das eine 1.er VM schneller werden kann, da sie noch
weniger Dinge berücksichtigt? Okay zugegeben die Sun 1.er ist alles
andere als schnell wenn man sie mit der Microsoft VM vergleicht, aber
wenn nun die 1er weiter optimiert worden wäre, würde sie auch die 1.4er
von Sun schlagen?

Zudem hatte doch die MS VM einige Sicherheitsprobleme. Wäre es also auch
denkbar das fehlende Sicherheitsüberprüfungen zu dem
Geschwindigkeitsvorteil führen?
Post by Tor-Einar Jarnbjo
Tiefer ins System greifen
hmmm

Wäre durchaus auch denkbar. Immerhin kennen die Microsoft Programmierer
einige Internas an die Konkurrenten einfach nicht herankommen können.
Dennoch glaube ich nicht, das es ein Effekt ist der von diesem
Detailwissen herrührt. Zugriff auf undokumentierte Windows APIs die nur
für die MS VM integriert wurden? Wäre auch denkbar ...

Ist sowieso immer schwer eine halbwegs objektive Aussage zu treffen wo
doch sehr viele Seiteneffekte bei solchen Microbenchmarks einfließen können.

cybi
michael paap
2003-09-08 09:40:00 UTC
Permalink
Post by Cybernd
Internas
Pfui. ;-)

Gruß,
Michael
--
Sollte ausnahmsweise eine Mail-Antwort auf ein Posting vonnöten sein,
bitte folgende Adresse verwenden: newsreply@<Absender-Domain>.
Carl Rosenberger
2003-09-10 11:42:28 UTC
Permalink
Post by Tor-Einar Jarnbjo
Ich hatte übrigens ein paar Reaktionen darauf erwartet, dass die uralte
Microsoft-VM immer noch schneller ist als aktuelle Hotspot-VMs von Sun.
Meine Laien-Meinung aus praktischen Ergebnissen:

Die uralte Microsoft-VM ("Microsoft (R) Befehlszeilenlader für
Java Version 5.00.3810") ist bei Multithreading eine Katastrophe,
weil gerne mal ein Thread in Ruhe zu Ende läuft, bevor der nächste
dran kommt. Das macht sie für komplexere Anwendungen faktisch
unanwendbar.

Der "Befehlszeilenlader" wird vergleichsweise ausgesprochen lahm,
wenn man viele Objekte erzeugt, die man nicht lange braucht. Hier
stimmt noch die alte Optimierungsregel "Objekterzeugung vermeiden".

Meiner Ansicht nach gewinnt die MS VM nur bei supersimplen
Anwendungen, also bei BenchMark-Tests. "Richtige" Programme werden
aus einer ganzen Reihe von Faktoren bei Verwendung der Sun VM
schneller laufen. Bei meiner Anwendung verhält sich das auch genau so.
Ich brauche mit der alten MS VM einen eigenen Thread, um Dateien zu
sperren und um diese Sperre zu kontrollieren. Das kostet tierisch Zeit.
Bei JDK 1.4 verwende ich aus NIO RandomAccessFile#getChannel().tryLock();
Schon allein dadurch läuft meine Applikation auf 1.4 immer deutlich
schneller. Zugegeben, das ist kein ganz fairer Test. Ich bin mir aber
ziemlich sicher, daß es in vielen Bereichen vergleichbare Vorteile
gibt, die man aus der Verwendung der aktuellen Sun VM ziehen kann.

Viele Grüße,
Carl
Stefan Matthias Aust
2003-09-10 11:52:25 UTC
Permalink
Post by Carl Rosenberger
schneller. Zugegeben, das ist kein ganz fairer Test.
Doch das ist IMHO ein fairer Test, denn die Gesamtperformance einer
Sprache wird nicht nur (vielleicht sogar nur zu einem kleinen Teil)
durch die VM beeinflusst sondern auch durch die Möglichkeiten der
Klassenbibliothek.


bye
--
Stefan Matthias Aust // "Ist es normal, nur weil alle es tun?" -F4
Tor-Einar Jarnbjo
2003-09-10 19:33:10 UTC
Permalink
Post by Carl Rosenberger
Die uralte Microsoft-VM ("Microsoft (R) Befehlszeilenlader für
Java Version 5.00.3810") ist bei Multithreading eine Katastrophe,
weil gerne mal ein Thread in Ruhe zu Ende läuft, bevor der nächste
dran kommt. Das macht sie für komplexere Anwendungen faktisch
unanwendbar.
Bei Client-Anwendungen könnte man so ein Problem wenn es einem bewusst
ist wohl meistens umgehen. Ich meine mich auch daran erinnern zu können,
dass die Thread-Verwaltung in Suns VMs <=1.1 auch nicht gerade besonders
toll war? Wurden die Threads nicht von der Java-VM selbst nachgebildet,
statt auf Betriebssystem-Threads zurückzugreifen?
Post by Carl Rosenberger
Meiner Ansicht nach gewinnt die MS VM nur bei supersimplen
Anwendungen, also bei BenchMark-Tests. "Richtige" Programme werden
aus einer ganzen Reihe von Faktoren bei Verwendung der Sun VM
schneller laufen. Bei meiner Anwendung verhält sich das auch genau so.
Ich brauche mit der alten MS VM einen eigenen Thread, um Dateien zu
sperren und um diese Sperre zu kontrollieren. Das kostet tierisch
Zeit. Bei JDK 1.4 verwende ich aus NIO
RandomAccessFile#getChannel().tryLock(); Schon allein dadurch läuft
meine Applikation auf 1.4 immer deutlich schneller. Zugegeben, das ist
kein ganz fairer Test. Ich bin mir aber ziemlich sicher, daß es in
vielen Bereichen vergleichbare Vorteile gibt, die man aus der
Verwendung der aktuellen Sun VM ziehen kann.
Es bringt ja nicht nur Performance-Probleme, dass neuere API-Funktionen
nicht vorhanden sind. Irgendwie wollte ich auch nicht die MS-VM als gute
Alternative lobpreisen. Ich finde es aber schon seltsam, dass Sun in den
letzten vier Jahren immer noch nicht geschafft hat "schnellere" VMs zu
bauen. Auch die VMs von IBM sind ja in der gleichen Version oft viel
schneller als die VM von Sun. Leider bietet IBM die Windows-Version nur
zusammen mit einem SDK für Web-Services und ich hatte keine Lust 120MB
runterzuladen, um die c't-Benchmarks auch mit der IBM-VM zu testen.

Ich habe übrigens noch Sun vs Microsoft mit meinem Vorbis-Dekoder
getestet. Hier schneidet Suns 1.4.1, 1.4.2 und Microsoft etwa gleich ab.
1.4.0 von Sun hatte einige Bugs, so dass der Hotspot nicht gegriffen hat
und war sehr viel langsamer. Auch Suns 1.3 ist hier langsamer als
Microsoft. Hier geht es zwar auch "nur" um mathematische Berechnungen,
es ist aber nicht wirklich mehr eine supersimple Anwendung.

Gruß, Tor
Wanja Gayk
2003-09-10 22:17:40 UTC
Permalink
Post by Carl Rosenberger
Die uralte Microsoft-VM ("Microsoft (R) Befehlszeilenlader für
Java Version 5.00.3810") ist bei Multithreading eine Katastrophe,
weil gerne mal ein Thread in Ruhe zu Ende läuft, bevor der nächste
dran kommt. Das macht sie für komplexere Anwendungen faktisch
unanwendbar.
Was bei gleicher Priorität immer noch richtig wäre, denn in den Specs
steht nur was von Priority scheduling, timeslicing wird nicht
garantiert.
Was Timeslicing angeht, sagt dieser Text aus, dass dieses nur vom OS-
Scheduler herrührt und von Java nicht garantiert wird:
http://java.sun.com/docs/books/tutorial/essential/threads/priority.html

Gruss,
-Wanja-
Marco Schmidt
2003-09-08 09:13:16 UTC
Permalink
Post by Tor-Einar Jarnbjo
Hmm, ich muss gerade überlegen ob die Methode wirklich deterministisch ist?
Die API-Dokumentation gestattet ja der Math-Klasse einige Freiheiten, um
eine bessere Performance zu erreichen, genau rechnet nur die StrictMath-
Klasse.
Wobei Math.java aus src.zip

public static double sqrt(double a) {
return StrictMath.sqrt(a); // default impl. delegates to
StrictMath
// Note that hardware sqrt instructions
// frequently can be directly used by JITs
// and should be much faster than doing
// Math.sqrt in software.
}

enthält. Deutet der Kommentar nun an, daß der JIT-Compiler
Math.sqrt-Aufrufe abfängt und durch eigenen Code ersetzt, oder ist das
nur eine generelle Anmerkung "da ginge noch was, vielleicht für
spätere Versionen"?

Gruß,
Marco
--
Bitte nur in der Newsgroup antworten, nicht per Email!
de.comp.lang.java Homepage: http://www.dclj.de/
FAQ: http://www.faqs.org/faqs/de/comp-lang-java/faq/
Meine Java-Seiten: http://www.geocities.com/marcoschmidt.geo/java.html
Juergen Kreileder
2003-09-07 17:28:43 UTC
Permalink
An dieser Stelle stellt sich mir die Frage, ob die Autoren die
Client- oder Server VM benutzt haben, denn die Server-VM optimiert
um einiges agressiver. Ich kann mir gut vorstellen, dass die
Client-VM sowas eben nicht wegoptimiert.
jdk1.4.2 jdk1.4.2 jview bcc5.5.1 gcc3.2.3 gcc3.2.3
-client -server (MS) -O6
1-1 34,8 20,2 24,7 150 140 26
1-2 27,5 20,0 24,7
Ich habs mal auf einem Opteron (Prototyp mit 1.2 GHz) unter Linux
laufen lassen. Interessant ist, dass bei RSARekursiv die Client VM
besser als die Server VM ist:

RSABrute:
Blackdown HS 1.4.2 GCC-3.2.2
Server Client g++ -03 gcj -03
32-bit: 10,1s 13,5s 11,0s ----
64-bit: 6,3s ----- 8,1s 8,1s


RSARekursiv:
Blackdown HS 1.4.2 GCC-3.2.2
Server Client g++ -03 gcj -03
32-bit: 45,2s 37,3s 39,2s -----
64-bit: 21,1s ----- 18,5s 24,8s


Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux/java2-status/
Ortwin Glück
2003-09-10 06:23:37 UTC
Permalink
Post by Tor-Einar Jarnbjo
Ich habe hier zwar nur die kostenlose Ausgabe von Borlands
C++-Compiler v5.5.1 (von Jahr 2000)
Du hättest ruhig einen GCC nehmen dürfen. Den gibts auch für Windows.
Cygwin ist dein Freund. Interessant wäre in diesem Zusammenhang auch was
GCJ für Laufzeiten bringt. Der soll ja in Sachen Optimierung noch
einiges können was HotSpot derzeit noch fehlt.
Tor-Einar Jarnbjo
2003-09-10 07:25:37 UTC
Permalink
Post by Ortwin Glück
Du hättest ruhig einen GCC nehmen dürfen. Den gibts auch für Windows.
Cygwin ist dein Freund. Interessant wäre in diesem Zusammenhang auch was
GCJ für Laufzeiten bringt. Der soll ja in Sachen Optimierung noch
einiges können was HotSpot derzeit noch fehlt.
Wenn du ein Bisschen weiterließt wirst du sehen, dass ich das gemacht habe.
gcj hatte ich auch probiert, kriege aber beim Linken Fehlermeldungen:

/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld:
cannot find -liconv

Gruß, Tor
Jochen Theodorou
2003-09-10 11:03:38 UTC
Permalink
Post by Tor-Einar Jarnbjo
Post by Ortwin Glück
Du hättest ruhig einen GCC nehmen dürfen. Den gibts auch für Windows.
Cygwin ist dein Freund. Interessant wäre in diesem Zusammenhang auch was
GCJ für Laufzeiten bringt. Der soll ja in Sachen Optimierung noch
einiges können was HotSpot derzeit noch fehlt.
Wenn du ein Bisschen weiterließt wirst du sehen, dass ich das gemacht habe.
cannot find -liconv
Wenn du den Source postest von (C und Java) dann kann ich ja mal einen
vergleich unter MinGW machen. Dort habe ich derzeit einen gcj und ein
gcc 3.3.1 am laufen

Gruss theo
Tor-Einar Jarnbjo
2003-09-10 18:08:43 UTC
Permalink
Post by Jochen Theodorou
Wenn du den Source postest von (C und Java) dann kann ich ja mal einen
vergleich unter MinGW machen. Dort habe ich derzeit einen gcj und ein
gcc 3.3.1 am laufen
Den Source kannst du von Heise runterladen unter der URL, die im ersten
Beitrag genannt wurde.

Gruß, Tor
Peter Büttner
2003-09-11 18:46:09 UTC
Permalink
ALso das C++ hab ich grad nicht zum Laufen gebracht, ich bin halt noch
nicht sehr vertraut mit g++, aber gcj funktionierte. Hier also meine
[...]
java version "1.4.1_01" mit client
Dauer: 0 Std 0 Min 21 Sek 581 ms
java version "1.4.1_01" mit server
Dauer: 0 Std 0 Min 12 Sek 719 ms
gcj.exe (GCC) 3.3.1 (mingw special 20030804-1)
Dauer: 0 Std 0 Min 13 Sek 99 ms
gcj scheint also zwischen client und server zu liegen
Ja, der ist nicht unbedingt schneller als java. Macht halt 'ne exe
und startet beim ersten mal schneller.

Hier meine Zeiten, sqrt jeweils aus der Schleife raus:
sec Faktor
g++ -O6 5,76 1
jview 6,42 1,11
'msvc4' -O2 6,81 1,18 (code angepasst)
g++ -O6 -mno-cygwin 7,12 1,24 (~MingW32)
java(1.4.1) --server 7,58 1,32
gcj -O2 8,25 1,43
java(1.4.1) 8,26 1,43
bcc32 -5 40,2 6,98

Der Borland Compiler scheint so lahm zu sein weil er bei den
64Bit mit zwei 32Bit rumhampelt, der gcc nimmt dafür long assembler
opcodes. Sieht man wenn man mit -S compiliert, und nach 'mod'
sucht. [gcc: version 3.2 20020927 (prerelease)]

Man testet hier aber nur das 'long mod long' Verhalten, schon recht
einfach, dieser Test. Schneller wird es beim gleichen Prozessor kaum
noch werden. Die Sprache macht es hier offensichtlich nicht aus
(warum auch) nur der Compiler. Die Unterschiede bewegen mich wirklich
nicht zum Schwenk auf C/C++.

Mal sehen was der nächste Artikel bringt, man sollte es wohl mit
etwas Vorsicht geniessen.

Grüße
Peter

Hier cpp das vom g++ angenommen wird. Ich hab's zusammengestaucht, doch
die Operationen in der Schleife sind die gleichen.
---><8-----><8-----><8-----><8-----><8-----><8-----><8-----><8--
#include <stdio.h>
#include <iostream>
#include <Math.h>
#include <Time.h>
using std::cout;

#ifndef __BORLANDC__
typedef unsigned long long __int64;
#endif
const __int64 BigNumber = 34571237124234713L;

static void DoPrimBruteForce(__int64 NumberToCrunch){
__int64 r = (__int64)sqrt(NumberToCrunch);
for (__int64 i=3; i<r; i+=2)
if(NumberToCrunch % i == 0)
cout << i << " * " << (NumberToCrunch/i) << " = " <<
NumberToCrunch << "\n";
}

main(){
cout << "C++: Zerlege " << BigNumber << "\n";
cout.flush();

clock_t start = clock();
DoPrimBruteForce(BigNumber);
clock_t diff = clock() - start;

cout << "Time:"<< (diff*1.0/ CLK_TCK) << " Sec\nPress Enter\n";
cout.flush();
getc(stdin);
}
---8><-----8><-----8><-----8><-----8><-----8><-----8><-----8><--
Stefan Matthias Aust
2003-09-11 20:42:00 UTC
Permalink
Ich habe heute die c't im Büro vorgefunden und konnte nicht umhin
(obwohl ich mir das fest vorgenommen hatte) das jetzt auch mal
auszuprobieren. Vielleicht wurde das daher schon gesagt:

Naiv kompiliert und mit 1.4.2 ausgeführt erreiche ich mit Java ähnliche
Ergebnisse wie gepostet. Mein Rechner hier hat nicht ganz 1 GHz und
daher komme ich (mit laufendem Winmap, der ein paar Prozent kostet) auf
ca. 6sek für die Empty, 7,6sek für Calc und ca. 10sek für RealCalc.
-Xprof zeigt, dass auch brav kompiliert wird. Der Test ist also okay,
auch wenn er natürlich alles mögliche misst, nur nicht einen Eindruck
der Performance eines typischen Java-Programms bietet.

Das war die client-VM. Der sträfliche Fehler der c't ist, das die nicht
die Server-VM getestet haben. Meine Ergebnisse:

Empty 4,7sek (20% besser)
Calc 5,7sek (25% besser)
RealCalc 9,3sek (10% besser)

Die Tests sind für Hotspot eigentlich zu kurz. Baut man in main() mal
eine Schleife ein, dass die drei Funktionen je 3x durchlaufen werden,
erkennt auch Hotspot die Sinnlosigkeit der Tests und liefert ab dem 2.
Durchlauf:

Empty 0sek
Calc 0sek
RealCalc 2,8sek (72% besser)

Damit schlägt Hotspot-Server nicht nur C# und zieht in den ersten beiden
Tests mit C++ gleich (was wohl auch komplett die Schleifen wegoptimiert)
sondern schlägt C++ locker im dritten Test.

Bei RSA brute force erhalte ich 24sek. Meine treue Hotspot-Server-VM
schafft es in 15sek (37% besser). Ein mehrfaches Ausführungen bringt
eine weitere Sekunde.
Nur die rekursive Version verliert bei mir: über 90sek dauert es
jeweils. Ob das an meinem PIII liegt?

Ich hatte noch gcj 3.3, damit komme ich auf 18sek für brute force und
90sek für die rekusrive Variante. Ich habe ohne groß zu probieren
einfach -O6 benutzt.
Post by Peter Büttner
java(1.4.1) --server 7,58 1,32
gcj -O2 8,25 1,43
java(1.4.1) 8,26 1,43
bcc32 -5 40,2 6,98
Dann bietet ich ca. 11sek für gcj und 15sek für java/server/hotspot.
Offenbar hat dieser die Optimierung auch selbst schon vorgenommen.


bye
--
Stefan Matthias Aust // "Ist es normal, nur weil alle es tun?" -F4
Peter Büttner
2003-09-11 22:57:15 UTC
Permalink
Hallo Stefan
Post by Stefan Matthias Aust
Ich habe heute die c't im Büro vorgefunden und konnte nicht umhin
(obwohl ich mir das fest vorgenommen hatte) das jetzt auch mal
Ja, das einfache messen macht ja nicht so dolle Aussagen, aber man
kann es halt einfach messen. Und ich find' es macht Spass, eine zeit
lang.
Post by Stefan Matthias Aust
Der Test ist also okay,
auch wenn er natürlich alles mögliche misst, nur nicht einen Eindruck
der Performance eines typischen Java-Programms bietet.
:-)
Post by Stefan Matthias Aust
Das war die client-VM. Der sträfliche Fehler der c't ist, das die nicht
Mir scheint es ging nur drum irgendwas zu machen, ob die sich auch
intensiv mit C#/Delphi/C++/Java auseinandergesetzt haben?

Gerade aufgefallen, im 'Rekursiven RSA Angriff', ein Stück Code:
if (i == 7)
{
int x = 0;
x++;
}
Nein, es folgt kein else. Hall of Fame?
Der Code ist irgendwie unschön, dann noch das die Textausgaben vorher
mitgemessen werden, das geht zwar unter, zeugt aber nicht so von
Sorgfalt.
Post by Stefan Matthias Aust
Die Tests sind für Hotspot eigentlich zu kurz. Baut man in main() mal
eine Schleife ein, dass die drei Funktionen je 3x durchlaufen werden,
erkennt auch Hotspot die Sinnlosigkeit der Tests und liefert ab dem 2.
Nixtun geht halt am schnellsten.
Post by Stefan Matthias Aust
Damit schlägt Hotspot-Server nicht nur C# und zieht in den ersten beiden
Tests mit C++ gleich (was wohl auch komplett die Schleifen wegoptimiert)
sondern schlägt C++ locker im dritten Test.
Bei RSA brute force erhalte ich 24sek. Meine treue Hotspot-Server-VM
schafft es in 15sek (37% besser). Ein mehrfaches Ausführungen bringt
eine weitere Sekunde.
Mehrfach hilft hier nix, gleich schnell.
Post by Stefan Matthias Aust
Ich hatte noch gcj 3.3, damit komme ich auf 18sek für brute force und
90sek für die rekusrive Variante. Ich habe ohne groß zu probieren
einfach -O6 benutzt.
-O6/O2/O3 macht hier keinen Unterschied. In meiner Doku geht es nur
bis O3, es gibt aber Seitenweise weitere Optimizations
Ha!
g++ -O2 -fomit-frame-pointer bringt von 5.82 auf 5.7 sec
Aber das bringt es doch nicht, wegen 2% schneller ewig mit den
options rummachen, und dann schiesst man sich noch in den Fuß
weil irgendwas nach hinten losgeht.
Post by Stefan Matthias Aust
Post by Peter Büttner
java(1.4.1) --server 7,58 1,32
gcj -O2 8,25 1,43
java(1.4.1) 8,26 1,43
bcc32 -5 40,2 6,98
Dann bietet ich ca. 11sek für gcj und 15sek für java/server/hotspot.
Offenbar hat dieser die Optimierung auch selbst schon vorgenommen.
Du meinst er berechnet sqrt() nicht für alle? Scheint mir
(hier "1.4.1_01") nicht so, sqrt ist in/vor Schleife:
in vor
13,2 8,3
-server 10,2 7,6
ich /glaube/ nicht das Hotspot 3s braucht um zu merken das
math.sqrt() hier invariant ist.


Gerade bemerkt: (beim 'durch 3 teilbare' i weglassen):
wenn man in Java die Ausgabe der Schleife in eine methode auslagert
wird es schneller:
for (i = 3; i < r; i+=2)
if(NumberToCrunch % i == 0)hit(NumberToCrunch,i);
von 7,6 auf 7,3 sec also ~4% besser
evtl. werden Register frei, in c++ wirkt das nicht so stark.
Ist doch prima: übersichtlichere Programme werden schneller.

Ach ja, man kann auch die durch 3 teilbaren Zahlen weglassen und
kommt auf 4,9s.


Grüße
Peter
Stefan Matthias Aust
2003-09-12 08:07:11 UTC
Permalink
Post by Peter Büttner
Mir scheint es ging nur drum irgendwas zu machen, ob die sich auch
intensiv mit C#/Delphi/C++/Java auseinandergesetzt haben?
if (i == 7)
{
int x = 0;
x++;
}
Nein, es folgt kein else. Hall of Fame?
Offenbar eine Falle für doofe Compiler, die diesen toten Code nicht
entfernen können :) Entfernen sollte nichts bringen, aber ich messe
4sek vorsprung für die client-Version ohne den Code.

Die C#-Version des Quelltexts hat übrigens diese Zeile nicht. Sie
vergleicht auch i mit < statt j mit <= gegen UBound. In dem zweiten if
nach dem else ist der selbe Unterschied. Was das ändern würde, habe ich
jetzt nicht probiert.
Post by Peter Büttner
Der Code ist irgendwie unschön, dann noch das die Textausgaben vorher
mitgemessen werden, das geht zwar unter, zeugt aber nicht so von
Sorgfalt.
Bei einer Laufzeit von über einer Minute (bei mir) ist es glaube ich
wirklich egal, ob 3x was ausgegeben wird.
Post by Peter Büttner
g++ -O2 -fomit-frame-pointer bringt von 5.82 auf 5.7 sec
Aber das bringt es doch nicht, wegen 2% schneller ewig mit den
options rummachen, und dann schiesst man sich noch in den Fuß
weil irgendwas nach hinten losgeht.
Was ist mit -funroll-loops? Ist das schon in den O's mit drin oder kann
man das auch noch zuschalten. Könnte ggf. etwas bringen.


bye
--
Stefan Matthias Aust // "Ist es normal, nur weil alle es tun?" -F4
Peter Büttner
2003-09-12 12:57:38 UTC
Permalink
Moin
Post by Stefan Matthias Aust
Post by Peter Büttner
Mir scheint es ging nur drum irgendwas zu machen, ob die sich auch
intensiv mit C#/Delphi/C++/Java auseinandergesetzt haben?
if (i == 7)
{
int x = 0;
x++;
}
Nein, es folgt kein else. Hall of Fame?
Offenbar eine Falle für doofe Compiler, die diesen toten Code nicht
entfernen können :) Entfernen sollte nichts bringen, aber ich messe
4sek vorsprung für die client-Version ohne den Code.
bei 1 Minute ist das schon bischen was. Macht hier 2s von 38 aus.
Bei mir ist übrigens der Rekursive Ansatz mit -server langsamer.
51s gegen 38s.
2/38=5%, es gibt Leute die geben für 5% schnelleren Speicher Geld aus.
Post by Stefan Matthias Aust
Die C#-Version des Quelltexts hat übrigens diese Zeile nicht. Sie
vergleicht auch i mit < statt j mit <= gegen UBound. In dem zweiten if
nach dem else ist der selbe Unterschied. Was das ändern würde, habe ich
jetzt nicht probiert.
Wenn ich in Java dort i<UBound reinschreibe so dauert es 1s länger.
Dann noch: in c# ist im 2ten if '(u==v) && (x<=y)' vertauscht.
Wird 332.916.918 mal durchlaufen, macht aber bei java kein Unterschied.

Hmm, auch wenn es nix ändert würde ich sagen: Nicht so gute Noten für
das ct Team wegen nicht beherrschung der Basics, unterschiedliche
Bedingungen, wo es doch hier einfach wäre diese gleich zu haben.

Auf der anderen Seite: Ich will mich als Entwickler nicht um solche
Kleinigkeiten kümmern müssen, ausser halt an Performancekritischen
Stellen. In normalen Programmen ist sowas eher egal.
Post by Stefan Matthias Aust
Post by Peter Büttner
Der Code ist irgendwie unschön, dann noch das die Textausgaben vorher
mitgemessen werden, das geht zwar unter, zeugt aber nicht so von
Sorgfalt.
Bei einer Laufzeit von über einer Minute (bei mir) ist es glaube ich
wirklich egal, ob 3x was ausgegeben wird.
Ja, hier schon. Mir ist aber aufgefallen das z.B. manche Cygwin Programme
bei Ausgabe auf die Konsole zum mitschreiben langsam sind. Wenn man
dann in Bereiche kommt wo die Ausgabe 1s und die Berechnung 2s
ausmacht... Siehe den Thread hier in der Gruppe mit BigInteger.

Es sollte das gemessen werden was beschrieben ist. Wenn man eine
grosse Leserschaft hat, sollte der Test sorgfältig sein. Was am Ende
des Tests rauskommt lesen viele, das sollte dann auch in etwa mit
der Realität übereinstimmen, gerade wenn es im Medium (Zeitschrift)
keine Diskussion gibt. Sonst hört man noch Java sei viieel
langsamer als .net
Post by Stefan Matthias Aust
Post by Peter Büttner
g++ -O2 -fomit-frame-pointer bringt von 5.82 auf 5.7 sec
Aber das bringt es doch nicht, wegen 2% schneller ewig mit den
options rummachen, und dann schiesst man sich noch in den Fuß
weil irgendwas nach hinten losgeht.
Was ist mit -funroll-loops? Ist das schon in den O's mit drin oder kann
man das auch noch zuschalten. Könnte ggf. etwas bringen.
Es kommt um den interessanten Bereich der gleiche Assemblercode raus,
nur manche Labels tauschen den Namen, was aber ohne Wirkung bleibt.
Prinzipiell bleibt an der entscheidenden Stelle ein
call ___umoddi3
übrig, ich kenne mich aber nicht genug aus ob das beim linken noch
inlined wird, wohl nicht.

Aber wer will sowas alles machen, da nachzugucken. Wenn es der
zentrale Programmkern ist ok, könnte lohnen.
Nebenbei wären Hints der Art: 'if() trifft selten ein'
oder 'diese Stelle so schnell wie möglich, Platz ist egal' besser.
der Compiler sollte den Rest machen. Ersteres kann ein dynamischer
Compiler wie Hotspot wahrscheinlich schon, wobei er wegen der
Beobachtung was vorgeht evtl. etwas langsamer ist. Dafür macht er
es ohne das ich mich kümmern muss!

Mich würde mal interessieren wieviel schneller das Programm auf
64Bit Maschienen läuft. Wahrscheinlich einiges, da native long.
Es passt mehr in die Registern, die dann ausreichen. War hier nicht
wer vom Blackdown Team der sowas hat:
Juergen Kreileder <***@blackdown.de>

Grüße
Peter
Peter Büttner
2003-09-12 13:33:00 UTC
Permalink
Post by Peter Büttner
Mich würde mal interessieren wieviel schneller das Programm auf
64Bit Maschienen läuft. Wahrscheinlich einiges, da native long.
Es passt mehr in die Registern, die dann ausreichen. War hier nicht
Upps, so nah...

Grüße
Peter
Aljoscha Rittner
2003-09-10 11:17:27 UTC
Permalink
jdk1.4.2 jdk1.4.2 jview bcc5.5.1 gcc3.2.3 gcc3.2.3
-client -server (MS) -O6
1-1 34,8 20,2 24,7 150 140 26
1-2 27,5 20,0 24,7
Gleich 2 Java VMs schlagen hier die C++ Version, die sogar bei O6 läuft,
das ist echt mal interessant. Auch gut zu sehen, wie die Server VM
besser optimiert.
2-1 17,4 16,6 12,5 150 17 15
2-2 18,3 16,6 12,5
Hier finde ich wiederum interessant, das die steinalte VM von Microsoft
scheinbar schneller läuft als die aufgemotzten Sun VMs.
Dazu muß man allerdings ehrlicherweise sagen, dass die "aufgemotzten"
VMs von Sun evtl. einen anderen Schwerpunkt haben. Die Sun-VM versucht
immer eine Balance zwischen Speicheroptimierung und Performance
hinzubekommen. Es wird versucht, dass der gc vernünftig läuft, Objekte
schnell erzeugt und verworfen werden können. Besimmte Bereiche des
Bytecodes werden nicht nativ compiliert usw.

Die steinalte VM von Microsoft compiliert sofort und führt alles
gleich native aus. Die VM kennt keine besonderen gc-Algos und
Analysiert auch nicht den Bytecode, um evtl. zur Laufzeit bessere
Alternativen zu finden. Und IMHO ist das genau der Vorteil, der bei
solchen kleinen Numbercruncher zum tragen kommt. Ein Numercruncher
wird idR für einen statischen Compiler schon im Algorithmus optimiert.
Man versucht schon im Algo alle Bedingungs-Pfade zu minimieren, so
dass Hotspot nix zum optimieren findet (aber es ja trotzdem versuchen
wird).

Die Hotspot-VM wird also mehr für große Applikationen die bessere
Performance bieten, als die alte M$VM

Gruß,
Josch.
--
Dreckiges Geschirr schimmelt nicht, wenn man es einfriert.
[Haushaltstips - für den nächsten Tip eine Antwort provozieren...]
Stefan Matthias Aust
2003-09-10 11:39:17 UTC
Permalink
Post by Aljoscha Rittner
Die Hotspot-VM wird also mehr für große Applikationen die bessere
Performance bieten, als die alte M$VM
Ich würde es extremer ausdrücken: Die MSVM versagt bei echten
objektorientierten Programmen mit hoher Dynamik. Und selbiges scheint
auch bei .NET - das natürlich die VM-Technologie geerbt hat erbt, zu
passieren. Das zeigen jedenfalls meine Tests, wie in üblicherweise mit
Objekten um sich schmeißen.

bye
--
Stefan Matthias Aust // "Ist es normal, nur weil alle es tun?" -F4
Marcus Fihlon
2003-09-11 08:50:49 UTC
Permalink
Hallo Christian,

es wäre nett, wenn Du in Deinem Newsreader Deinen Nachnamen ergänzen und
TOFU (Text oben, Fullquote unten) unterlassen würdest. Mehr zum Thema
"sinnvoll zitieren" findest Du unter dieser Adresse:

http://www.afaik.de/usenet/faq/zitieren/

Gruß
Marcus
--
"Dann schreib das doch bzw. verhalte Dich so. Wie man in die Newsgroup
hineinkräht, so ei-duziduzidu-t es wieder raus."

Dirk Nimmich (de.comp.datenbanken.mysql)
Alexander Frey
2003-09-11 13:42:26 UTC
Permalink
jdk1.4.2 jdk1.4.2 jview bcc5.5.1 gcc3.2.3 gcc3.2.3
-client -server (MS) -O6
1-1 34,8 20,2 24,7 150 140 26
1-2 27,5 20,0 24,7
2-1 17,4 16,6 12,5 150 17 15
2-2 18,3 16,6 12,5
Ich habe aus Interesse auch mal eine Testreihe auf meinem Rechener
(Pentium 3 1GHz mit Win2000) durchgeführt:

Version c't Version c't Version Tor
-target 1.1 (default) -target 1.1

jview 55,6 - 34,4
jdk1.2.2 5,9 5,8 5,6
jdk1.3.1 28,3 (15,7) 28,0 (15,5) 13,4 (12,8)
jdk1.4.0 23,1 (25,2) 23,3 (24,8) 13,5 (12,8)
jdk1.4.1 26,2 (15,7) 26,3 (15,7) 13,4 (12,8)
jdk1.4.2 23,6 (16,5) 23,6 (16,6) 13,5 (12,7)

Die Zeiten sind Mittelwerte von zwei von einander unabhängigen Läufen.
Die Werte in den Klammern sind mit -server gemessen.

Wie Tor schon geschrieben hat, kann man zwischen dem mit -target 1.1 und
dem "normal" übersetzten Bytecode (beides mal mit JDK1.4.2) bei der
Ausführung keinen Unterschied erkennen.

Einige Dinge sind mir allerdings aufgefallen:
1. Bei mir scheint jview viel langsamer zu sein. Es ist jedes mal
deutlich langsamer als alle jdks. Gibt es vielleicht irgendwelche
Parameter (wie -server) mit denen ich jview starten muss, damit es
schneller läuft?
2. Schlägt das jdk1.2.2 alle anderen jdks um Längen. Kann diese
Beobachtung jemand bestätigen? Wenn ja, scheint Sun in Version 1.3
Änderungen gemacht zu haben, die für diesen speziellen Testfall
kontraproduktiv waren.
3. Bei der Option -server tanzt jdk1.4.0 aus der Reihe, hier ist bei mir
sogar eine "normale" Ausführung schneller.

Gruß,
Alexander
Tor-Einar Jarnbjo
2003-09-13 09:42:52 UTC
Permalink
Post by Alexander Frey
Version c't Version c't Version Tor
-target 1.1 (default) -target 1.1
jview 55,6 - 34,4
jdk1.2.2 5,9 5,8 5,6
jdk1.3.1 28,3 (15,7) 28,0 (15,5) 13,4 (12,8)
jdk1.4.0 23,1 (25,2) 23,3 (24,8) 13,5 (12,8)
jdk1.4.1 26,2 (15,7) 26,3 (15,7) 13,4 (12,8)
jdk1.4.2 23,6 (16,5) 23,6 (16,6) 13,5 (12,7)
Stimmt. JDK1.2.2 ist bei mir auch entsprechend viel schneller als 1.3
oder 1.4 und 1.1.8 ist auch genau so schnell wie 1.2.2. 1.0.2 braucht
aber fast fünf Mal so lange wie 1.4.2.

Auf einem 700MHz Pentium III, meine Version:

jdk1.0.2 84s
jdk1.1.8 7s
jdk1.2.2 7s
Post by Alexander Frey
jdk1.3.1 17s
jview 12s

Es gab in 1.4.0 einige Bugs im Hotspot, die dazu geführt haben, dass oft
ausgeführte Methoden nicht vom Hotspot erfasst wurden, sondern immer
interpretiert wurden. Vielleicht fällt deswegen 1.4.0-server aus der
Messreihe.

Gruß, Tor

Lesen Sie weiter auf narkive:
Loading...