[Perfromance Benchmark] Java - C++

[AlleNamenBelegt]

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]

[Gast]

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.

[C++ und Java Entwickler]

@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.

[Gast]

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.

[borg]

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 .

Qt malt auch selbst, das ist kein argument. irgendwas muss bei der swing-implementierung schiefgelaufen sein.

----------
und wenn du sagst java-code ist einfacher zu handhaben und sieht schöner aus, dann kann ich das auch nicht zu 100% nachvollziehen:

myList.add(new Integer(myInt));
//...
int intFromList = ((Integer)myList.get(0)).intValue();

myList.push_back( myInt );
//..
int intFromList = myList[0];

und vielleicht ist java hier in dem momment auch schon langsamer, auf grund des hin und her castens. natürlich, ich kann mir eine eigene liste schreiben die nur mit int hantiert, dann greift aber das argument java sei einfacher zu handhaben überhaupt nicht mehr.

oder mal was zu der hochgelobten java-api:
wenn ich zB das GridBagLayout mit Qt's QGridLayout vergleiche, die machen beide genau das gleiche. der unterschied besteht darin, QGridLayout guck ich mir in der doku 2 minuten an und kann es benutzen, GridBagLayout ist das benutzerunfreundlichste was ich je gesehen hab. ich denke da wird mir kaum einer widersprechen.
oder gucken wir uns den layout manager von swing an, der scheint beim resizen überhaupt nicht zu funktionieren. es scheint gar kein konzept zu geben was die maximale und die minimale größe einer komponente anbelangt (mit Qt verglichen wieder total unverständlich).
es gibt soooo viele solche beispiele. deswegen kann ichs einfach nicht verstehen warum die leute sagen java hätte eine "easy-to-use" API.

[Gast]

borg schrieb:

Qt malt auch selbst, das ist kein argument. irgendwas muss bei der swing-implementierung schiefgelaufen sein.

Moment. *nachschau*

http://www.trolltech.com/products/qt/index.html schrieb:

Qt encapsulates the different platform-specific APIs of Unix, Windows, and Mac, and the APIs for file handling, networking (Operations, Protocols), process handling, threading, database access, and more.

Hihi.

und wenn du sagst java-code ist einfacher zu handhaben und sieht schöner aus, dann kann ich das auch nicht zu 100% nachvollziehen: [...]

Egal. Es ist weder meine Absicht, noch mein Wunsch, dich von Java zu überzeugen.

[JBeni]

borg schrieb:

und wenn du sagst java-code ist einfacher zu handhaben und sieht schöner aus, dann kann ich das auch nicht zu 100% nachvollziehen:

myList.add(new Integer(myInt));
//...
int intFromList = ((Integer)myList.get(0)).intValue();

Du kannst sowas natürlich kompliziert schreiben... aber Java erlaubt auch das:

List<Integer> myList = ...

myList.add( 123 );
int intFromList = myList.get( 0 );

Ich kanns mir nicht verkneifen: "zuerst informieren, dann protestieren!" (zugegeben, das Feature ist erst seit einem Jahr dabei :)).

Das andere: eine Liste nimmt nur Objekte auf. Ein "int" ist kein Objekt, deshalb muss er verpackt werden (und dazu verwendet man die Klasse "Integer").

[borg]

Optimizer schrieb:

borg schrieb:

Qt malt auch selbst, das ist kein argument. irgendwas muss bei der swing-implementierung schiefgelaufen sein.

Moment. *nachschau*

http://www.trolltech.com/products/qt/index.html schrieb:

Qt encapsulates the different platform-specific APIs of Unix, Windows, and Mac, and the APIs for file handling, networking (Operations, Protocols), process handling, threading, database access, and more.

Hihi.

ja ich hab gesagt Qt malt selbst, wie soll denn zB "file handling" funktionieren ohne dabei auf betriebssystem-spezifische funktionen zuzugreifen? ich nehme an das macht die JVM auch (weiß ich aber nicht)
übrigens auf der gleichen seite 2 zeilen drunter:

http://www.trolltech.com/products/qt/index.html schrieb:

Qt requires no "virtual machines" or emulation layers. It writes directly to low-level graphics functions, just like native apps do. So Qt applications run at native speed.

Hihi.

Optimizer schrieb:

und wenn du sagst java-code ist einfacher zu handhaben und sieht schöner aus, dann kann ich das auch nicht zu 100% nachvollziehen: [...]

Egal. Es ist weder meine Absicht, noch mein Wunsch, dich von Java zu überzeugen.

darum gehts doch gar nicht, ich bin eh unverbesserlich

[borg]

JBeni schrieb:

Ich kanns mir nicht verkneifen: "zuerst informieren, dann protestieren!" (zugegeben, das Feature ist erst seit einem Jahr dabei :)).

ich muss zugeben wenn ich von java rede dann rede ich von java 1.4, das hab ich in der uni gelernt und mich bisher noch nicht mit java 5 befasst.

JBeni schrieb:

Das andere: eine Liste nimmt nur Objekte auf. Ein "int" ist kein Objekt, deshalb muss er verpackt werden (und dazu verwendet man die Klasse "Integer").

das ist mir klar, deswegen hab ich auch von geschwindigkeitsverlust geredet.

mal was anderes: für wieviele platformen gibt es eigentlich eine jvm die java5 unterstützt? 3?

[Gast]

borg schrieb:

ja ich hab gesagt Qt malt selbst [...]

Kannst du das belegen? Wäre mir echt neu.

brigens auf der gleichen seite 2 zeilen drunter:

http://www.trolltech.com/products/qt/index.html schrieb:

Qt requires no "virtual machines" or emulation layers. It writes directly to low-level graphics functions, just like native apps do. So Qt applications run at native speed.

Hihi.

Was willst du mir damit sagen? Ich hab ja nicht behauptet, dass man für Qt ne VM braucht, oder? Aber wenn du dich einfach nur freust, dass du keine brauchst, dann lass uns feiern.
Oder deutest du den Satz so, dass Widgets gemalt werden? Das kann ich daraus aber nicht entnehmen.

[borg]

Optimizer schrieb:

Was willst du mir damit sagen?

Optimizer schrieb:

Ich hab ja nicht behauptet, dass man für Qt ne VM braucht, oder? Aber wenn du dich einfach nur freust, dass du keine brauchst, dann lass uns feiern.

ne, den ersten satz hab ich nur der vollständigkeitshalber mit reingemacht.

Optimizer schrieb:

Oder deutest du den Satz so, dass Widgets gemalt werden?

ja

edit:

zitat aus nem anderem forum, was besseres finde ich nicht schrieb:

Qt zeichnet die Widgets unter Windows selbst. IOW, die ganzen Widgets werden mit den Qt eigenen Canvas Klassen, etc. gezeichnet.

Das hat den Vorteil, dass auf den diversen Plattformen nur die Canvas Klasse mit Hilfe der OS spezifischen Grafikfunktionen implementiert werden muss.

Allerdings sehen Qt basiert Programme wirklich *genau* so aus, wie native Windows Programme. Es werden sogar Windows XP Themes unterstützt, wie das genau funktioniert, weiß ich aber nicht.

[Gast]

borg schrieb:

mal was anderes: für wieviele platformen gibt es eigentlich eine jvm die java5 unterstützt? 3?

Für so viele Plattformen, für wieviel es schon immer eine JVM gegeben hat.
Das mit dem boxing ist natürlich ärgerlich. Dumm, dass Java überhaupt primitive Typen hat. Wenn es so etwas nicht geben würde, wäre Java designtechnisch noch ein gutes Stück besser. Aber irgendwann hat man dann doch mal auf die Performance geschaut.
Und deshalb gibt's jetzt ne Menge Overloads für sort. Sowas suckt. Das ist in C# einfach besser gelöst. Also wenn schon kritisieren, dann bitte echte Kritikpunkte bringen. Aber das ist eigentlich auch nur, weil Arrays nicht generisch sind.
Und natürlich ist es Schnee von gestern. Wenn's nicht grad absolut performance-kritisch ist, kann man ja sowas nehmen:

public static <T> void sort(List<T> list, Comparator<? super T> c)

und die Welt ist wieder heile. Und das geht in gewissen anderen Sprachen schon wieder nicht so schön (Anmerkung: List<T> ist ein Interface). Es gibt in jeder Sprache Dinge, die mich aufregen, die Welt ist irgendwie nicht für mich gemacht.

[borg]

Optimizer schrieb:

Und deshalb gibt's jetzt ne Menge Overloads für sort.

lol, wie geil ist das denn

[terraner]

lach schrieb:

Warum hat sich Windows damals gegen Unix durchgesetzt? Es wurde anfangs von Guru's auch nicht für voll genommen, was ist daraus geworden?

*lol*
was für ein vergleich.
windows wird auch jetzt nicht für voll genommen.
für mehr informationen kontaktieren sie bitte eine suchmaschine ihrer wahl.

mfg