[Perfromance Benchmark] Java - C++

borg schrieb:

was ist eigentlich der unterschied zwischen "server JVM" und "client JVM"? die "client JVM" ist eigentlich immer langsamer als alle anderen.

Die Server VM ist auf hohe "Throughput"-Performance optimiert, während die Client VM auf geringe Latenzzeiten optimiert ist.
Beispielsweise benutzt die Server VM einen sehr viel größeren Heap, so dass eine volle Garbage Collection schon mal ne Sekunde dauert anstatt ein paar ms. Dafür wird insgesamt der GC sehr viel seltener ausgeführt und letztlich wird insgesamt weniger Zeit mit GC verbracht als bei der Client VM.
Der JIT-Compiler hat außerdem eine bessere dynamische Optimierung und sehr viel höhere Compilierzeiten im Gegenzug.

Letztlich lohnt sich die Server VM nur bei lange laufenden Programmen (per Parameter einstellbar), ich kann mir aber durchaus vorstellen, dass der Server-JIT einige C++ Compiler gut schlagen kann, weil er sich zur Compilierung schon die Zeit nimmt, die er für richtig hält, was normalerweise bei JIT-Compilern das Problem ist. Und die dynamische Optimierung kann einiges bringen, was bei C++ zur Zeit brach liegt (ma gucken, ob Whidbey VC++ mit der "profile guided optimization" da abhilft).
Solche generellen Aussagen sind aber IMHO trotzdem Unsinn.

Gerard

borg schrieb:

was ist eigentlich der unterschied zwischen "server JVM" und "client JVM"? die "client JVM" ist eigentlich immer langsamer als alle anderen.

bei server jvm vergleichst du antwortzeiten usw.,
bei client jvm vergleichst du swing-gui mit nativer-gui antwortzeiten

und bei vielen benchmarks (ohne gui) hat java schon bewisen das es c++ das wasser reichen kann

Also sagen wir der Test ist Schrott. Man soll immer nach Einsatzgebieten die Sprache wählen. Wo liegen dann eurer Meinung die Einsatzgebiete von Java und C++?

Artchi

Die Tests sind schrott - basta. Am besten diesen Thread hier schliessen, die ewigen Java vs. C++ Threads nerven.

borg

wtf? könnt ihr mal so reden das ichs verstehe? nachdem ich bei optimizers post erst herausfinden musste was 'Throughput-Performance' und 'Latenzzeit' meint, verstehe ich dein posting gar nicht.

Gerard schrieb:

bei server jvm vergleichst du antwortzeiten usw.,
bei client jvm vergleichst du swing-gui mit nativer-gui antwortzeiten

die server jvm ist für console und die client jvm für gui oder was willst du mir damit sagen?

Gerard schrieb:

und bei vielen benchmarks (ohne gui) hat java schon bewisen das es c++ das wasser reichen kann

... ich ess halt lieber birnen als äpfel.

Gerard

vergiss mein post, habe an was andes gedacht

Inf. Stud. schrieb:

Wo liegen dann eurer Meinung die Einsatzgebiete von Java und C++?

Du brauchst dir nur die Standardbibliotheken der Sprachen ansehen, dann weißt du sehr schnell, wo deren Einsatzgebiete liegen bzw. auf Dauer liegen werden. In der Standardbibliothek und in den Sprachfeatures von C++ fehlt ziemlich viel, was bei der Anwendungsentwicklung benötigt wird. Man will in der Standardbibliothek ja nichts haben, was nicht bei allen Plattformen Sinn macht, also nimmt man auf den berüchtigten Toaster Rücksicht und wundert sich dann irgendwann, wenn das Einsatzgebiet der Sprache auf solche Toaster und ähnliche Dinge zurückgedrängt wird.

C++ hatte lange Zeit einen erheblichen Vorteil gegenüber Java, was die Performance betrifft. Da hat C++ auch immer noch einen gewissen Vorteil, der aber ziemlich geschrumpft ist. Früher war C++ gegenüber Java um einen Faktor 50 oder so schneller und heute ist es vielleicht im Großen und Ganzen noch Faktor 2, 3 oder vielleicht sogar 4, wenn man einen guten C++ Programmierer hat, der entsprechenden Aufwand in den Code steckt. Es gibt Bereiche, in denen das noch ein ganz erheblicher Vorteil für C++ ist. Die Spieleprogrammierung ist beispielsweise so ein Bereich. Für die Anwendungsentwicklung ist es aber oft nicht so wichtig, noch das letzte aus dem Computer rauszuholen. Heutige PCs bieten so viel Rechenleistung, dass dieser Vorteil von C++ gegenüber Sprachen wie Java oder auch C# kaum mehr ins Gewicht fällt und die PCs werden sicherlich nicht langsamer. In naher Zukunft kommen stattdessen Prozessoren mit mehreren Kernen auf den Markt, die wohl in ein paar Jahren üblich sein werden. Da macht sich eine Sprache, die von sich aus keinerlei Unterstützung für Threads liefert nicht besonders gut.

@Inf. Stud.: Was dir dein Professor da geschrieben hat, hat trotz der Tatsache, dass man so ziemlich jeden Benchmark runtermachen kann, einen wahren Kern. Sicherlich kann man sowohl bei den Javaprogrammen als auch bei den C++ Programmen, die dort verglichen wurden, noch etwas rausholen und bestimmt ist das im C++ Fall auch mehr als im Javafall. Die Realität ist aber, dass nicht jeder Programmierer die von ihm genutzten Sprachen bis ins letzte kennt und darauf achtet, alle Probleme zu umschiffen. Nimm einen Programmierer, der mit beiden Sprachen mittelmäßige Erfahrung hat, dann kann so ein Code durchaus dabei herauskommen. Der Javacode kommt da dann eher an das Java-Optimum heran, weil die Sprache einfacher gehalten ist und man insgesamt weniger falsch machen kann. Beim C++ Code ist das genau andersherum: Die Sprache ist kompliziert und es gibt allerlei Dinge, die man beachten und kennen muss, wenn man schnellen Code schreiben will. Man muss für C++ mehr Zeit investieren, um auf ein Level zu kommen, auf dem man guten Code produziert. Bei Java hat man so ein Level schneller erreicht.

Wenn du also angewandte Informatik studierst, dann ist eine Sprache wie Java oder C# in der Ausbildung besser als C++, auch wenn C++ geringfügig schneller sein kann. Bis du im Beruf bist, wird C++ nahezu keinerlei Bedeutung für die Anwendungsentwicklung mehr haben. Das liegt auch an der unglaublich langsamen und zähen Entwicklung von C++. Wenn man da 10 Jahre benötigt, um einen Standard herauszubringen und dann vielleicht nochmal 10 Jahre für den nächsten, dann sollte man sich mal überlegen, ob man in dieser schnelllebigen IT-Branche richtig ist. (Jetzt kommen gleich die C++ Jünger und erzählen dir, dass man eine schnelle Entwicklung von C++ nicht erwarten könne, da dort keine Firma wie MS oder Sun hintersteht, die die Entwicklung vorantreibt. Und? Pech! Dann war es das halt für C++.)

Korbinian

schon mal überlegt, dass c(++) und java auch nur mit wasser kochen? ein a++ oder 3+4 ist in java genauso schnell wie in c(++). eine vm macht auch nur eine maschinencode umsetzung. ich bin durchaus der meinung, dass sich die sprachen in geschwindigkeit nichts schenken, weil sie in den fast gleichen asm codes enden. also wenn ich algorithmen nehme, und jeweils über die "normalen" zugriffe gehe (z.b. konventioneller array index), werden die sprachen wohl fast gleich schnell sein. zeitfaktoren sind nur die GC bei java, und so spracheigenschaften wie pointerarithmetik, die man sich bei manchen datenalgorithmen zunutze machen kann. aber auch java bietet solche vorteile (siehe z.b. dieser hashmap vergleich). nagut, die vm braucht etwas zum abstarten, aber das ist auch schon alles.
die zeiten in denen java langsam ist, die sind vorbei, definitiv. wenn ihr alle so an eclipse rumheult. schaut mal an, wie es aufgebaut ist und was es alles kann. das dings besteht nur aus plugins. mach sowas mal mit c(++) möchte sehn, wie das dings läuft...

Marc++us

Korbinian schrieb:

die zeiten in denen java langsam ist, die sind vorbei, definitiv. wenn ihr alle so an eclipse rumheult. schaut mal an, wie es aufgebaut ist und was es alles kann. das dings besteht nur aus plugins. mach sowas mal mit c(++) möchte sehn, wie das dings läuft...

Naja, ich war von Eclipse geschockt. Ich habe ein bißchen Midlets für mein Handy programmiert und mir dafür Eclipse installiert, das ist ja ein Witz. Auf einem 2.4GHz-Rechner laggt die Eingabe mit Syncol teilweise, und wenn man die "Was gibt es für Parameter"-Hilfe im Editor (z.B. für Parameter, etc) aufmacht, kann man erst Mal Kaffee trinken gehen... ich weiß nicht, was man da für ein System braucht, damit es flüssig läuft.

Und wenn Du eine IDE aus lauter Plugins bestehend sehen willst, die RAST, dann schau Dir den VC7 an. Guck Dir mal an, wie da im Editor die direkte Hilfe für den Syntax aufmacht fliegt einem die Box entgegen (auf dem gleichen PC). Und das Ding besteht auch nur aus COM-Objekten, die über eine Menüleiste verzahnt sind, und man kann ebenfalls eigene Plugins einbinden.

Abgesehen davon sehe ich noch nicht, wieso die Möglichkeit von Plugins zu hohen Latenzzeiten beim Tippen führen darf.

Auf jeden Fall war ich maßlos enttäuscht. Dachte der JBuilder wäre lahm, aber Eclipse...

phlox81

Ich denke das technische Dinge wohl nicht entscheiden werden,
was sich auf dem Massenmarkt durchsetzt. Windows zeigt ja,
das man mit Marketing weiter kommt, als damit Qualität.
Hinter Java steht Sun, und Sun kann in den Bereichen,
in denen die Entscheidung für Firmenweite Softwareentwicklung
getroffen wird, mit argumenten punkten, wie Plattformunabhängigkeit,
flexiblilität und eben solchen Studien wie sie hier gepostet wurden.
Das beeindruckt die Leute, und die jenigen die die Entscheidungen
treffen, haben vielleicht mal C oder Cobol programmiert, haben
aber keine Ahnung von Softwareentwicklung. Zu dem kann man mit
Eclipse auch noch ein kostenloses Tool für die Entwicklung nutzen.
Für C# gilt ähnliches, da ist MS, und auch sie bieten den
Support den Sun bietet, und mit Mono wird C# auch noch Plattformunabhängig,
irgendwann.
C++ dagegen ist eine Freie Sprache, kein Produkt einer Firma wie Java
oder C#, von daher gibt es auch keine grosse Firma/Organisation die
es bewirbt, bzw. verkauft. Ich glaube das das ein Nachteil für C++ ist,
denn langfristig entscheidet auch Marktmacht über das für und wieder einer
Sprache. Man kann nur hoffen das bald der neue Standard kommt, und somit
es evtl. auch eine erweiterte STL gibt, die mehr kann als ein Toaster braucht...

Devil

Power Off

Nur zu dem geposteten C++ Benchmark:

Der Entwickler dieses Codes hat nicht die geringste Ahnung von der STL.

Der Code muesste naemlich so aussehen:

string s;
for ( int i=0; i < n; ++i ) {
   s += "Hallo\n";
}

Was Java betrifft: Das Design der HotSpot-Engine (siehe HotSpot-Patent-Beschreibung), sowie des virtuellen Maschinencodes der JVM, legen die Vermutung nahe, dass die Designer niemals einen Blick in ein Buch ueber Compilerbau geworfen haben (z.B. Aho/Sethi/Ullman's "Compilers"). In "Compilers", beispielsweise, wird ganz klar gesagt, warum stackbasierter Zwischencode (der ja einem VMC aehnlich ist) sich schlecht optimieren laesst. D.h. solange sich das Design der Java VM nicht grundlegend aendert, wird Java niemals die gleiche Performance wie C oder C++ erreichen, nicht mal annaehernd. Ausserdem muss man bedenken, dass etlicher Code der JRE native in C++ geschrieben ist, wodurch Unzulaenglichkeiten der VM kaschiert werden. Schnelle VMs gibt es z.B. von Martin Richards (Universitaet Cambridge UK), dem Erfinder der Sprache BCPL, die ja Vorgaenger von C war. Seine INTCODE und CIntCode Maschinen sind wesentlich schneller als Java, obwohl interpretiert. Und das schon seit den 60er/70er Jahren. Richards ist uebrigens der Pionier portablen Compilerbaus. BCPL war die erste Sprache mit portablem Compiler.

Korbinian

ich will ja nicht unken, aber einer der hauptentwickler des javacompiler lehrt jetzt bei uns an der uni compilerbau und ist führender forscher/entwickler bei java-party (integriertes verteilen von anwendungen). und die vm optmiert recht gut afaik (und optimiert wird eh nicht im zwischencode, sondern bei der erstellung desselben...)

@marcus: jau, die vc7 gui ist fett, ich bin auch n riesen fan von. nur für java is t halt eclipse das einzig vergleichbare ausserdem: vc7 pumpt halt einfach mal alle namen in den speicher, da ist ein zugriff natürlich schnell im unterschied zu vc7 codevervollständigung, haste bie eclipse gleich noch den entsprechenden javadoc teil mit im popup. könnte mir vorstellen, dass die garbage collection etwas am tempo zieht
wobei bei mir eclipse eigentlihc sehr flott ist, wenns mal gestartet ist (auch die codevervollständigung)

(und die vervollständigung für eigenen code ist bei vc7 recht buggy. also zumindest hatte ich da einige probleme mit)

Sovok

lol son unsinn der vergleich

@Marc++us: Eclipse 3.1 hat schon eine wesentlich bessere Performance. Eclipse sucht sich beim Start erstmal alle Plugins zusammen, die in den Unterverzeichnissen liegen, dafür kann man ein Plugin äußerst einfach hinzufügen und entfernen.
Ich habe, sobald der Start überstanden ist, eigentlich keine Probleme mehr.
Das Ganze ist gegenwärtig sicher auch noch nicht so toll implementiert, 3.1 ist ja schon, wie gesagt, wesentlich besser.

Auf jeden Fall wird es immer wieder schön als Paradebeispiel für langsames Java hergenommen, was einfach Unsinn ist. Es ist langsam unspannend, immer wieder zu erklären, dass Eclipse nicht wegen Java lahm ist, sondern wegen seiner Architektur (und vielleicht deren Implementierung).

Korbinian schrieb:

und optimiert wird eh nicht im zwischencode, sondern bei der erstellung desselben

Sicher??
Das würde mich jetzt ehrlich gesagt, überraschen. Dann wäre es nämlich schon wieder entscheidend, ob ich jetzt den godlike Eclipse-Compiler nehme oder den javac. Außerdem sind doch manche Optimierungen auf Maschinencode-Ebene (#define Maschinencode Bytecode der virtuellen Maschine) einfacher zu machen.

Shade Of Mine

Korbinian schrieb:

vc7 pumpt halt einfach mal alle namen in den speicher, da ist ein zugriff natürlich schnell

und trotzdem quasi kein speicher verbrauch!

hatte zwar nie probleme mit intellisense, aber dank VisualAssist brauch ich es auch nicht

muss mir irgendwann mal die neue Version kaufen, es wird ja immer geiler

die einzige Java basierende IDE die ich wirklich verwende ist ZendStudio (seit 2.0). da merkt man, dass Java merklich schneller wird - dennoch ist ZendStudio 4 wesentlich lahmer als VC7 (kann aber nur einen Bruchteil).

Vorallem das Starten ist viel zu lahm Bei diesen kleinen Benchmarks fällt es vermutlich nicht ins Gewicht, aber wenn erstmal ein paar MB Code gejittet werden müssen, dann wirds lahm. zB habe ich .php Dateien nicht mit ZendStudio verknüpft, weil wenn ich mir den Code nur mal kurz ansehen will ist die Startzeit von ZendStudio zu lang.

Beim VC7 hingegen habe ich da keine Probleme...

und ZendStudio ist nicht Pluginbasiert

Marc++us

Ok, dann nehme ich Suns "Java Studio" als weiteres Beispiel für eine quälend langsame IDE.

Marc++us schrieb:

Ok, dann nehme ich Suns "Java Studio" als weiteres Beispiel für eine quälend langsame IDE.

Java IDE's haben auch idr. eine andere Architektur, weshalb die Vergleiche hinken.

Aber Java wird nicht so schnell sein wie c++. Bei solchen winzigen Programmen läßt sich keine vernüftige Aussage treffen.

Java hat eine ganz andere Stärke, die weder Perfromance noch Plattformunabhängigkeit ist.

Java ist die Sprache der Wahl der für verteilte Systeme und Webservices. Nicht zuletzt da die Großen in dieser Branche alles auf Java setzen. Die großen Unternehmen in der Welt setzen nun mal immer mehr auf mehrschichtige Architekturen. Da ist für c++ der leider Zug abgefahren. Die Gründe sind zum einem ein unzulänglicher Standard und zum anderen fehlen IT-Größen die es Pushen. IBM/SAP setzen auf Java, MS auf .NET. Da bleibt auf Dauer für iso c++ nichts mehr übrig.

@toaster:

Da der KDE jetzt auf Windows portiert wird und Qt auch für Windows unter der GPL steht, dürfte c++ noch einmal einen Stoß geben.

Diese Vergleiche gab es früher genauso mit PHP. PHP ist zu langsam hier, PHP ist zu langsam da und was ist heute daraus geworden?

dEUs

An Java-Programmen habe ich bisher ZendStudio und Borlands TogetherSolo benutzt.
ZendStudio ist lahm, Together ist schrecklich. Da ist einfach alles lahm. Der Hammer. So etwas hab ich bisher wirklich nur bei Java-Programmen gesehen, noch nciht bei einem C++-Programm.
Ich bin eindeutig kein Fan von Javabasierten Programmen.
Noch was zu diesem Thema: Auf der Homepage des JCreators (IDE für Java) steht irgendwo sinngemäß: Sie haben Java nicht für die IDE verwendet, weil es einfach zu lahm war.
Wer ständig behauptet, das liegt nicht an Java, sondern an der Architektur, der mag sich meiner Meinung nach die Wahrheit nicht so wirklich eingestehen: Wenn es die Architektur einem so viel schwieriger macht performante Programme zu schreiben, obwohl es (anscheinend) mit der Sprache an sich durchaus möglich wär, dann ist das trotzdem die Schuld der Sprache. In diesem Fall eben der schlechten Architektur.

Ne. Allein der Unterschied Eclipse 3.1M4 <-> 3.0 sagt mir wirklich alles.
Und Netbeans hat auch keine schlechte Performance. Ich verstehe auch gar nicht, wie ihr dazu kommt, IDEs zu vergleichen.
Java IDEs haben Sachen, von denen andere IDEs nur träumen können. Es gibt für keine Programmiersprache so gute IDEs wie für Java. Das ist das absolute Paradebeispiel für "mein Apfel ist schneller als deine Birne".