[Perfromance Benchmark] Java - C++

Hallo,

wenn man die Aussage des Benchmarks, daß Java bei einigen Aufgaben schneller als C++ bzw. schneller als von üblichen C++ Compilern produzierter Code ist, entkräften möchte, dann sollte man vielleicht nicht gerade einen Teilbenchmark optimieren, bei dem C++ sowieso schneller ist. Es sollten eher die optimiert werden, bei denen die C++ Version langsamer ist.

Damit dürfte Java schnell genug sein... Passt auch zum Thema IBM und Java

http://www.heise.de/newsticker/meldung/46362

Irgendwann vielleicht auch erschwinglich für kleinere Firmen

volkard schrieb:

Optimizer schrieb:

So etwas kann ich selbstverständlich auch in Java schreiben.

ups, hab ich verpasst, daß operator overloading eingeführt wurde? wenn das der fall ist, kann man sich natürlich klassen schreiben, die man dann auch benutzen mag. oder man könnte auch die operatoren für die eingebauten typen wegmachen.

Wenn's dir um Operator-Overloading geht, dann nimm doch C#. Da haste das Gleiche in Grün und mit operator overloading. Aber ich sehe nicht, warum das dann abstrakter oder performanter ist? Denn das war doch das Thema.

So etwas verursacht in Java mit Sicherheit auch keinen Overhead, der JIT-Compiler kann genauso Methoden inlinen und anderen Overhead sehe ich dort nicht.

kann sein. aber ich traue das java nicht fehlerfrei zu.

Hmmmmm. Ich denke, dass du dem Hotspotter einiges zutrauen kannst. Ich würde nicht meine Hand darauf verwetten, dass so ne Methode beim ersten Kompilieren geinlined wird. Das Problem ist, dass nicht-statische und nicht-private Methode erstmal als virtuell gelten.
Aber wenn der Hotspotter sogar Variablen erkennt, die ihren Wert nicht mehr ändern, sie fest einkompiliert und dann die Stelle neu kompiliert, wenn sich der Wert nach 93846 Jahren doch geändert hat, dann darfst du ihm inlinen zutrauen, würde ich sagen.

und das letzte beispiel verdeutlicht einfach nur die schlechtheit des tests. solche tests fordern doch nur herauf, daß man die compiler umstrickt, sodaß sie genau die testfälle erkennen und wegoptimieren.

Von dem Benchmark halte ich genauso wenig wie du. Ich habe mich nur gewundert, warum dass deiner Meinung in Java nicht möglich sein soll. Gerade Optimierungen auf Algorithmenebene (und das war das doch) sind doch in nahezu jeder Sprache umsetzbar.
Das ist doch so schön. Jeder darf in der Sprache coden, die ihm genehmer ist und ungefähr auf die gleiche Performance kann er doch noch kommen. Ein HashSet ist und bleibt ein HashSet, auch wenn's in Java gecodet ist.

Dann gibt's halt Dinge, wo man in C++ mehr Möglichkeiten hat. Dann gibt's noch Dinge, wo man in C++ mehr Aufwand investieren muss, um die selbe Funktionalität zu erhalten. Dann gibt's sogar Dinge, wo man in C++ mehr Aufwand investieren muss, um die selbe Performance zu erhalten (z.B. Allokatoren). Ist halt immer unterschiedlich, aber am meisten hängt's halt doch vom Programmierer ab.

Java macht mir halt das Leben leichter und ich kann mehr über meine Algorithmen nachdenken. Weil wenn ich statt

for( std::vector<Foo*>::const_iterator i = myVector.begin();  i != myVector.end();  ++i )
    (*i)->methode();

folgendes habe:

for( Foo x : myVector)
    x.methode();

kann ich mich leichter auf's Wesentliche konzentrieren. Das soll jetzt nur als Beispiel dienen und nicht aufzeigen, dass ich mit obigen C++ Code überfordert bin. Aber ich bin halt trotzdem nur ein Mensch.
Und weil es so viele Menschen auf dieser Welt gibt, gibt es noch andere Sprachen als C++.

DEvent

Java macht mir halt das Leben leichter und ich kann mehr über meine Algorithmen nachdenken. Weil wenn ich statt
for( std::vector<Foo*>::const_iterator i = myVector.begin(); i != myVector.end(); ++i ) 
(*i)->methode();

noch nie was von typedef gehört?

das ist es was mich an java stört. keine operatoren und keine typedefs.
wieso wurde das eigentlich nicht übernommen? diese beiden dinge erleichtern das leben einem sehr. vieleicht werden wenigstens operatoren mit eingenommen, so wie die templates.

ich hab mal eine gui gebastelt mit java ( studium ) und ich muss sagen, Java algos sind nicht lahm. leider ist aber swing & co. mehr als lahmarschig. die ganze grafik ist in java sehr langsam. das liegt wohl daran, dass die GUI portabel sein soll und man deswegen noch einen layer über die win-gui legt.

DEvent schrieb:

noch nie was von typedef gehört?

Nein, ich bin blöd, weißt.
Dieses Stück Code ist ein repräsentatives Beispiel dafür, dass C++ mir an einigen Stellen einfach zu kaputt ist, was mich ablenkt. Und das betrifft insbesondere auch Templates. Das ist meine Meinung, die ich haben darf.

das ist es was mich an java stört. keine operatoren und keine typedefs.
wieso wurde das eigentlich nicht übernommen? diese beiden dinge erleichtern das leben einem sehr. vieleicht werden wenigstens operatoren mit eingenommen, so wie die templates.

Das ist deine Meinung, die du auch haben darfst. Falls du auf Operatoren in Java ernsthaft hoffst, muss ich dich enttäuschen, die Chance dafür geht gegen absolut 0. Ich finds auch ein bisschen schade, deshalb schwank ich so zwischen Java und C#, welches dafür nicht mal kovariante return-Typen kennt.

ich hab mal eine gui gebastelt mit java ( studium ) und ich muss sagen, Java algos sind nicht lahm. leider ist aber swing & co. mehr als lahmarschig. die ganze grafik ist in java sehr langsam. das liegt wohl daran, dass die GUI portabel sein soll und man deswegen noch einen layer über die win-gui legt.

Und wieder etwas, was nichts mit Java zu tun hat. In C++ rufst du WinAPI Funktionen auf. In Java machst du das nicht und beschwerst dich aber dann, anstatt es dort genauso zu machen.
Ich werde diese Logik nie verstehen. "Hey wenn ich in C++ WinAPI nutze und in Java Swing, dann ist Java voll lahm, man ist das scheiße" *kopfschüttel*

phlox81

Auch C++ kennt foreach...
Ich denke, das was C++ einfach fehlt ist eine klare Standard Umgebung,
Java hat das, mag kein Vorteil sein, aber es macht es den Leuten einfach.
Und, seinen wir ehrlich, im grunde sind Programmierer faul, was
einfach ist, und jeder versteht wird sich durchsetzen.

Devil

DEvent

stimmt auf die idee, statt swing direkt die winapi aufzurufen kommt keiner. (also wenn einem die gui wichtiger ist als portabilität). Aber wenn man zB wxWidgets benutzt wird die GUI ja nicht so lahm wie swing. ist das jetzt ein beispiel für die lahmheit von java oder ein beispiel für eine schlechte implementation der swing-entwickler?

naja in 5 jahren wird das eh keinen unterschied machen...

Ich glaube, dass du glaubst, dass Swing ein Wrapper um das Betriebssystem-API ist. Swing wird aber vom Programm selber gemalt, was einiges sicher erklärt .
Mit AWT gibts noch nen Wrapper um das Native System, das kann aber natürlich nicht so viel.

groovemaster

Optimizer schrieb:

Dieses Stück Code ist ein repräsentatives Beispiel dafür, dass C++ mir an einigen Stellen einfach zu kaputt ist, was mich ablenkt. Und das betrifft insbesondere auch Templates. Das ist meine Meinung, die ich haben darf.

Die ist aber ebenso wenig repräsentativ wie dein Beispiel für eine kaputte Sprache.

DEvent

was bitte heist jetzt "wird vom programm selber gemahlt" ?

DEvent schrieb:

leider ist aber swing & co. mehr als lahmarschig. die ganze grafik ist in java sehr langsam.

Wie lange wohl noch? In 1 oder 2 Javaversionen wird Swing auf OpenGL aufsetzen und kommt damit deutlich näher an die darunterliegende Hardware. Vermutlich ähnlich nah wie die native GUI. Abgesehen davon wird Swing sowieso von Version zu Version deutlich beschleunigt und der Geschwindigkeitsnachteil macht immer weniger aus, weil die Rechner schneller werden. Bei Java tut sich andauernd etwas und die Schwächen werden konsequent, wenn auch nicht ganz so schnell wie sich manche erhoffen, beseitigt. Was tut sich währenddessen bei C++? Jahrelanges Warten auf den nächsten Standard. Ich frage mich, wann die C++ Gemeinde endlich aufwacht und mal einen Zahn zulegt. Wenn der neue Standard so groß ist, dass es 10 Jahre benötigt, ihn festzulegen, dann sollte man doch überlegen, ob man nicht lieber häufiger kleinere Veränderungen vornimmt. Zumal bei so langen Zeitdauern vermutlich viele Dinge, die in den ersten Jahren entschieden wurden, am Schluss längst veraltet sind.

otze

for( std::vector<Foo*>::const_iterator i = myVector.begin();  i != myVector.end();  ++i )
    (*i)->methode();

ma schaun, was man da noch vereinfachen kann

erstmal das typedef wie bereits gesagt wurde:

typedef std::vector<Foo*>::const_iterator iterator;
for(iterator i = myVector.begin();  i != myVector.end();  ++i )
    (*i)->methode();

ok, sieht schon einfacher aus... leider stört mich noch die zusätzliche dereferenzierung von i.

ok, boost hilft uns da weiter:

using namespace boost;
//...
typedef indirect_iterator<std::vector<Foo*>::const_iterator> iterator;
for(iterator i = myVector.begin();  i != myVector.end();  ++i )
    i->methode();

ok...durch die typedef ist das doch nicht so schön...

egal, man kann ja noch das for problemlos wegbekommen:

#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>

using namespace boost::lambda;
//...
std::for_each(bar.begin(),bar.end(),bind(&Foo::methode,*_1));

najut, so kurz wie die java version is es immernoch nicht, aber wenigtens ein oneliner

volkard

devil81 schrieb:

Auch C++ kennt foreach...

aber kein ernstzunehmendes.

und java kennt keine enrsatzunehmenden templates. fair ist es nur, zu sagen: c++ hat kein foreach und java hat keine templates.

Ich denke, das was C++ einfach fehlt ist eine klare Standard Umgebung,
Java hat das, mag kein Vorteil sein, aber es macht es den Leuten einfach.

klarer standard ist in c++ genauso da. nur macht c++ den riesen-fehler, nur bis zur konsolen-ausgabe ohne farbe zu gehen. nix bunt, keine threads, nix sockets, keine maus. nix eben. und ein standardisierungskomitee, das schlicht verabsäumt, minor changes rauszubringen.

edit: ich würde sagen, die standardisierung hat c++ getötet. vielleicht noch zu retten, wenn ganz bald ein standard mit mehr grafik rauskommt.

net 0

volkard schrieb:

klarer standard ist in c++ genauso da. nur macht c++ den riesen-fehler, nur bis zur konsolen-ausgabe ohne farbe zu gehen. nix bunt, keine threads, nix sockets, keine maus. nix eben.

so'n 'standard' gibts auch für java. guckst du: http://java.sun.com/docs/books/jls/second_edition/html/jTOC.doc.html
aber java ist eben mehr als nur eine programmiersprache (wie z.b. c++)

Power Off

Optimizer schrieb:

Ich glaube, dass du glaubst, dass Swing ein Wrapper um das Betriebssystem-API ist. Swing wird aber vom Programm selber gemalt, was einiges sicher erklärt .
Mit AWT gibts noch nen Wrapper um das Native System, das kann aber natürlich nicht so viel.

Das stimmt so nicht. Die AWT benutzt Code, der ueber JNI eingebunden ist, jedoch ist die AWT kein Wrapper um das OS. Das machen die Teile, die mit dem JNI implementiert sind.

Swing ist auf gleicher Ebene wie die AWT implementiert.

Unter Windows benutzt Swing damit indirekt sogar DirectX, um seine Fenster zu zeichnen. (Was natuerlich unklug ist -- da Java viel zu lahm ist und dadurch seine Surfaces zu lange sperrt)

Es gibt auch einen Java 3D API, der eine halbwegs brauchbare 3D Performance liefert (ebenfells unter Windows indirekt ueber Direct3D).

Richtig ist, dass Swing seine Komponenten selber malt, sonst gaebe es auch kein "Pluggable Look & Feel".

Neue Frameworks wie SWT liegen direkter ueber dem System API.

Java ist prinzipiell nicht schlecht, aber von der Performance kaum mit C++ vergleichbar.

Es mag sein, dass in Java die Objektkonstruktion schneller ablaeuft, da ein Garbage Collected Heap verwendet wird, aber das ist in C++ auch moeglich (z.B. ueber Allocation-Template-Parameter in der STL). Damit wuerde dann dieser Vorteil von Java vollends wegfallen, wenn man in C++ eigene Allocator-Klassen verwendet.

Der Nachteil des Java Garbage Collectors ist, dass die VM angehalten werden muss, um die Garbage Collection auszufuehren. Das ist eine extrem primitive Loesung, zu der es schon seit Jahrzehnten bessere Alternativen gibt.

Fuer viele Programme ist ein Anspringen des Garbage Collectors toedlich, da der User denkt, das Programm reagiert nicht mehr. Das gilt auch fuer viele lahme Routinen in Swing.

Ehrlich gesagt, habe ich von Java eh nicht allzu viel erwartet, da einer der Entwickler mal behauptet hat "niemand versteht unsigned-Arithmetik". War wohl eher nur er gewesen ...

Vielleicht kommen ja mal unsigned-Typen in Java, solange werde ich warten, bis ich es verwende (warum Bits verschwenden?).

JBeni

Ehrlich gesagt, habe ich von Java eh nicht allzu viel erwartet, da einer der Entwickler mal behauptet hat "niemand versteht unsigned-Arithmetik". War wohl eher nur er gewesen ...

Es gibt überall schwarze Schafe, nur weil jemand zu schnell Autofährt, sind nicht alle Autofahrer Raser...

Fuer viele Programme ist ein Anspringen des Garbage Collectors toedlich, da der User denkt, das Programm reagiert nicht mehr. Das gilt auch fuer viele lahme Routinen in Swing.

Bitte nenn mir ein konkretes Beispiel. Ich hab in all den Jahren die ich Java nutze noch nie ein Progi gesehen das aufgrund des GC's stockt (wenn was stockte, war das Problem immer im Code zu finden).

[Edit: Typo]

volkard schrieb:

vielleicht noch zu retten, wenn ganz bald ein standard mit mehr grafik rauskommt.

Oder umsteigen auf einen anderen Standard: C++/CLI. Da haste viele bunte Sachen, sogar mit malen auf GUIs.

Power Off schrieb:

Das stimmt so nicht. Die AWT benutzt Code, der ueber JNI eingebunden ist, jedoch ist die AWT kein Wrapper um das OS. Das machen die Teile, die mit dem JNI implementiert sind.

Na, den Unterschied verstehe ich jetzt nicht.
AWT ist ja gerade diese native Bibliothek und über das JNI greif ich darauf zu.

Swing ist auf gleicher Ebene wie die AWT implementiert.

Unter Windows benutzt Swing damit indirekt sogar DirectX, um seine Fenster zu zeichnen. (Was natuerlich unklug ist -- da Java viel zu lahm ist und dadurch seine Surfaces zu lange sperrt)

Nein, das stimmt nicht. Hast du dir den Source mal angesehen? Swing ist 100% in Java und nutzt das Graphics-API, mit dem man auf GUIs und BufferedImages malen kann. Dieses wiederum nutzt unter Windows das GDI.

"Auf gleicher Ebene implementiert" ist nur das JFrame, was ein natives Fenster ist, alle JComponents darauf werden gemalt.

@otze: Dein Besipiel ist Klasse wie schön man C++ vereinfachen kann. Aber es zeigt auch recht schön, daß es ist nicht schnell und einfach geht. Das will die Industrie. Der Industrie ist es im Regelfall scheiß egal, ob dein C++ Programm 3,6589932 sek. schneller läuft.

Das Ziel ist ein Produkt das stabil ist und kostengünstig erstellt werden kann. Ich habe früher auch Java nicht gemocht. Für meinen AG musste ich es lernen. Heutzutage kann ich bestätigen, daß Java die ideale Mitte zwischen guter Abstraktion, Performance und schneller Entwicklung getroffen hat.

Damit will nicht sagen, daß C++ aussterben wird. Es gibt noch sehr viel Code in C++(wie auch in COBOL ). Aber damit C++ für neue Projekte nocheinmal interessant werden kann, braucht es einen Standard der wie Volkard schon sagte, alles abdeckt. GUIs, Threads, Sockets, usw.

Wenn dieser neue Standard mit diesen Features nicht sehr bald kommt, dann wird C++ für sehr viele neue Projekte uninteressant.

Power Off schrieb:

Der Nachteil des Java Garbage Collectors ist, dass die VM angehalten werden muss, um die Garbage Collection auszufuehren. Das ist eine extrem primitive Loesung, zu der es schon seit Jahrzehnten bessere Alternativen gibt.

Fuer viele Programme ist ein Anspringen des Garbage Collectors toedlich, da der User denkt, das Programm reagiert nicht mehr.

Tut mir leid, ist mir 3,5 Jahren nicht einmal passiert!

Power Off schrieb:

Vielleicht kommen ja mal unsigned-Typen in Java, solange werde ich warten, bis ich es verwende (warum Bits verschwenden?).

Genau darauf braucht man heutzutage in der Softwareentwicklung(ich meine SW die auf X86 und besser läuft) nicht mehr achten.

Es mag sein, dass in Java die Objektkonstruktion schneller ablaeuft, da ein Garbage Collected Heap verwendet wird, aber das ist in C++ auch moeglich (z.B. ueber Allocation-Template-Parameter in der STL). Damit wuerde dann dieser Vorteil von Java vollends wegfallen, wenn man in C++ eigene Allocator-Klassen verwendet.

Das fällt unter den von mir erwähnten Punkt "mehr Aufwand um die gleiche Performance zu erreichen", was auf einige Dinge im Java <-> C++ vergleich durchaus zutrifft. In C++ hat man mit genügendem Aufwand natürlich immer die Möglichkeit, noch performanter zu sein.

Der Nachteil des Java Garbage Collectors ist, dass die VM angehalten werden muss, um die Garbage Collection auszufuehren. Das ist eine extrem primitive Loesung, zu der es schon seit Jahrzehnten bessere Alternativen gibt.

Unsinn. Bei einer Gen0-Collection, was die allermeisten Collections sind, laufen alle Threads während der Mark-Phase weiter und erst bei der Kompaktierungsphase werden sie sehr kurz angehalten. Ich hab Gen0-Zeiten von ein paar zehntel Millisekunden.

Fuer viele Programme ist ein Anspringen des Garbage Collectors toedlich, da der User denkt, das Programm reagiert nicht mehr.

Ja, da werd ich auch immer gleich mistrauisch, wenn mein Programm ein paar zehntel ms nicht mehr reagiert.

Vielleicht kommen ja mal unsigned-Typen in Java, solange werde ich warten, bis ich es verwende (warum Bits verschwenden?).

Es gibt unsigned Bitshifts und bitweise Operatoren in Java, dafür braucht man keine eigenen Typen. Damit kannst du beliebige Bitmuster erzeugen und alles andere ist oft nicht viel mehr als Schnickschnack. Wer es vermisst, codet halt dann in C++ oder C#, für ausreichend viele Leute ist das kein Problem, wie man sieht.

volkard

Power Off schrieb:

Ehrlich gesagt, habe ich von Java eh nicht allzu viel erwartet, da einer der Entwickler mal behauptet hat "niemand versteht unsigned-Arithmetik". War wohl eher nur er gewesen ...

bei lichte betrachtet ist die unsigned-arithmetik natürlich einfacher als die signed-arithmetik.
natürlich verstand er auch unsigned-arithmetik. das ist typisches sun-marketing. jeden eigenen nachteil als vortiel verkaufen. so sachen wie "ohne überladene operatoren kann man den code besser lesen" oder "ohne zeiger ist viel klarer, was da passiert". und die leute, die nicht programmieren können, glauben das sogar. und das war bestimmt ein test-ballon, um zu gucken, ob das nicht allzu dreist ist. war aber allzu dreist und es konnte keine unsigned-lüge ins offizielle sun-marketing eingereiht werden.