[Perfromance Benchmark] Java - C++
-
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.
-
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.
-
-
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
-
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.
-
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.
-
Power Off schrieb:
Importier mal mehrere 30 MB grosse JAR-Files in JBuilder.
Habe ich nicht. Ist ja schon alles in der Standardbibliothek drin. Wer braucht da schon mehrere externe Jars?
-
Importier mal mehrere 30 MB grosse JAR-Files in JBuilder.
LOL. 30 MB vom winzigen Bytecode. Das komplette Java API hat knapp über 30 MB. Du hast natürlich auch solche kleinen Bibliotheken wie das komplette Java API. Mehrere.
Was für ein Quatsch, man.
-
Ich war mal in einem Team, das Call-Center-Loesungen in Java (mit J2EE, EJB usw.) entwickelt hat. Die kompletten JAR-Files waren etwa 150 MB gross (einzeln ca. 30 MB jedes). Da haben ca. 60 Leute dran entwickelt (ca. 50-60 Mannjahre).
Fuer den JBuilder waren natuerlich auch die Source-Files in den JAR-Files enthalten.
Ich hab damals allein nur die Doku geschrieben, die hatte ca. 1500 Seiten. Teilweise musste ich Generatorprogramme schreiben um die Doku teilautomatisch erzeugen zu koennen, sonst wuerde ich heute noch daran arbeiten!
-
Power Off schrieb:
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.
@Power Off
Ich hab sowas noch nie erlebt (ich arbeite auch mit Progis die Millionen von Objekten haben), aber man soll ja offen für neues sein...Du hast leider recht, dass viele Java-Programmierer ziemlich verschwenderisch mit dem Speicher umgehen. Das wird einem ja in allen *Büchern und Unis so beigebracht... Ich hab selbst erst spät bemerkt, dass man auch mit Java ein bisschen aufpassen muss, was man macht.
(* das grösste Problem von Java sind die vielen Studenten mit ihrem Halbwissen...)
-
terraner schrieb:
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.Endlich sagt es mal einer!
Java mag zwar schön und toll sein, es mag sich vielleicht sogar unter Windows ein festes Standbein holen, aber unter UNIX/*BSD/Linux wird Java oder erst recht das Konkurrenzprodukt kaum bis weniger akzeptiert.
Wozu auch?@borg: Ein gutes Bsp. für Qt ist der KDE. Er läuft flott und ich kann jederzeit mein Theme wechseln.
Qt für C++ 0x
-
Es gibt auch Benchmarks die etwas anderes zeigen
-
Warum sind groessere IDE's wie z.B. JBuilder so langsam?
Das liegt daran, wie die Programmierer eingestellt sind. C++-Programmierer haben immer und überall Geschwindigkeit im Hinterkopf. Java-Programmierer denken immer nur daran sauber zu designen.
Beispiel:
void foo(std::string bar) { ... }Dann ein Dialog zwischen jemandem, der schon länger mit C++ arbeitet und dem Programmierer dieses Code-Stücks (so in etwa):
- Es ist in C++ üblich den String als konstante Referenz zu übergeben.
> Aha. Und warum?
- Weil es deutlich schneller geht. So muss jedes mal der komplette String übergeben werden.
> Ja und? die Funktion wird doch nicht an Performance-kritischen Stellen eingesetzt.
- Normalerweise gewöhnt man sich einfach an alles außer die nativen Typen als konstante Referenz zu übergeben.
> Find ich doof. Das ist doch total unübersichtlich. Das würde ich nur machen, wenn ich merke, dass es ein Flaschenhals im Programm ist. So kann man das doch viel besser lesen.
...Viele C++-Programmierer drehen schon fast durch, wenn sie so einen Code sehen. Viele Java-Programmierer sehen überhaupt keinen sinn darin.
Ich fand dieses Gespräch auf jeden fall interessant.
-
Normalerweise gewöhnt man sich einfach an alles außer die nativen Typen als konstante Referenz zu übergeben.
[...]
Viele Java-Programmierer sehen überhaupt keinen sinn darin.In Java werden alle nicht-primitiven Typen per Referenz übergeben und dieses Verhalten lässt sich nur durch explizites clonen ändern. Ich kann deshalb nicht ganz nachvollziehen, wie das jetzt gemeint ist.
-
JBeni schrieb:
(* das grösste Problem von Java sind die vielen Studenten mit ihrem Halbwissen...)
Selber! :p
-
HalbwissenderStudent schrieb:
JBeni schrieb:
(* das grösste Problem von Java sind die vielen Studenten mit ihrem Halbwissen...)
Selber! :p
Ist doch so, die dümmsten Fragen (und der schlimmste Code) kommen immer von Studenten :p (guck mal in ein Java-Forum ;))
(Ach ja, ich bin ja selbst Student. Mist, hm, *Ausred such* aber ich stelle keine Fragen :p ).
-
JBeni schrieb:
Ist doch so, die dümmsten Fragen (und der schlimmste Code) kommen immer von Studenten :p (guck mal in ein Java-Forum ;))
(Ach ja, ich bin ja selbst Student. Mist, hm, *Ausred such* aber ich stelle keine Fragen :p ).
Das erklärt deinen schlimmen Code :p
-
Benckmark schrieb:
Es gibt auch Benchmarks die etwas anderes zeigen
Zumindest für einige viele Sprachen mehr und scheinbar auch seriöser.
Von manchen Sprachen hab ich noch nix gehört, aber scheinbar schnell...
