BCB vs VC++,C#,Delphi ----> Java doppelt so schnell wie C++ ?

[AndreasW]

hm,

letzendlich ist das Prgramm in jeder Sprache nicht optimal umgesetzt worden. War ja wahrscheinlich auch nicht Sinn der Sache. Der Autor wollte, so wie ich das sehe, möglichst identischen Code vergleichen.

Beim BCB hat er auch ne TList genommen, obwohl eine TList wohl recht wenig mit C++ zu tun hat.
(Komischerweise ist, hab ich getestet, ist im BCB die TList sogar schneller als ein vector. Das haut mich auch mal wieder von den Socken. Ist der Compiler vom BCB denn so schlecht optimniert ? Klar, mir ist bewusst, das Borland seine Energie in Delphi steckt und der BCB nur hier und da etwas Zeit abbekommt. Aber so ?)

Naja, zumindest sind alle Implementationen nicht 100% sauber. Das hat er aber auch im Artikel gesagt. Er wollt ja auch nicht optimieren sondern eine allgemeine Lösung nachgehen, die, wie er sagt, "ottonormal- Programmierer" (was immer das auch ist) anstreben würde.

Sicherlich kann man hier und da recht gut optimieren. Das kann man aber in den anderen Sprachen auch und ist bei sowas nicht ausschlaggebend denn es war ja nicht die Optimierungsfähigkeit eines Programmierers auf dem Prüfstand.

[AndreasW]

damit es übersichtlich bleibt,

sollten wir den Thread HIER weiterführen.

@Mod: Mach hier zu..

[Gregor]

kingruedi schrieb:

lass mich raten, wenn ich jetzt sage, dass Java Applikationen viel RAM verbrauchen, dann kann ich mir von dir anhören, dass das einfach daran liegt, wie Java Programmierer denken und die lieber ein sauberes Programm schreiben, anstelle RAM zu sparen?

Was das RAM betrifft, bringt Java von sich aus einen sehr großen Overhead mit. Das stimmt und das ist sicherlich auch ein Nachteil von Java.

Warum sollte jemand anders Java als C++ programmieren?

Weil sonst soetwas herauskommt, wie bei diesem Benchmark. Das C++-Programm ist dann einfach lahm!

[:p]

@Mod: Mach hier zu..

2 verschiedene Themen - 2 verschiedene Threads

[AndreasW]

in welchem Punkt ist das Thema anders?

naja, ist mir egal. Dann lasst ihn hat auf. Das stört mich doch nicht...

[Gregor]

AndreasW schrieb:

in welchem Punkt ist das Thema anders?

In diesem Thread geht es in erster Linie um den c't-Benchmark. Im anderen Thread wurde der eigentlich nur mal so am Rande ewähnt.

[Peter]

Das Programm ListList_BCB_VU6 hat wohl ein Delphianer geschrieben
Schon alleine das Umschreiben folgender Zeilen der Routine BuildListList genügte schon, um die Laufzeit des Programms (bBenchCreate (1 Mio Calls)) deutlich zu beschleunigen.

Ursprüngliche Codezeilen, Time 23:684

NewName="";
for(int y=1; y<=NameLength; y++)
   NewName = NewName + char((int)'a' + (rand() % 26));

Modifizierte Codezeilen, Time 10:385

NewName.SetLength(NameLength);
for(char *p=NewName.c_str(), y=1; y<=NameLength; y++)
   *p=char((int)'a' + (rand() % 26));

Die Zeiten wurden auf meinem System Pentium 800MHZ gemessen.

[.]

Peter, ich glaube dein Code ist illegal.

Du darfst den von c_str zurückgegebenen Zeiger nicht beschreiben.

[Jester]

Eigentlich sollte es schon einiges bringen einfach statt NewName = NewName + blablabla

NewName += blablabla zu schreiben.

Und wenn man wie in diesem Fall weiß wie groß der string mal wird sollte man den Speicher auch im Voraus reservieren. Das spart wertvolle Rechenzeit.

Btw:
Das beschreiben des von c_str zurückgegebenen Strings ist wirklich verboten.

MfG Jester

[Peter]

Du darfst den von c_str zurückgegebenen Zeiger nicht beschreiben

Aja, man darf also nicht dürfen. Komisch, ich hatte noch garnieüberhauptnicht Probleme damit (man muß halt ein bisserl aufpassen) Aber wenn ihr meint . Keiner kann Euch die Benutzung von Pointern aufzwingen, aber dann wäre es vielleicht sinnvoller Delphi zu verwenden. Da ist ein String ein richtiger Datentyp und keine Klasse ....

Ob man nun NewName += "Blabla" oder NewName = NewName + "Blabla" schreibt ist doch nun wirklich vollkommen egal !

[MFK]

Peter schrieb:

Aja, man darf also nicht dürfen. Komisch, ich hatte noch garnieüberhauptnicht Probleme damit (man muß halt ein bisserl aufpassen) Aber wenn ihr meint .

Da hat doch vor einiger Zeit jemand genauso argumentiert...

Spieleprogrammierer hat der sich genannt, IIRC.

[an ja]

Ob man nun NewName += "Blabla" oder NewName = NewName + "Blabla" schreibt ist doch nun wirklich vollkommen egal !

Kurz gesagt: Du hast keine Ahnung.

[Peter]

Da hat doch vor einiger Zeit jemand genauso argumentiert

Hab ich nicht mitbekommen. Es ist aber in der Tat so, wenn man rein nur String/AnsiString verwendet, kann die Anwendung langsam werden. Schaut man sich nur mal im Debugger an was passiert, wenn man ein Zeichen des Strings mit [] modifiziert, versteht man warum das so ist.
Hoffe es geht deswegen nicht wieder rund hier

[Peter]

@Anja
Okay okay, in diesem Punkt habe ich mich geirrt. Hab mich gerade davon überzeugt. Danke für Deinen Hinweis

[MFK]

Peter schrieb:

Hab ich nicht mitbekommen.

Sei froh. Dieser Spieleprogrammierer hat seine seltsamen Ansichten darüber, was richtiger Code ist, grundsätzlich damit begründet, dass das "bei ihm so funktioniert". Er wollte nicht einsehen, warum das kein Argument ist. Am Ende wurde ihm eine verdiente Merkbefreiung ausgestellt.

Schaut man sich nur mal im Debugger an was passiert, wenn man ein Zeichen des Strings mit [] modifiziert, versteht man warum das so ist.

Es ging um Schreibzugriffe über den Zeiger, den c_str() liefert. Der ist ein Zeiger auf const char. Du hast das const einfach weggecastet, und dann reingeschrieben. Das erzeugt undefiniertes Verhalten. Es ist schön für dich, dass dein Compiler da mitspielt, aber das macht den Code nicht besser.

[junix]

Jester schrieb:

Eigentlich sollte es schon einiges bringen einfach statt NewName = NewName + blablabla

NewName += blablabla zu schreiben.

? Wieso?

Jester schrieb:

Und wenn man wie in diesem Fall weiß wie groß der string mal wird sollte man den Speicher auch im Voraus reservieren. Das spart wertvolle Rechenzeit.

Das sttimmtund gilt speziell auchfür STL-Container.

-junix

[Peter]

@junix
Hab das str+="blabla" und str=str+"blabla" im Debugger angeschaut, es gibt in diesem Fall (AnsiString) tatsächlich einen großen Unterschied. Gucks Dir einfach mal an ....

[Jester]

Naja, mit += hänge ich den aktuellen String dran.
Mit String = String + bla

erzeuge ich zunächst einen temporären String, der String + bla enthält und rufe anschließend den operator= des String auf.

Ich hab jetzt auch mal ein bissel damit rumgespielt:

Gesamtlaufzeit Originalcode: 2:39,6, nachdem ich ihn überarbeitet hatte: 27.6
Und lange hab ich dazu nicht gebraucht.

Nochmal was zur Vergleichbarkeit: Klar ist es nicht nötig das alles 100% zu optimieren. Aber der Code sollte schon Vergleichbar sein, und nur weil er syntaktisch sehr ähnlich ist ist er eben nicht unbedingt auch semantisch sehr ähnlich.

public void Process(String Text);

ist in Java eben eine Übergabe per Referenz.

void Process(std::string Text); sieht zwar sehr ähnlich aus, kann aber was die Performanz betrifft selbstverständlich nicht mithalten.
Deshalb muß, damit man überhaupt vergleichen kann daraus auch ein
void Process(const std::string & Text) werden, wenn nichts triftiges dagegen spricht. Insofern halte ich die verschiedenen Programme keineswegs für vergleichbar. Aber wenn man natürlich sagt zwei Programme sind vergleichbar, wenn sie nru minimale syntaktische Unterschiede aufweisen... dann... ja, dann könnte es hinkommen.

MfG Jester

[Peter]

Übrigens, für alle denen die Pointerei in einen AnsiString missfällt, so ungefähr gehts natürlich auch, ganz ohne AnsiGedöns:

char *NewName=new char[NameLength+1];
for(p=NewName, y=1; y<=NameLength; y++, p++)
   *p='a' + (rand() % 26);
*p=0;

Entsprechende Deklarationen nicht vergessen, vor allem nicht das Freigeben von NewName am Ende der Routine.
Der Kreativität sind keine Grenzen gesetzt

[_tom_]

Benchmarks sind zum grössten Teil Quatsch, denn sie gehen
an der Realität vorbei.

Mann sieht es z.b an der Art wieviel mann schneller dieses oder
jenes implementieren kann.

Ich gehöre zu der Java Seite und habe nicht viel Ahnung von C++ aber
wenn ich sehe das mann lieber cout << nutzen sollte um hier und
da noch zu beschleunigen, oder in Java mann lieber seine LinkedList
selber implementiert um hier und da noch ein fünkchen Zeit rauszuholen,
oder nicht die Methode sort bei Collectionen nutzt, die das gewünschte
Ergebnis zwar liefert, aber für ein Benchmark lieber ein eigener
Sotieralgorythmus geschrieben wird, dann geht das um weiten an dem
Vorbei wofuer die Programmiersprache genutzt wird.

Ich nutze weiterhin [Collection].sort(); auch wenn sie eventuell
etwas langsamer ist.
Mein Chef würde mir was husten, wenn ich die Entwicklungszeit eines
Projektes verdreifache nur um im Endeffekt nochmal 10% Performance
rauszukitzeln.
Zudem wird mein Programm, umso mehr ich eigene Algorythmen darin platziere
und von dem gebotenen abweiche, schwerer wartbar.
Besonders dann wenn sich irgend ein armer Hund, noch in meine Algorythmen einarbeiten muss, nur um zu verstehen was ich damit erreichen will.

Selbst wenn Java ein bischen langsamer als C++ ist (und ich glaube
auch als Java Programmierer nicht an diesen ct Benchmark) so ist
das ziemlich schnuppe.
Die Geschwindigkeitsgrenzen sind nur in mannchen Teilbereichen
der Entwicklung spürbar.
So ist und bleibt C(++) eher die Wahl dafür den letzte Tick an
Frameraten herauszuholen.
Wenn ich Kundendaten mit einen Suchalgorythmus durchsuche und
dieser statt nach 0,3 sec nach 0.45 sec durchläuft ist dann macht
das in der Usability des Programmes nicht viel aus.

Genauso wie Programmiersprachen ihre Stärken haben, haben sie ihre
Schwächen.
So sehe ich (was andere wieder anders sehen) Swing als Schwäche Javas
an. Swing ist u.a dafür verantwortlich das viele die es einfach nicht
besser wissen, Java für langsam halten. Deshalb nutze ich lieber
SWT und JFace (Eclipse).
Swing ist zwar was die MVC Umsetzung angeht, und die Programmierbarkeit
in meinen Augen um einiges freundlicher als alles was ich davor kennengelernt
habe (inc. Qt, GTK) aber dennoch sehr gewöhnungsbedürftig was das "Feeling"
angeht. Dazu hat sich aber nach meiner Erfahrung herausgestellt das mann
sich an Swing GUIs gewöhnen kann, und einem die Performance immer weniger
stört. Auch verspricht, und scheint es auch zu halten (meinen bescheidenen
pers. Tests nach), Java 1.5 dort einige Verbesserrungen.
Dennoch sehe ich einen anderen grossen Vorteil von Java, das ist die
verrringerte Entwicklungszeit.
Ja ich traue einigen guten C++ Programmierern zu das sie auch in grossen
Projekten sämmtliche wilden Pointer verhindern zu wissen. Das es bei ihnen
nicht vorkommt das schwer zu findende Laufzeitfehler, auf grund der komplexität von C++, auftreteten.
Das Problem ist, das Firmen erstmal diese Menge an guten C++ Programmierern
finden und dann auch noch bezahlen müssen. Mitarbeiter mit einer solchen Erfahrung und Kompetenz sind relativ rar und teuer.
(Oh Gott hoffentlich dreh ich mir jetzt nicht selbst ein Strick :D) In Java ist es auch weniger erfahrenen Mitarbeitern möglich produktiv für die Firma
zu sein. Die Entwicklungskosten & Zeit vermindert sich.

Im übrigen, sorry das ich einen so alten Thread rauskrame, aber ich bin darauf gestossen und meine Meinungsaustauschdrang hält sich nicht an Alte/Neue Threads.