[Perfromance Benchmark] Java - C++

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.

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.

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?

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.

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

Power Off

JBeni schrieb:

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

Bei kleineren Programmen, wie z.B. Spielen, ruckelt's ziemlich uebel. Hab's irgendwann aufgegeben. Auch die Reihenfolge in der Threads drankommen, ist ziemlich bescheuert, d.h. einige kommen oefter dran als andere, auch wenn sie dasselbe machen. Ebenfalls toedlich fuer Spiele.

Bei grossen Programmen mit mehreren hundert Millionen Objekten ist ganz einfach der Kanal voll. Da dauert die Garbage Collection dann mehrere volle Sekunden. Das ist einem Anwender nicht mehr zumutbar. (Beispiel: Anzeige einer Datenbanktabelle mit mehreren Millionen Datensaetzen, z.B. Artikel oder Buchungen; was man in C++ locker im Speicher halten kann, muss man bei Java aufsplitten -- leider beherrscht nicht jeder Java-Programmierer das Scrollen eines Datenbank-Anzeigefensters ueber dynamische SQL-Abfragen und -Cursor)

Natuerlich liegt das daran, dass Java-Entwickler auf das Freigeben von Objekten nicht achten (muessen), wodurch bei riesigen Datenstrukturen Unmengen von Objektleichen im Heap erzeugt werden.

Hab's schonmal bei einigen groesseren Anwendungen gesehen.

Mein Eindruck von Java war damals, dass es fuer den Alltag in Firmen noch nicht taugt.

Urspruenglich sollten mit Java ja nur Web-Applets und kleinere Anwendungen entwickelt werden, aber das Ganze hat ja schon wesentlich groessere Ausmasse angenommen.

Warum sind groessere IDE's wie z.B. JBuilder so langsam? Wegen dem Garbage Collector, weil er bestimmt dauernd ausgefuehrt werden muss, um das Speicherlimit nicht zu sprengen. Java-Programme verbrauchen den VM-Speicher relativ schnell, das kann bloss Sekunden dauern, bis zur naechsten Garbage Collection ...

Power Off schrieb:

Warum sind groessere IDE's wie z.B. JBuilder so langsam?

Warum sollten sie es denn nicht tun? Oben wurde doch schon festgestellt, dass es für IDEs deutlich wichtigere Dinge als die Geschwindigkeit gibt. Sonst ließe sich der Erfolg von Eclipse oder auch Netbeans wohl nicht erklären. Solange es diese wichtigeren Dinge gibt werden die Entwickler dieser IDEs wohl auch eher auf solche Dinge als auf die Geschwindigkeit achten.

Power Off

WarumNicht? schrieb:

Power Off schrieb:

Warum sind groessere IDE's wie z.B. JBuilder so langsam?

Warum sollten sie es denn nicht tun? Oben wurde doch schon festgestellt, dass es für IDEs deutlich wichtigere Dinge als die Geschwindigkeit gibt. Sonst ließe sich der Erfolg von Eclipse oder auch Netbeans wohl nicht erklären. Solange es diese wichtigeren Dinge gibt werden die Entwickler dieser IDEs wohl auch eher auf solche Dinge als auf die Geschwindigkeit achten.

Importier mal mehrere 30 MB grosse JAR-Files in JBuilder.