Entwickler-Ecke :: Thema anzeigen

Klabautermann - Do 18.09.03 17:42
Titel: Delphi doch langsam

Hallo,

in der vergangenheit wurde auch hier oft die Frage gestellt, ob Delhi langsamer sei als andere Sprachen. Die ct [http://www.heise.de/ct/] hat jetzt die eindeutige antwort gefunden.
Leider lautet sie Ja. Ich dachte mir, das das auch den einen oder anderen von euch interessieren könnte (die ct-Ausgabe müsste bis zum ende dieser Woche noch am Kiosk sein).
Eigentlich ging es im Artikel "Daniel Düsentrieb", von Arne Schäpers & Rudolf Huttary, welcher auf den Seiten 204ff der ct 19.03 veröffendlicht wurde darum, wie Schnell C# bzw. .NET Anwendungen sind. Hierzu wurden ein paar Tests in Konkurren zu M$-C++, Java und Delphi gefahren.

In einigen Anwendungsgebieten mus Delphi sogar hinter Java anstehen. Mehr als einen 2 Platz ereicht Delphi in keinem Test aber diser ist sehr selten.

Hier ein paar Beispiele aus den Abbildungen auf den Seiten 206 & 207 (angaben jeweils für den Relase Mode in Sekunden auf einem Athlon mit 1GHz):

ct hat folgendes geschrieben:

Einfache Schleifen
Empty Loops:

C#: 3,0s
C++: 0,0s
Java: 5,0s
Delphi: 2,0s

Calc Loops:

C#: 2,0s
C++: 0,0s
Java: 4,0s
Delphi: 2,0s

Real Calc Loops:

C#: 6,0s
C++: 5,0s
Java: 7,1s
Delphi: 6,0s

Integer-Arithmetik
RSABrute:

C#: 20,0s
C++: 12,0s
Java: 19,0s
Delphi: 57,0s

RSARekursiv:

C#: 77,7s
C++: 49,0s
Java: 54,2s
Delphi: 74,4s

Die verwendeten Quelltexte könnt ihr hier [http://www.heise.de/ct/ftp/03/19/204] runterladen.

Hierbei ist zu beachten, das bei Java und C# die Zeitmessung auch erst nach der (JIT) Compilierung beginnt. Dennoch finde ich, das Borland sich dabei nciht mit Ruhm bekleckert hat (was aber wenn ich mich recht entsinne auch bei Turbo Pascal schon so war. Compiliergeschwindigkeit hevoragend, Laufgeschwindigkeit Mäßig).

Gruß
Klabautermann

MSCH - Do 18.09.03 18:10

Ich denke, dass Geschwindigkeit alleine nicht dass ausschlaggebende sein kann und auch nicht ist - denn die meiste Zeit wartet der Puter sowieso auf die Eingaben des davorstehenden-sitzenden meist organisch aufgebauten Individuum.

Ich hab schon alles probiert, C, C++, Java, ASM und bin bei D geblieben. Warum ? Alleine die Zeigerarithmetik unter C ist grausam. Delphi erkauft sich vielleicht 0.000.. Promille Geschwindigkeitsbremse durch etwas "Benutzerfreundlichkeit" in einigen Dingen.

Die wichtigste Frage ist doch, welches Programm besteht aus solch komplexen Rechenoperationen? Realtimeanwendungen werden imho doch sowieso nicht mit D entwickelt.

grez
msch

DeCodeGuru - Do 18.09.03 18:41

Zitat:

hauptsache schneller als der C# Müll von M$ !

Könntest du bitte erklären, warum C# Müll sein soll? Ich finde diesen Sprachen-"Krieg" so lächerlich. Warum immer auf eine Sprache setzen. Warum denn nicht einfach die Vorzüge der jeweiligen Sprachen für seine Probleme benutzen und einfach diese Vorzüge anerkennen, anstatt dauern zu sagen "Delphi ist aber besser!!!". Ich will damit jetzt keinen direkt ansprechen, aber in IRC-Channels artet das wirklich auch schon aus. Einer kommt in den Channel, fragt nach einer Lösung für Delphi und prompt kommt dann einer und sagt "vergiss das scheiß Delphi, nimm C". Dann kommt der nächste etc...

UGrohne - Do 18.09.03 19:01

Hab den Artikel gerade auch gelesen, aber ich muss sagen, dass man daraus nicht unbedingt schließen kann, dass Delphi langsamer ist als andere. Es hat (wie auch in dem Artikel erwähnt wurde) nur 2 Probleme:

Ist die Optimierung nicht so sehr auf den Code selber eingestellt. VC kürzte ja die leeren Schleifen ersatzlos weg, deshalb dieses Ergebnis, sonst war es nicht viel langsamer als C++
Ist die Implementierung des Int64 nicht gut gelungen, sagen wir es richtig: Sie ist Mist. Aber wer braucht für normale Anwendungen im Moment den 64-Bit-Int? Ich habe ihn einmal gebraucht, mehr nicht. Und bis dahin, hat Borland das Problem auch in den Griff gekriegt

Alles in allem würde ich sagen, dass der Test in Richtung Delphi etwas unfair war, aber das war ja eigentlich auch nicht das Thema. Warten wir erstmal den 2. Teil mit der Objekt-Orientierung ab und dann können wir weiterdiskutieren ;-)

Klabautermann - Do 18.09.03 21:57

Hallo,

UGrohne hat folgendes geschrieben:

Hab den Artikel gerade auch gelesen, aber ich muss sagen, dass man daraus nicht unbedingt schließen kann, dass Delphi langsamer ist als andere.

die ctler räumen ja auch ein, das ihre Programme keine "echten" Benshmarks sind, aber wenn etwas wie:

Delphi-Quelltext

1:
2:
3:
4:

for x := 1 to 1000 do
    for y := 1 to 1000 do
      for z := 1 to 1000 do
         ;

nicht als nutzlos erkannt und wegoptimiert wird ist das schon Peinlich (weder x, noch y noch z werden später verwendet).

UGrohne hat folgendes geschrieben:

Es hat (wie auch in dem Artikel erwähnt wurde) nur 2 Probleme:

Ist die Optimierung nicht so sehr auf den Code selber eingestellt. VC kürzte ja die leeren Schleifen ersatzlos weg, deshalb dieses Ergebnis, sonst war es nicht viel langsamer als C++

Siehe oben ;). Bei der CalcLoop finde ich das vorgehen von C++ zwar genial aber überflüssig, bei der leeren ist es aber die einzig wirklich sinvolle Variante.

UGrohne hat folgendes geschrieben:

Ist die Implementierung des Int64 nicht gut gelungen, sagen wir es richtig: Sie ist Mist. Aber wer braucht für normale Anwendungen im Moment den 64-Bit-Int? Ich habe ihn einmal gebraucht, mehr nicht. Und bis dahin, hat Borland das Problem auch in den Griff gekriegt

Ja die ist misst, ich hoffe das Delphi da eine besser spendiert wird wenn es auch 64Bit Windows Systeme losgelassen wird (ist eigentlich sehr warhscheinlich) wenn die Borländer es dann nciht zur reinen .NET Sprache machen.

UGrohne hat folgendes geschrieben:

Alles in allem würde ich sagen, dass der Test in Richtung Delphi etwas unfair war,

Wieso? Was wurde denn da gemacht, das Delphi benachteiligte?

UGrohne hat folgendes geschrieben:

Warten wir erstmal den 2. Teil mit der Objekt-Orientierung ab und dann können wir weiterdiskutieren ;-)

Ja, den erwarte ich auch mit Spannung. Aber meine Glaskugel sagt mir, das C# dort am besten abschneiden wird, gefolgt von Java und mit C++ & Delphi auf den Plätzen 3&4. Warum? Weil die Beiden erstgenannten Konzepte als OOP Sprachen gebohen sind, während C++ und Delphi sich erst zu diesen entwickelt haben und deshalb viel ballast von C und Pascal mitschleppen werden, der sie da behindert. Aber vieleicht (hoffendlich) irrd sich meine Glaskugel da ja auch.

Gruß
Klabautermann

Udontknow - Fr 19.09.03 09:38

Hi!

Bitte schön, wen interessiert denn Geschwindigkeit? Etwa Windows-User? :mrgreen:

Spass beiseite:

Zitat:

die ctler räumen ja auch ein, das ihre Programme keine "echten" Benshmarks sind, aber wenn etwas wie:
Sourcecode:
for x := 1 to 1000 do
for y := 1 to 1000 do
for z := 1 to 1000 do
;

nicht als nutzlos erkannt und wegoptimiert wird ist das schon Peinlich (weder x, noch y noch z werden später verwendet).

Hmmm, ich finde, es ist peinlich, so einen Code in seinem Programm zu hinterlegen.
Die Optimierung findet ja bei der Compilierung statt, und nicht etwa zur Laufzeit, sprich : das Programm erkennt ja nicht, ob irgendeine Schleife gerade in einer gewissen Situation keinen Sinn macht.

Auf den OOP-Teil bin ich auch gespannt. Delphi hat ja dort einen ganz tollen Vorteil gegenüber C++, nämlich Properties. C# hat sie denn dann auch gleich mitimplementiert.

Cu, :)
Udontknow

Klabautermann - Fr 19.09.03 10:53

Udontknow hat folgendes geschrieben:

Hmmm, ich finde, es ist peinlich, so einen Code in seinem Programm zu hinterlegen.

Sicherlich aber wenn die Optimierung bei solch offensichtlichen Dingen nicht greift, wie soll es denn bei subtieleren Dingen funktionieren?
Nutzlose Variableniitialisierungen entfernet Delphi ja auch.

Udontknow hat folgendes geschrieben:

Die Optimierung findet ja bei der Compilierung statt, und nicht etwa zur Laufzeit, sprich : das Programm erkennt ja nicht, ob irgendeine Schleife gerade in einer gewissen Situation keinen Sinn macht.

Aber es sollte erkennen, wen es keine Situation gibt in der die Konstruktion Sinn macht, in diesem Fall einfach aufgrung der Tatsache, das die Zählvariablen nirgendwo anders verwendet werden und die innere Schleife völlig leer ist.

Naja, ich finde das ganze auch nicht so dramatisch wie es sich vieleicht anhört. Denn die geschwindigkeit (besonders die schlechte ;)) kommt durch den Code, den der Programmier erzeugt, die Optimierung kann ohnehin nichts retten wenn der Programmierer murks macht, aber wenn er gute Arbeit leistet, sollte sie noch für das Sahnehäubchen liefern.

Gruß
Klabautermann

JoelH - Fr 19.09.03 13:26
Titel: hmm,

Klabautermann hat folgendes geschrieben:

Udontknow hat folgendes geschrieben:

Hmmm, ich finde, es ist peinlich, so einen Code in seinem Programm zu hinterlegen.

Hmm, wobei hier ein grosser Unterschied besteht !

Eine leere Schleife muss nicht nutzlos sein, sondern kann für einfach verzögerungseffekte herhalten. Was erlaubt sich ein Compiler diese weg zu optimieren ? Dies ist für mich keine optimierung sondern eine Veränderung denn der Compiler kann wirklich nicht wissen ob die Schleife 'vergessen' wurde oder ob sie bewusst da ist. Wenn schon dann bitte eine Compilerwarning und optionale Wegoptimierung, aber dann kann ich den Kram auch einfach aus den Quelltext löschen.

Was 'vergessene' bzw. rudimetäre Variablen angeht sieht die Sache anders aus. Da diese keinerlei auswirkung auf den Code haben können sie einfach gestrichen werden.

JoelH - Fr 19.09.03 17:23
Titel: hmm,

Udontknow hat folgendes geschrieben:

Verzögern mit Schleifen? Dann verzögerst du auf einem 386er um ein Vielfaches des Zeitraumes, den ein 3GHz-Rechner braucht.

Darauf kommt es nicht an.Genauso ein Schrott ist es zu sagen C++ ist schneller weil es die Sache wegoptimiert. Damit zerstört es aber auch einfach den Code. Das ist nicht was ein Copiler tun sollte. Hatte einige male Probs mit Delphi 4 und der Codeoptimierung, der hat mir den ganzen Code kaputt gemacht, konnte ich nur dadurch beheben das ich die Codeoptimierung ausgeschaltet habe.

Es ging mir eher ums Pronzip. Die Maschine darf IMHO den Code nicht selbst verändern. Dann werden wir irgendwann nurnoch von Maschinen bestimmt

@ak
Full ACK.

Alfons-G - So 21.09.03 18:13

In dem Artikel warnen die Autoren ja ausdrücklich davor, die Ergebnisse zu ernst zu nehmen. Die Vergleiche erlauben denn auch eher Rückschlüsse darauf, wie die jeweiligen Compiler mit dem Code umgehen, als direkte Geschwindigkeitsvergleiche anzustellen. Zu dr Meinung "Sch***-C#" kann ich nur sagen, dass ich das nicht teile. Allein schon der Autor des Sprachkonzeptes von C# sorgte dafür, dass man sich als Delphi-Programmierer hier viel eher heimisch fühlt, als bei C++ :) .

Und nichts ist nur deswegen schon sch****, weil es von Microsoft stammt - auch wenn die Qualität der Microsoft-Produkte nicht ihrer Marktbedeutung entspricht.

Mit solchen Vergleichen, wie sie die "c't" veröffentlicht, kann man aber (manchmal) erkennen, mit welchen Konstruktionen seine Lieblingssprache besser umgehen kann.

8)

Christian S. - So 21.09.03 18:52

Ich muss sagen, dass ich C# sehr elegant und angenehm zu programmieren finde. Besonders das Überladen von Operatoren für eigene Objekte finde ich Klasse. Und auch sonst macht es einfach Spaß, damit zu arbeiten.

Und solche Tests wie die der c't sind zum einen dann sinnvoll, wenn man bei einem Projekt entscheiden will, welche Programmiersprache man verwenden will (bei Datenbanken wahrscheinlich eher Delphi, bei aufwändigen Berechnungen wohl eher C++) und zum anderen für die Entwickler der Programmiersprachen, die sehen, wo sie noch dran arbeiten müssen.

MfG
Peter

Klabautermann - Mo 22.09.03 10:02

Phobeus hat folgendes geschrieben:

Hm. Bei einem Primazahlrechner den wir mal bei einem Delpher_Treffen gemacht haben, war die C++-App eindeutig langsamer fast um 25%.

als die Delphi Version?
Kannst du mal die Quelltexte, posten, währe interessant.

Zitat:

Bei der 3D-Programmierung komme ich auf gleiche Ergebenisse. Werde mal die "Benchmarks" nicht in Frage stellen, aber in der Praxis scheint es keine Bedeutung zu haben...

Dafür sind sie auch noch zu Homogen. Leider schein der Artiken in der neuen Ausgabe ncoh nicht fortgesetzt zu werden (oder ich habe ihn übersehen). Daher müssen wir uns wohl noch 2 Wochen gedulden bevor wir die Daten zum OOP Handling bekommen.

Gruß
Klabautermann

Udontknow - Mo 22.09.03 11:08

Habe mir jetzt auch noch mal den Artikel durchgelesen.

Ich denke nicht, daß man nun sagen sollte, Delphi ist langsamer. Die ersten zwei Tests sind zu ignorieren, da es nicht wirklich die Performance der Compiler, sondern ihre Fähigkeit, sinnlosen Code zu entfernen, darstellt.

Dabei sollte, wie ich schon oben mal bemerkte, jeder halbwegs ordentliche Programmierer solche Situationen nie entstehen lassen (Zitat ct: "Die anderen Sprachen... setzen also eher auf eine gewisse Eigenintelligenz des Programmierers").

Beim Real-Calc-Loop-Test sind sich ja Delphi und C++ fast ebenbürtig, mit 2,3s ist Delphi nur eine Zehntel-Sekunde langsamer.

Gut, die Integer-Arithmetik ist aus den bereits benannten Gründen für Delphi nicht gerade ein Sieg auf ganzer Linie. Aber wann setzt man denn schon Int64 ein? Die Fälle, wo ein Integer nicht mehr ausreicht, sind recht selten...

Für mich stellt sich der gesamte Bericht gar nicht so negativ für Delphi heraus, wie ich es beim ersten Lesen von Klabautermanns Beitrag dachte.

Die Ct-Redakteure schreiben übrigens, daß bei einem ersten Test mit einem kompletten Programm, wo die OOP gefordert wird, C++ stark einbricht( Zitat ct:" Zumindest bei dem ersten bereits fertig gestellten Programm einer, hierarchischen Listenverwaltung, sieht C++ auf einmal ziemlich alt aus - und das nicht etwa, weil wir es drauf angelegt hätten").
Da bin ich auf den Vergleich mit Delphi gespannt.

Cu,
Udontknow

LarsMiddendorf - Mo 22.09.03 11:59

Das schlechte Abschneiden von Delphi in dem Test liegt vermutlich hauptsächlich daran, daß int64 benutzt wurden.
Auf Coder Area war so ein Wettbewerb bei dem man alle ungeraden Zahlen addieren sollte. Es wurde dort auch der erzeugte Assemblercode von Delphi und C++ verglichen und es kam dabei raus, daß das Delphi den Ausdruck besser optimiert hat.

http://www.2003.coder-area.de/wbb2/thread.php?threadid=8176&sid=9c4b67146ec3ee58f31d9053f397badf

Delphi Ausdruck:

Quelltext

1:	result:=((n+1) shr 1)*((n+1)shr 1);

Assembler

Quelltext

1:
2:
3:
4:
5:

lea edx, [eax+$01] 
shr edx, 1 
mov ecx, edx 
imul ecx, edx
mov eax, ecx

VC++ 6.0

Quelltext

1:	return ( ((n+1)>>1) * ((n+1)>>1) );

Assembler

Quelltext

1:
2:
3:
4:
5:
6:
7:

mov   eax,dword ptr [ebp+8]
add   eax,1
sar   eax,1
mov   ecx,dword ptr [ebp+8]
add   ecx,1
sar   ecx,1
imul  eax,ecx

Delphi erkennt vermutlich, daß auf beiden Seiten vom * der gleiche Ausdruck steht.

Klabautermann - Mo 22.09.03 12:09

Hallo,

Motzi hat folgendes geschrieben:

Mal eine kurze Zwischenfrage, nicht unbedingt jetzt diese Benchmarks betreffend... anscheinend is das c't ja ganz gut... weiß jemand ob/wo man das in Österreich/Wien bekommt? Hab das noch nie irgendwo gefunden... :?

ich kenne mich in Wien zwar nicht aus, aber bei uns in Deutschland bekommt man die reichhaltigste Zeitschriften Auswal interessanterweise an den Bahnhöfen. Durch die Laufkundschaft lässt sich das dort wohl am besten absetzen. Deshalb würde ich dir empfehlen es mal am Hauptbahnhof zu probieren.

Auf jedem Fall ist auf der Titelseite auch ein Preis für Östereich (3,20 Euro) angegeben, weshalb ich davon ausgehe, dass sie auch bei euch gehandelt wird.

Gruß
Klabautermann

MaxiTB - Mo 22.09.03 13:46
Titel: Was für ein komischer Benchmark ...

Asche auf mein Haupt :oops: - ich gebe zu, ich habe irgendwo in der Mitte aufgehört eure Antworten zu lesen, also seht das folgende hier mal als Anmerkung zum main-topic:

:?: Erstens mals, was machen hier C# und Java in dem Test ? Das schaut mir sehr unprofessionell aus, besonders da jeder wohl die Performance des Java-GC kennt ! Es ist eine Sache in Delphi, mem leaks zu basteln aber bei Java ist man nicht selber Schuld an der miesen Speicherverwaltung. Und C# ? Ach bitte, C# ist traumhaft - nur leider ists 100% an MS gebunden und somit wieder uninteressant. Bis C# auch wirklich eine vernüftige Klassenbibliothek zu bieten hat, werden auch noch ein paar Jährchen vergehen.

:?: Zweitens die Tests - jetzt kommt der Hammer von Sachen Professionalität - LEERE SCHLEIFEN ? Ähm, kann der Autor dieses Artikel eigentlich programmieren oder ist er einer von den Lamer, der sich freut, mit leeren Schleifen Rechnerleistung zu verbraten ? :twisted: Also wirklich ... realitätsfremder gehts nicht - ich hatte noch NIE (in über 10 Jahren) denn Fall, daß in meinen Programmen leere Schleifen vorkamen :lol: , aber vielleicht bin ich auch nur zu altmodisch.

Kritisieren kann man viel ... wie schauts aus - machen wir selber einen Test ? Und zwar nach Aufgabengebieten ?

Ich weiß - das klingt jetzt blöd, weil wer kann hier schon was anderes außer Delphi ... ähm, einige denke ich; aber wirklich optimal ? :roll: Okay - habe mich damals schon geoutet und will die Tests so liefern:

:arrow: VC++ (7.0)
:arrow: MS VB (6.0) - weils Spaß machen soll :wink:

Aufgabengebiete würde ich mal auf die schnelle folgende Vorschlagen:

:arrow: Integer Berechnungen (auch Bitoperationen), Schwerpunkt 32-Bit.

:arrow: Fließkomma Brechnungen, Schwerpunkt doppelte Genauigkeit (wenn schon, dann schon).

:arrow: String-Operationen (und zwar ANSI- und UNICODE ... ups, okay, VB eben nur ANSI :twisted: )

:arrow: OOP - Klassen instanzieren, vererben, zugreifen (upps - jetzt wirds peinlich für VB, naja weniger Arbeit für mich).

Zeitmessung:
Klar, sie sollte nicht über das ganze Programm gehen und auch nicht die GUI einbeziehen (deshalb werde ich für C++ auch nur ein command line Progrämmchen basteln).

Fazit:
Ich weiß, es würden noch die Aufgaben genau definiert gehört - vielleicht fallen euch noch ein paar ein. Jedenfalls sollte es nur das wichtigste sein ... also schön klein halten. Wir können die Dinger ja jederzeit erweitern und dann genauer unter die Lupe nehmen.

PS:
Wir sollten unbedingt Spracheigenheiten mitberücksichtigen (also in C++ z.B. statt A=A+1; :arrow: A++; denn jeder Programmierer verwendet sie ja - alles andere würde die Resultate wieder verfälschen).

MaxiTB - Mo 22.09.03 13:52
Titel: Ach ja Motzi ...

:lol:

Sorry, konnte ich mir jetzt oben nicht verkneifen. *g*
Wie kommst du drauf, daß es bei uns das c't nicht gibt ? :lol:
Ups, schon wieder *g*.

Also erstens mal zu Wien: Ja, witzigerweise sind in der Hauptstadt :roll: die Kioske sehr ausgesucht und ich habe ein halbes Jahr gebraucht, um einen Stand zu finden, der ein zwei Monate altes 'Barett' hatte - aktueller gings nicht. *g* Aber das c't bekommt man selbst in Wien fast an jeder Ecke.

Zweitens an Klabauter: Wenn man hier als Österreicher Nicht-Wiener ist, geht man in eine Traffik und schon hat man ein brandaktuelles c't in den Händen. Oder man hat ein Abo :wink:

Klabautermann - Mo 22.09.03 15:30
Titel: Re: Was für ein komischer Benchmark ...

Hallo,

MaxiTB hat folgendes geschrieben:

:?: Erstens mals, was machen hier C# und Java in dem Test ? Das schaut mir sehr unprofessionell aus, besonders da jeder wohl die Performance des Java-GC kennt !

in dem Artikel geht es nun mal um das Laufzeitverhalten von C#. Die anderen Sprachen liefern nur die Orientierungswerte.
Die Schlechte Performance von JAVA rührt größtenteils daher, das es erst auf Maschienencode Compiliert wird, wenn das Applet aufgerufen wird. Diese Compiliertzeit wird aber ausdrücklich nicht mitgezählt es geht um das reine laufzeitverhalten des Compilats.

MaxiTB hat folgendes geschrieben:

Und C# ? Ach bitte, C# ist traumhaft - nur leider ists 100% an MS gebunden und somit wieder uninteressant.

Das mag ja für dich so sein, aber deshalb wird der rest der Weld trotzdem nciht aufhören sich intensiver damit zu beschäftigen und es somit auch bei solchen Tests berücksichtigen.

MaxiTB hat folgendes geschrieben:

:?: Zweitens die Tests - jetzt kommt der Hammer von Sachen Professionalität - LEERE SCHLEIFEN ? Ähm, kann der Autor dieses Artikel eigentlich programmieren oder ist er einer von den Lamer, der sich freut, mit leeren Schleifen Rechnerleistung zu verbraten ?

Wenn ermittelt werden soll, wie gut ein Compiler verschiedene Programmstukturen umsetzt, dann muss man diese Sprachstrukturen auch alleinstehend testen, egal ob diese in der Realität alleinstehend vorkommen oder nciht. Alles andere währe unprofessionell.

MaxiTB hat folgendes geschrieben:

Kritisieren kann man viel ... wie schauts aus - machen wir selber einen Test ? Und zwar nach Aufgabengebieten ?
[..]
:arrow: MS VB (6.0) - weils Spaß machen soll :wink:

Thschuldigung, aber unprofessioneller geht es ja kaum mehr. Schließlich liefert Visual Basic keine echten Kompilate, sondern nur aufrufscripte für die VB-Runtimes. Diese mit "echten" Programmen zu vergleichen ist mehr als unfair. Die vier Kanidaten des Artikels liefern alle in letzter konsequenz ein echtes Compilat.
Mal abgesehen davon, das dein

maxiTB hat folgendes geschrieben:

- weils Spaß machen soll :wink:

die Vermutung einer manipulativen Aufgabenstellung nahe legt ;). Wenn man die Aufgabe aber schon so stellt, das das gewünschte Ergebnis rauskommt, kann man es gleich sein lassen.

Also viel Spass bei deinen experimenten ;)

Kalbautermann

SMI - Fr 26.09.03 05:16
Titel: Re: Was für ein komischer Benchmark ...

MaxiTB hat folgendes geschrieben:

:?: Erstens mals, was machen hier C# und Java in dem Test ? Das schaut mir sehr unprofessionell aus, besonders da jeder wohl die Performance des Java-GC kennt ! Es ist eine Sache in Delphi, mem leaks zu basteln aber bei Java ist man nicht selber Schuld an der miesen Speicherverwaltung. Und C# ? Ach bitte, C# ist traumhaft - nur leider ists 100% an MS gebunden und somit wieder uninteressant. Bis C# auch wirklich eine vernüftige Klassenbibliothek zu bieten hat, werden auch noch ein paar Jährchen vergehen.

@MaxiTB
Du solltest dich mal richtig über Java informieren. Dann würdest du feststellen dass in zunehmender Anzahl immer mehr Firmen ihre Software Entwicklung auf Java umgestellt haben. Da sie auf Grund der Palttform unabhängig extrem viel Geld sparen können.

Es mag dir auch entgangen sein, dass es Java Native Compiler gibt die von der Performance her durchaus im vorderen Bereich liegen. Denn genau hier zahlt sich das Speichermanagement aus. Da der Java Garbage Collector ist meistens nur im Idle aktiv ist, kann auf kosten von etwas RAM zum Teil viel Performance dazugewonnen werden.
Java war darüberhinaus unsprünglich eine Sprache für Embedded Systems. Und ist daher sehr stikt ausgelegt Speicherlöcher zu vermeiden. Wovon sich einige anderen Sprachen ein goßes Stückch abschneiden könnten.

SMI

Klabautermann - So 05.10.03 14:05
Titel: Re: Delphi im 2. Teil "Etappensieger"

Bernhard Geyer hat folgendes geschrieben:

Wer den 2ten Teil des Vergleichs gelesen hat, wird jetzt erleichtert Aufatmen. Im OOP-Vergleich (jeweils bei den getesteten Eigenschaften) ist Delphi erster (knapp gefolgt von C#). Damit ist die Int64-Schmach mehr als getilgt. 8)

Und wo ist C++ - Abgeschlagen letzter! :lol:

Ja, obwohl die Autoren den Delphi vorsprung teilweise darauf zurückführen, dass der Autor, welcher die Programme schrieb aus dem Delphi lager stammt. Wo genau aber die heimlichen Optimierungen liegen habe ich aus dem Artikel nicht rauslesen können.

Und C++ ist hier mit der Komplexität seiner Objekte gestraft. Wer also noch eine sinvolle begründung für das fehlen der Mehrfachvererbung in Delphi suchte hat sie hiermit gefunden ;).

Gruß
Klabautermann

mull - Di 07.10.03 21:25

Ich hab mir aml den Spaß gemacht Delphi + Vb.Net zu vergleichen, der ausgeführte Net Code ist ja ind jeder Sprache gleich.
Es werden 32.000 Zufallszahlen sortiert und dann in einer Listbox ausgegeben.
Der Code ist bei beiden bis auf die Syntax Identisch.

Meine Werte auf einen Athlon 1700
Sortieren: Delphi 2.91 sek. VB.Net 3.85 sek.
Listboch füllen 1.31 sek. 1.00 sek.

Delphi 6 Code

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:

procedure TForm1.Button1Click(Sender: TObject);
  var A: array[0..32000] of Integer;
   I, J, X: Integer; T: Double;
begin
      For I:= 0 To 32000 do begin
         A[I]:= round((10000 * Random) + 0);
      end;
      T:= GetTickCount;
      For I:= 0 To 32000 do begin
         For J:= I To 32000 do begin
            If A[I] > A[J] Then begin
               X:= A[I]; A[I]:= A[J]; A[J]:= X;
            End;
         end;
      end;
      Label1.caption:= FloatToStr(Round(GetTickCount - T)/1000) + ' sek. Sortieren';
      Beep;
      ListBox1.Clear;
      T:= GetTickCount;
      For I:= 0 To 32000 do begin
         ListBox1.Items.Add (IntToStr(I)+'. '+IntToStr(A[I]));
      end;
      Button1.caption:= FloatToStr(Round(GetTickCount - T)/1000) + ' sek. Listbox füllen';
end;

VB.Net Framwork1.1 Code

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
      Dim A(32000), I, J, X As Integer, T As Double
      For I = 0 To 32000
         A(I) = CInt(Int((10000 * Rnd()) + 0))
      Next
      T = Timer
      For I = 0 To 32000
         For J = I To 32000
            If A(I) > A(J) Then
               X = A(I) : A(I) = A(J) : A(J) = X
            End If
         Next
      Next
      Label1.Text = CStr(Math.Round(Timer - T, 2)) + " sek. sortieren" : Application.DoEvents()
      Beep()
      ListBox1.Items.Clear()
      T = Timer
      For I = 0 To 32000
         ListBox1.Items.Add(I.ToString + ". " + A(I).ToString)
      Next
      Button1.Text = CStr(Math.Round(Timer - T, 2)) + " sek. Listbox füllen"
   End Sub

Moderiert von Tino: Code- und Delphi-Tags hinzugefügt.

Klabautermann - Mi 08.10.03 08:47

Hallo,

mull hat folgendes geschrieben:

der ausgeführte Net Code ist ja ind jeder Sprache gleich.

da bin ich mir gar nciht so sicher. Es ist zwar richtig, dass der .NET in jedem .NET Programm weiterverwendet werden kann. Aber aus der Ursprungssprache muss ja in den Zwischencode Compiliert werden, ich bezweifle, das da jedes konstunkt zum selben Zwischencode Compiliert wird wie das äquivalente Konstrukt aus einer anderen Sprache.

Ich denke auch da werden Compiler das eine oder abdere Leisten können.

Wenn ich das falsch sehe bitte ich um aufklährung ;).

Gruß
Klabautermann

Delete - Mi 08.10.03 12:39

GetTickCount kannst du hier vergessen. Erklärung an Hand eines Beispieles:

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

Start := GetTickCount;
...;
...;
  // Windows wechselt zu einem anderen Thread
...
...
...
  // Windows / CPU führt den Code weiter aus
...;
...;
End := GetTickCount;

So in der Zeit hast du jetzt auch die Zeit drin, die dein Thread nicht zuteilungsfähig war und keinen Code ausgeführt hat. Einzige Möglichkeit hier eine korrekte Zeit zu ermittlen ist die Benutzung der API Funktion GetThreadTimes. Diese liefert die Zeit die ein Thread mit dem tatsächlichen Ausführen von Code verbracht hat und zwar sowohl im User-Modus als auch im Kernel-Modus.

sakura - Mi 08.10.03 13:35

Wenn Du die Listbox schnell haben willst, dann nutze mal Begin-/EndUpdate

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

 ...
  T:= GetTickCount;
  ListBox1.BeginUpdate;
  try
    ListBox1.Clear;
    For I:= 0 To 32000 do 
      ListBox1.Items.Add (IntToStr(I)+'. '+IntToStr(A[I]));
  finally
    ListBox1.EndUpdate;
  end;
  ....

Das Problem bei solchen Vergleichen ist oft, daß nicht die volle Palette der Optimierungsmöglichkeiten ausgeschöpft wird. Aber jetzt sollte Delphi die Listbox in einem Bruchteil einer Sekunde füllen ;-)

:wink2:

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!