[Perfromance Benchmark] Java - C++
-
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...
-
interpreter schrieb:
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
Mein Code ist schön wie eine klare Frühlingsnacht! Werde konkret, oder schweige für immer
-
JBeni schrieb:
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 ).
naja vieleicht liegst irgendwie darann, dass studenten noch in der ausbildung sind
