BCB vs VC++,C#,Delphi ----> Java doppelt so schnell wie C++ ?
-
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?
Ich glaube kaum, dass sich C++ und Java Programmierer stark von einander unterscheiden. Ich meine, es programmieren sehr viele C++ Programmierer auch Java und natürlich auch umgekehrt und dann sind die Sprachen recht aehnlich. Warum sollte jemand anders Java als C++ programmieren?
Vielleicht sollte man mal messen, wie lang die JRE fuers Jitten brauch (aber bitte nicht wieder auf die dumme idee kommen ein Hello World zu nehmen und dann erzaehlen zu wollen, dass die JRE nur 0.xy ms braucht
)
-
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.
-
-
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!
-
@Mod: Mach hier zu..
2 verschiedene Themen - 2 verschiedene Threads
-
in welchem Punkt ist das Thema anders?
naja, ist mir egal. Dann lasst ihn hat auf. Das stört mich doch nicht...
-
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.
-
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.
-
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
-
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 !
-
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.
-
Ob man nun NewName += "Blabla" oder NewName = NewName + "Blabla" schreibt ist doch nun wirklich vollkommen egal !
Kurz gesagt: Du hast keine Ahnung.
-
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
-
@Anja
Okay okay, in diesem Punkt habe ich mich geirrt. Hab mich gerade davon überzeugt. Danke für Deinen Hinweis
-
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.
-
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
-
@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 ....
-
Naja, mit += hänge ich den aktuellen String dran.
Mit String = String + blaerzeuge 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
-
Ü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