Delphi doch langsam

LarsMiddendorf · Hält's aus hier Beiträge: 11

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.

www.2003.coder-area....ee58f31d9053f397badf

Delphi Ausdruck:

markieren

Quelltext

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

Assembler

markieren

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

markieren

Quelltext

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

Assembler

markieren

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 · Verfasst: 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

neojones · Beiträge: 1206 Erhaltene Danke: 1

Fakt ist, dass ich die c't auch schon am Hauptbahnhof in Wien gekauft habe und an irgendeinem Kiosk im Bezirk 7. Frag mich aber nicht mehr genau, an welchem ;-)

_________________
Ha! Es compiliert! Wir können ausliefern!

MaxiTB · Verfasst: 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:

)

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

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

MaxiTB · Verfasst: Mo 22.09.03 13:52 Titel: Ach ja Motzi ...

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:

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

Motzi · Verfasst: Mo 22.09.03 14:34

Ich habe nie gesagt, dass es das c't bei uns nicht gibt, ich hab nur gesagt, dass ich es bis jetzt noch nie gefunden habe..!

_________________
gringo pussy cats - eef i see you i will pull your tail out by eets roots!

Klabautermann · Verfasst: 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

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Zitat:

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.

Der Witz ist ja, das du das eben nicht kannst, weil C++ diese alleinstehenden/sinnlosen Schleifen einfach nicht mitkompiliert. Essig mit Test.

Cu,
Udontknow

Klabautermann · Verfasst: Mo 22.09.03 15:51

Hi,

Udontknow hat folgendes geschrieben:

Der Witz ist ja, das du das eben nicht kannst, weil C++ diese alleinstehenden/sinnlosen Schleifen einfach nicht mitkompiliert. Essig mit Test.

richtig, aber deshalb ist der Test nicht fehlerhaft oder unsinnig. C++ kann in der Disziplin nur nicht wirklich bewertet werden (disqualifiziert

).

Gruß
Klabautermann

SMI · Beiträge: 106 Win95-2003 / Debian / Suse D1/D3/D6/D7

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

_________________
Wenn es im Jahre 1879 schon Computer gegeben hätte, würden diese vorausgesagt haben, daß man infolge der Zunahme von Pferdewagen im Jahre 1979 im Pferdemist ersticken würde.
(John C. Edwards, brit. Zukunftsforscher)

Bernhard Geyer · Beiträge: 721 Erhaltene Danke: 3

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.

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

Klabautermann · Verfasst: 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.

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

LarsMiddendorf · Hält's aus hier Beiträge: 11

Das ist eine erfreuliche Nachricht, da man ja Objekte wesentlich häufiger als int64 benötigt. Ich vermute mal, daß das daran liegt, daß C++ nur 2 Register für die Parameterübergabe benutzt während es bei Delphi 3 sind. Da bei Objekten immer noch der self/this Parameter dazukommt, könnte das schon was ausmachen.

blackbirdXXX · Beiträge: 1077 Erhaltene Danke: 1 Ubuntu Dapper

Ich hab die c't im Abo. Obwohl es sie in Hermagor bei Spar gibt. Und wenn es die Zeitung in Hermagor gibt dann gibt es sie auch in Wien.

_________________
Klein, schwarz und ärgert Techniker? Jumper!

mull · Hält's aus hier Beiträge: 3

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

markieren

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

markieren

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 · Verfasst: 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

Ehemaliges Mitglied Erhaltene Danke: 1

@mull: Wei hast du die Werte gemessen?

smiegel · Verfasst: Mi 08.10.03 11:49

Hallo,

ich muss Klabautermann zustimmen.

Zum einen macht mich das füllen der Listbox stutzig. Sagt das Beispiel etwas über die Geschwindigkeit eines Compilers aus oder etwa über die Implemetierung der Listbox? Wenn man das ganze vernünftig vergleichen will, sollte man wie im c't-Artikel, eine nicht visuelle Klasse nehmen (TList od. vergleichbares).
Warum wird in dem Beispiel nicht auch noch die Initialisierung des Arrays gemessen?

Kann man GetTickCount und Timer als gleichwertige Zeitmesser benutzen?

_________________
Gruß Smiegel
Ich weiß, daß ich nichts weiß, aber ich weiß mehr als die, die nicht wissen, daß sie nichts wissen. (Sokrates)

Ehemaliges Mitglied Erhaltene Danke: 1

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

markieren

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 · Verfasst: Mi 08.10.03 13:35

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

markieren

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 ;-)

_________________
Das Lächeln ist die eleganteste Art dem Gegner die Zähne zu zeigen.
Borland SE

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme