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

[Gregor]

MaSTaH schrieb:

Hauptsache Delphi und Java schneiden gut ab.

Java hat in dem Artikel überhaupt nicht gut abgeschnitten. Zudem wurde im Artikel eine Menge Unwahres über Java gesagt. Zum Beispiel wurde behauptet, es gäber kein "JWord". Als was bezeichnen die denn dann die Einzelprogramme von ThinkFree Office? Es wurde auch behauptet, Methoden wären in Java immer virtuell. Kennen die nichtmal das "final"-Schlüsselwort?

[Gregor]

kingruedi schrieb:

BTW. gibt es natuerlich auch C++ Software, die lange zum laden braucht (OpenOffice und Mozilla sind 2 negativ Beispiele, die mir gerade einfallen, aber deren Code ist teilweise gar nicht mal so weit von dem Ct Code entfernt

ja, bei C++-Programmen liegt es immer am Programmierer, wenn das Programm lahm ist. Bei Java-Programmen ist immer die Programmiersprache schuld. Gut, dass wir das jetzt mal klargestellt haben.

[rüdiger]

der Unterschied ist, dass ich noch nie eine Java Anwendung gesehen habe, die schnell bootet. Das liegt aber nicht wirklich in der Hand des Programmierers, da bei Java der Bytecode noch entsprechend compiliert werden muss, was natuerlich bei groesseren Projekten laenger dauert. Deswegen ist Java an der Lade-Zeit schuld. Natuerlich kann man einen Java Compiler nehmen um das Problem zu beheben. Dann liegt die Ladezeit wieder (zumindest zum gleichen Teil wei bei C++) in den Händen des Programmierers.

[Unix-Tom]

Womit wir wieder bei der Frage wären: In welcher Programmiersprache wurde ASM geschrieben.

Und wie sieht es mit
C/C++
JAVA
PHP
PERL
und wie sie nicht alle heißen

aus

[Gregor]

kingruedi schrieb:

der Unterschied ist, dass ich noch nie eine Java Anwendung gesehen habe, die schnell bootet. Das liegt aber nicht wirklich in der Hand des Programmierers,

Doch, das liegt in der Hand des Programmierers. Die JVM braucht vielleicht eine Sekunde zum Starten. Alles weitere ist vom Programmierer abhängig. Wenn ein Programm jetzt 10 Sekunden zum Starten braucht, dann heißt das, dass eine ganze Menge beim Start des Programms erledigt wird. ...und Java lädt geradezu dazu ein, allemöglichen skurilen Sachen beim Start des Programms zu machen.

Ich durchsuche bei meinem aktuellen Projekt zum Beispiel alle Verzeichnisse des Programms beim Start und suche mir bestimmte Dateien zusammen, die ich dann letztendlich in eine Datenstruktur stecke. Das kostet natürlich Zeit, weil das momentan wohl etwa 400 Dateien sind, die ich beim Start des Programms durchgehe. Mir ist das aber reichlich egal, weil ich die Startzeit für ziemlich irrelevant halte. Der Vorteil, den ich als Programmierer durch die veränderte und sauberere Codestruktur habe ist mir wichtiger. Ich bin mir fast sicher, dass die meisten Javaprogrammierer hier eine andere Mentalität als die meisten C++-Programmierer haben.

[rüdiger]

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 )

[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