[Perfromance Benchmark] Java - C++

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

Marc++us

Optimizer schrieb:

Ich verstehe auch gar nicht, wie ihr dazu kommt, IDEs zu vergleichen.

Naja, wir versuchen halt reale Anwendungen zu vergleichen, und da bietet es sich für Softwerker eben an, ihre reale Anwendung "IDE" zu vergleichen. Und ich kenne keine Java-Excel... sonst hätte ich das genommen.

Optimizer schrieb:

Java IDEs haben Sachen, von denen andere IDEs nur träumen können.

Und das wäre? Z.B. Eingabe von Zeichen ohne Latenzzeit?

Ich verstehe weder das Featureargument, noch das Architekturargument. Wieso dauert das Syntaxcoloring bei einer Java-IDE beim Neuzeichnen, wieso scrollt das Ding so lahm, und warum dauert die automatische Codeergänzung solange? Durch eine Plugin-Schnittstelle wird sowas doch nicht langsamer... während ich tippe, ist doch außer der Tippse nix wirklich aktiv.

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ich weiß ja, daß in dem ganzen Servlet-Bereichen die Java-Anwendungen sich durchgesetzt haben und flott sind, aber bei den größeren Anwendungspaketen mit GUIs bin ich nicht überzeugt.

Ich verstehe weder das Featureargument, noch das Architekturargument. Wieso dauert das Syntaxcoloring bei einer Java-IDE beim Neuzeichnen, wieso scrollt das Ding so lahm, und warum dauert die automatische Codeergänzung solange?

Sorry, aber das ist halt bei mir einfach nicht so, falls sich das auf Eclipse bezieht. Für Netbeans kann ich auch sprechen. Sonst hab ich mir wohl zu wenig Java-IDEs angeschaut.

während ich tippe, ist doch außer der Tippse nix wirklich aktiv.

Das stimmt zwar zumindest bei Eclipse nicht (/me Plugin-Schreiber), aber ist trotzdem auch kein Problem. Wie gesagt, ich kann das in dem Maße wie du das beschreibst nicht nachvollziehen.
Die einzige IDE, die ich kenne und mit dem Syntaxcoloring nicht hinterherkommt ist die Visual C# 2005 Express Beta. Wenn ich da ne Datei öffne, ist sie erstmal 10sec nicht gecolort.
Hast du ne Java 5.0 VM? Zumindest 1.3 ist wirklich noch sehr langsam.

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Und ich kenne keine Java-Excel... sonst hätte ich das genommen.

OpenOffice ist AFAIK zu einigen Teilen in Java geschrieben, ich kann aber jetzt nicht sagen, welche Teile.

dEUs

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ponto

Power Off schrieb:

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";
}

Diese Schleife dauert bei mir 5.5 Sekunden. Aber man kann ja was machen.

Ich würde behaupten, folgendes sei schneller:

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

Das dauert nur noch 4.5 Sekunden. Aber die ganzen Stringfunktionen machen bestimmt viel zu viele Checks. Das kann man doch direkter, wir wissen ja was wir wollen:

char hallo[] = "Hallo\n";
int const size = strlen(hallo);
string s(size * n, 0);
std::string::iterator iter = s.begin();
for ( int i=0; i != n; ++i ) {
   for (int j = 0; j != size; ++j) {
      *iter = hallo[j];
      ++iter;
   }
}

Und siehe da, das Programm benötigt nur noch 0.4 Sekunden.
Was kann man daran sehen:

1. In C++ gibt es viele Wege das gleiche Ergebnis zu erreichen. Wahrscheinlich gilt das auch für Java.

2. So ein Benchmark kann nicht viel aussagen. Ziel der Messung war wahrscheinlich die Geschwindigkeit von String appends, weshalb die letzte Transformation nicht akzeptabel wäre. Der Programmierer will aber ein Ergebnis erreichen. Mal will er schnell zum Ergebnis kommen, mal will er ein schnelles Ergebnis haben. Sollte jemals eine solche Schleife in einem realen Programm notwendig sein, kann sie je nach Ziel des Programmierers so einfach, wie im ersten Fall oder so kompliziert wie im letzten Fall aussehen. Über beide Fälle sagt der Benchmark jedoch nichts aus, da er etwas misst, dessen Geschwindigkeit völlig unerheblich ist. Denn ist die Geschwindigkeit an dieser Stelle das Nadelöhr, fällt dem Programmierer schnell etwas besseres ein.

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ist es jetzt völlig ausgeschlossen, dass es einfach schlecht programmiert ist?

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Woran liegt es das C/C++ Anwendungen Bufferoverflows haben? Natürlich an C++

Welche VM benutzt ihr? Die 1.4.2 und erst recht die 1.5 sind _viel_ schneller als zum Bleistift die 1.3. Ich rede nur von Sun VM's!

Wie schon erwähnt hat Java auch weniger das Ziel auf dem Desktop als vielmehr auf dem Server. Da ist es dank AS und EJB sehr schnell!

Sovok

Optimizer schrieb:

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ist es jetzt völlig ausgeschlossen, dass es einfach schlecht programmiert ist?

dass java desktop-anwendungen in dem ruf stehn träge zu sein is auch ned ganz von der hand zu weisen

dEUs

Optimizer schrieb:

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ist es jetzt völlig ausgeschlossen, dass es einfach schlecht programmiert ist?

Können alle Javaprogrammierer jetzt plötzlich nciht mehr programmieren?

Was ich damit sagen will:
Ich finde es doch recht seltsam, dass alle Applikationen, die bei mir so ultralahm waren, bisher alle in Java geschrieben waren. Du willst doch nicht den ganzen Entwicklern einfach Versagen vorwerfen?

Ich finde eure Argumentation so klein-klein. Es liegt an der Architektur, an diesem und jenem, aber um Gottes Willen nicht, kein Stück, an Java.

Entwickler schrieb:

Woran liegt es das C/C++ Anwendungen Bufferoverflows haben? Natürlich an C++

In der Tat liegt das ein stückweit an C++, da es dem Entwickler die Möglichkeit gibt, Bufferoverflows einfach zu produzieren. Genau so scheint es mir mit Java zu sein: Es gibt dem Programmierer die Möglichkeit, einfach lahme Anwendungen zu schreiben.

JCreator is written entirely in C++, which makes it fast and efficient compared to the Java based editors/IDE's.

dEUs

richtiges zitat schrieb:

JCreator is written entirely in C++, which makes it fast and efficient compared to the Java based editors/IDE's.

Danke für's raussuchen, ich meinte aber ein anderes:

<a href= schrieb:

http://www.jcreator.com/faq.htm#52">
Will JCreator be released for other platforms? Will there be a Java version?

The very first version (0.1) of JCreator was a Java version, but we switched to C++, because of performance issues.

Ist natürlich in der Grundaussage das gleiche.