Delphi vs. C# vs C++

[luisk]

Hallo,
hab mal einen Vergleich zwischen Delphi 6 und MS C# Express 2015 gemacht:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var li,lj:integer;
begin
        li := 0;
        lj := 0;
            for li:=0 to 50000 do begin
               for lj:=0 to 1000000  do begin

                end;
                if (li mod 1000=0) then begin
                   button1.caption := inttostr(li);
                   button1.Update();
                end;
            end;
end;

C#:

Code:

       private void button1_Click(object sender, EventArgs e)
        {
            int li = 0;
            int lj = 0;
            for (li=0;li<50000;li++)
            {
                for(lj=0;lj<1000000;lj++)
                {                  
                }
                if (li % 1000 == 0)
                {
                    button1.Text = li.ToString();
                    button1.Update();
                }
            }
        }

Ergebnis: Delphi ist 10 mal schneller als C#
Kann jemand Angaben zu C++ machen ?

[Phoenix]

Du weisst schon dass Du hier nicht Delphi vs. C# getestet hast, sondern die VCL (also die Win32 API) gegen das Windows Forms UI-Framework?

Mach das nochmal mit VCL gegen Firemonkey und sag uns dann mal, wie viel langsamer 'Delphi' gegenüber 'Delphi' ist.

Um die Geschwindigkeit der Runtime an sich zu testen, bieten sich Vergleiche an die viel CPU nutzen. Zum Beispiel identisch implementierte Sortieralgorithmen, die den identischen Input sortieren. Da dürfte der Unterschied dann eher marginal sein.

[JasonDX]

Was genau willst du denn messen? Wovon genau willst du die Geschwindigkeit vergleichen?
Ich erkenne in deinem Code nicht den Sinn des Benchmarks, ein Schluss "A ist x-mal schneller als B" ist daher nicht wirklich nachvollziehbar.

[Mavarik]

Zitat:

Zitat von Phoenix (Beitrag 1310310)

Mach das nochmal mit VCL gegen Firemonkey und sag uns dann mal, wie viel langsamer 'Delphi' gegenüber 'Delphi' ist.

Warum UI? Wegen den wenigen Updates der Caption?

btw:

Selbst mit einem

Delphi-Quellcode:

button1.Text := inttostr(li);
Application.ProcessMessages;

damit Firemonkey die Änderung darstellt, ist FMX ca. 3,5% schneller als die VCL...

Aber darum ging es Ihm sicherlich nicht...

[p80286]

[OT]
Chic!
Chips holen und sich zurück lehnen.

Gruß
K-H
[/OT]

[Lemmy]

Zitat:

Zitat von p80286 (Beitrag 1310316)

[OT]
Chic!
Chips holen und sich zurück lehnen.
[/OT]

aber echt.. der letzte "Kinoabend" ist schon lange her...
*dazusetz*

[Sherlock]

[OT]
Ich hab Nachos und Coke
[/OT]

O'Neill

[Mavarik]

[OT]

Ping Runde 1

[/OT]

[luisk]

Was gibt´s hier zu kapieren ?

Delphi-Quellcode:

if (li mod 1000=0) then begin

Delphi ist mit dem Code 10 mal schneller als C# !
Könnt Ihr das auch mal testen ?
In 15 sec ist Delphi bei 40 000 während C# gerade mal bei 4000 ist.
Ausgegeben wird ja nur alle 1000 Werte.

Wenn ich jeden Wert ausgebe kommt Delphi bis 30 000 in 15 Sekunden. C# bis 3000 .
Ihr könnt ja selber mal vergleichen ! (Sollte bei dem Mega-Code wohl kein Problem sein.)


Wie schnell ist im Moment MS C++ bei dem Vergleich ? (hab ich leider nicht zur Verfügung.)

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var li,lj:integer;
begin
         li := 0;
         lj := 0;
             for li:=0 to 50000 do begin
                for lj:=0 to 1000000 do begin

                 end;
                 if (li mod 1000=0) then begin
                    button1.caption := inttostr(li);
                    button1.Update();
                 end;
             end;
end;

[stahli]

Ich kann es nicht testen aber die Fragestellung ist doch in Ordnung.

Klar hat die GUI Auswirkungen aber die ist hier schon reduziert worden.

Und wenn die Aufgabenstellung so gegeben ist, ist die Fragestellung zur Performance auf unterschiedlichen Systemen legitim.

Also mein Vorschlag: Antworten oder halt nicht.

[greenmile]

Auf irgendeinem Delphi Karton stand mal "Für die einfachen Sachen nimmt man VB, für die Schnellen und komplexen Delphi". Glaube es war D4 oder D5.

[baumina]

Möchtest du testen wie schnell die for-Schleifen-Variablen hochgezählt werden, wie schnell so eine Integerumwandlung in String geht, wielange der mod-Befehl braucht oder wielange der Bildschirmupdate geht?

[luisk]

Zitat:

Zitat von baumina (Beitrag 1310325)

Möchtest du testen wie schnell die for-Schleifen-Variablen hochgezählt werden, wie schnell so eine Integerumwandlung in String geht, wielange der mod-Befehl braucht oder wielange der Bildschirmupdate geht?

Kannst Du nicht lesen ?
Jedes Programm besteht doch aus unterschiedlichen Befehlen und daraus ergibt sich dann ein Mittelwert !
Fakt ist, dass Delphi 6 bei dem simplen Programm 10 mal schneller ist, als MS C# Express 2015.
http://www.chip.de/downloads/Visual-..._36594529.html

Meine Frage ist, wie schnell läuft dieser einfache Code auf MS C++
im Vergleich zu Delphi (VCL) ?
Vielleicht ist hier ja jemand, der beides zur Hand hat.

[baumina]

Zitat:

Zitat von luisk (Beitrag 1310326)

Kannst Du nicht lesen ?

Vielleicht hattest du nicht genügend Text in Fett geschrieben. :P

[Daniel]

Nur die Ruhe. Die meisten werden hier des Lebens fähig sein.
Allerdings scheinst Du die Aussagekraft Deines Code-Fetzens zu überstrapazieren.

Ich habe aktuell keine Zeit, einen entsprechenden Vergleich nachzustellen - glaube Dir aber gern, dass es sich auf Deinem System verhält wie beschrieben.
Die Geschwindigkeit von Programmen "im Mittel" zu vergleichen ist etwa so, als wolltest Du die Wassertemperatur der Ozeane "im Mittel" vergleichen. Du wirst punktuell zu Ergebnissen kommen, die lokal betrachtet in Ordnung sein mögen, dennoch wäre es wagemutig, darauf basierend eine Gesamtausgabe treffen zu wollen.

Du solltest die Bereiche isoliert testen: CPU-Arithmetik, Speicherverwaltung, UI, I/O zu Datenträgern. Aber all das gibt es schon zuhauf für diverse Programmiersprachen.

[luisk]

Zitat:

Zitat von Daniel (Beitrag 1310328)

Du solltest die Bereiche isoliert testen:

Bei dem Code geht es jetzt in erster Linie nur um die For-Schleife. Ist also ein isolierter Test.

[Phoenix]

Wenn es ein isolierter Test sein soll, dann nimm das UI-Updaten da raus und benutze ne StopWatch um wirklich nur die Zeit der Schleife zu messen.

[luisk]

Zitat:

Zitat von Phoenix (Beitrag 1310332)

Wenn es ein isolierter Test sein soll, dann nimm das UI-Updaten da raus und benutze ne StopWatch um wirklich nur die Zeit der Schleife zu messen.

Der Faktor 10 sagt doch schon einiges.
Die Frage ist:
Wie schnell läuft dieses einfache Programm auf MS C++ im Vergleich zu C# und Delphi !

[Phoenix]

Zitat:

Zitat von luisk (Beitrag 1310334)

Zitat:

Zitat von Phoenix (Beitrag 1310332)

Wenn es ein isolierter Test sein soll, dann nimm das UI-Updaten da raus und benutze ne StopWatch um wirklich nur die Zeit der Schleife zu messen.

Der Faktor 10 sagt doch schon einiges.

Nein, er sagt genau gar nichts aus. Nur das das verwendete UI-Framework (bekanntermassen) nicht das schnellste ist.

[luisk]

Zitat:

Zitat von Phoenix (Beitrag 1310335)

Nein, er sagt genau gar nichts aus. Nur das das verwendete UI-Framework (bekanntermassen) nicht das schnellste ist.

Das UI spielt doch bei dem Vergleich keine Rolle, da eh nur bei
if (li mod 1000=0) then begin
ausgegeben wird !


Die Frage ist: wie schnell läuft das Teil auf C++ ?
kann das mal jemand testen ?

[Union]

Zitat:

Zitat von luisk (Beitrag 1310336)

Das UI spielt doch bei dem Vergleich keine Rolle, da eh nur bei
if (li mod 1000=0) then begin

Hast Du eine Messung ausgeführt um Deine Vermutung zu verifizieren?

[luisk]

Zitat:

Zitat von Union (Beitrag 1310338)

Hast Du eine Messung ausgeführt um Deine Vermutung zu verifizieren?

Genau !
Kannst Du evtl. mal den Code bei C++ messen, um zu vergleichen ?
Hab leider kein C++ zur Hand.

[JasonDX]

Zitat:

Zitat von luisk (Beitrag 1310334)

Wie schnell läuft dieses einfache Programm auf MS C++ im Vergleich zu C# und Delphi !

Ich kanns leider nicht mit MS C++ testen, hab gerade nur einen gcc zur Hand (hab deshalb auch das UI-Update rausgeschmissen - es geht ja um die Schleife)

Code:

int main() {
  int i, j;
  for (i = 0; i < 50000; i++)
    for (j = 0; j < 1000000; j++)
      ; // kein UI-Update. Lenkt nur ab.
  return 0;
}

Ergebnis: Das Programm läuft im einstelligen Millisekundenbereich (1-2ms), wobei anzumerken ist, dass in dem Bereich Messungen im Verhältnis ungenau sind; Programm läuft aber in wenigen Millisekunden.
Ich habe auch mit den Werten rumgespielt, statt 50000 auch 50 oder 1000000, das Ergebnis blieb dabei aber nahezu konstant (+/-1ms, nehme an das sind Messungenauigkeiten).

Fazit daraus: Sinnvolle Performance-Messung ist schwieriger, als es aussieht.

[Stevie]

Debug oder Release Config?

Einfacher oder mehrfacher Durchlauf (Stichwort JiT)?

[Union]

Wenn der gcc schlau optimiert, macht er sowieso das draus:

Code:

int main() {
  return 0;
}

[Phoenix]

Natürlich macht die Ausgabe am UI extrem viel aus.

Eine Ausgabe am UI ist grob so langsam wie einige tausende Schleifendurchläufe in denen nichts sonst gemacht wird.
Das heisst wenn Du alle 1000 Durchläufe stoppst, um irgendwas zu machen was grob geschätzt um die 8 - 12 mal so viel Zeit braucht wie die 1000 durchzuzählen, misst Du ausschliesslich die Darstellung am UI.

Beschäftige Dich erstmal mit den theoretischen Grundlagen von korrekten Performance-Tests bevor Du versuchst einen komplett unsinnigen Test mit anderen Sprachen / Plattformen durchführen zu lassen.

Und das ist auch der Grund, warum Dir hier niemand dieses unsinnige Beispiel mit C++ testen mag. Die Leute hier haben keine Lust sich mit sowas offensichtlich sinnlosem zu beschäftigen.

[mkinzler]

Zitat:

Ergebnis: Das Programm läuft im einstelligen Millisekundenbereich (1-2ms), wobei anzumerken ist, dass in dem Bereich Messungen im Verhältnis ungenau sind; Programm läuft aber in wenigen Millisekunden.
Ich habe auch mit den Werten rumgespielt, statt 50000 auch 50 oder 1000000, das Ergebnis blieb dabei aber nahezu konstant (+/-1ms, nehme an das sind Messungenauigkeiten).

Wirklich nur 2 ms?

Der selbe Code als Konsolenanwendung in Delphi benötigt rund 17 Sekunden.

[TRomano]

Ich finde diese Art von Messungen sinnfrei und wenn man schon C++,C# und Delphi vergleicht sollte man sich mit dem Debugger auch mal den erzeugten Assembler-Code ansehen. Vielleicht optimiert ein guter/aggressiver Compiler die einfachen (sinnlosen) Schleifen auch einfach weg und macht nix wie eben "return 0". Da kann doch nichts vergleichen !
Wenn man die CPU-Arithmetik und die Qualität des erzeugten Codes testen will muss man schon etwas Anspruchvolleres proggen. Dann könnte man auch testen, ob der Compiler die Befehlssätze (Stichwort SSE-SSE4.2) der CPU sinnvoll nutzt.

[JasonDX]

Zitat:

Zitat von mkinzler (Beitrag 1310349)

Zitat:

Ergebnis: Das Programm läuft im einstelligen Millisekundenbereich (1-2ms), wobei anzumerken ist, dass in dem Bereich Messungen im Verhältnis ungenau sind; Programm läuft aber in wenigen Millisekunden.
Ich habe auch mit den Werten rumgespielt, statt 50000 auch 50 oder 1000000, das Ergebnis blieb dabei aber nahezu konstant (+/-1ms, nehme an das sind Messungenauigkeiten).

Wirklich nur 2 ms?

Der selbe Code als Konsolenanwendung in Delphi benötigt rund 17 Sekunden.

Das hängt eben stark vom Compiler ab. Debug vs. Release, und wie viel er optimiert. Union hats richtig erkannt - der Compiler überspringt einfach die leere(n) Schleifen. Das war auch der Sinn hinter dem Beispiel: "Einfach so" Performance messen und vergleichen bringt kein sinnvolles Ergebnis. Haben zwar schon viele angedeutet, wurden aber überhört - der TE wollte eine Messung für C++ sehen, vielleicht öffnet das die Augen.

[Bernhard Geyer]

Zitat:

Zitat von luisk (Beitrag 1310308)

Hallo,
hab mal einen Vergleich zwischen Delphi 6 und MS C# Express 2015 gemacht:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var li,lj:integer;
begin
        li := 0;
        lj := 0;
            for li:=0 to 50000 do begin
               for lj:=0 to 1000000  do begin

                end;
                if (li mod 1000=0) then begin
                   button1.caption := inttostr(li);
                   button1.Update();
                end;
            end;
end;

C#:

Code:

       private void button1_Click(object sender, EventArgs e)
        {
            int li = 0;
            int lj = 0;
            for (li=0;li<50000;li++)
            {
                for(lj=0;lj<1000000;lj++)
                {                  
                }
                if (li % 1000 == 0)
                {
                    button1.Text = li.ToString();
                    button1.Update();
                }
            }
        }

Ergebnis: Delphi ist 10 mal schneller als C#
Kann jemand Angaben zu C++ machen ?

Das Ergebnis ist das bei blödsinniger permanenten GUI-Aktualisierung (welche die Funktionzeit eh vervielfacht) Delphi schneller diese blödsinnige Permanete GUI-Aktualsierung durchführen kann. Weiter Aussagen zu Performancevergleich Delphi <-> C# lassen sich nicht ableiten.

Und wie heißt es so schön: "Wer Mist mist, mist Mist"

[mkinzler]

Diese Vermutung hatte ich. Wenn man aus 50000 5000 oder sogar 50 macht und sich an der Zeit nichts ändert, spricht es auch dafür.

C# (2015) benötigt sogar etwas weniger als Delphi (16,6 Sekunden)

VC++ (2015): 0 ms. Nach Abschalten der Optimierung sind es dann 103s

c#:

Code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            int li = 0;
            int lj = 0;
            int st = System.Environment.TickCount;

            for (li = 0; li < 50000; li++)
            {
                for (lj = 0; lj < 1000000; lj++)
                {
                }
  
            }
            int et = System.Environment.TickCount - st;
            Console.WriteLine(et);
            Console.ReadLine();
        }
    }
}

Delphi:

Delphi-Quellcode:

program Test;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils, Windows;

  var li,lj:integer;
      st: Cardinal;
begin
  try
        li := 0;
        lj := 0;
        st := GetTickCount;
            for li:=0 to 50000 do
            begin
               for lj:=0 to 1000000 do
               begin

               end;
               {if (li mod 1000=0) then
               begin
                   WriteLn( li);
               end; }
            end;
        Writeln( IntToStr(GetTickCount - st));
        Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

c++:

Code:

#include "stdafx.h"
#include <iostream>
#include <windows.h>
using namespace std;
#pragma optimize( "", off )

int main() {
   int i, j, k;
   DWORD st = GetTickCount();

   for (i = 0; i < 50000; i++)
      for (j = 0; j < 1000000; j++)
      {
         
      }

   DWORD et = GetTickCount();

   cout << (et - st);
   cin >> i;
   return 0;
}

[luisk]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310355)

Das Ergebnis ist das bei blödsinniger permanenten GUI-Aktualisierung (welche die Funktionzeit eh vervielfacht) Delphi schneller diese blödsinnige Permanete GUI-Aktualsierung durchführen kann. Weiter Aussagen zu Performancevergleich Delphi <-> C# lassen sich nicht ableiten.

Wohl übersehen, was dieses li mod 1000 bewirkt?

Delphi-Quellcode:

if (li mod 1000=0) then begin
                   button1.caption := inttostr(li);
                   button1.Update();
       end;

[Bernhard Geyer]

Vor einiger Zeit (mehrer Jahre) gabs mal 2-3 Artikel bezüglich Performancevergleich C/C++/Java/C# und Delphi.

Ergebnis war:

Im "Number-Crunshing" ist C/C++ vorne
In "normalen" Entwickeralttag (Objektorientierte Programmierung, Ableitung, Überladen von Methoden, ...) sind Delphi/Java/C# ähnlich schnell.
C++ war hier der "einsame" Verlierer.

[Daniel]

Es sollte schon allen klar sein, dass hier "nur" alle 1000 Durchläufe der Button aktualisiert wird. Aber bei 50 Mio. Durchläufen ist auch das schon einiges. "Einiges" im Sinne von "derart viel, dass es so sehr ins Gewicht fällt, dass alles andere quasi weggedrückt wird".

[Bernhard Geyer]

Zitat:

Zitat von luisk (Beitrag 1310373)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310355)

Das Ergebnis ist das bei blödsinniger permanenten GUI-Aktualisierung (welche die Funktionzeit eh vervielfacht) Delphi schneller diese blödsinnige Permanete GUI-Aktualsierung durchführen kann. Weiter Aussagen zu Performancevergleich Delphi <-> C# lassen sich nicht ableiten.

Wohl übersehen, was dieses li mod 1000 bewirkt?

Delphi-Quellcode:

if (li mod 1000=0) then begin
                   button1.caption := inttostr(li);
                   button1.Update();
       end;

Nein, habe ich nicht! Genau so eine Logik haben/hatten wir hier auch in unserer Anwendung drin.
Wenn aber so ein Mod-Vergleich alle 1 ms kommt ist trotzdem die GUI-Aktualiserung das bremsende Element.
Haben mittlerweile ein Basisklass/Codefragement/Methode das eine "if DelayToLastUpdate > 300ms"-Abfrage drin hat.
Damit wird die GUI nur alle 300 ms aktualisiert (Und erst nach Aktualisierung wird die Vergleichszeit neu gestartet)
Damit habe ich Zeiten für länger andauernde Aktionen teilweise auf 1/5 der ursprünglichen Zeit verkürzen können.

[luisk]

Zitat:

Zitat von mkinzler (Beitrag 1310365)

C# (2015) benötigt sogar etwas weniger als Delphi (16,6 Sekunden)

Das heißt, bei Dir läuft der Code in C# genauso schnell wie in Delphi, bzw. einen Tick schneller ?
Kann es sein, dass die Express-Edition von Microsoft nicht die volle Leistung bringt ?
http://www.chip.de/downloads/Visual-..._36594529.html

ich hab jetzt auch mal die Konsolen-Beispiele von mkinzler auf Delphi und C# Express 2015 mit der Hauptschleife bis 5000 laufen lassen.
Delphi war in 1,684 Sekunden fertig,
C# Express 2015 nach 19,797 sec.

Wird die Express Edition demnach von Microsoft ausgebremst ?

[stahli]

Zitat:

Zitat von luisk (Beitrag 1310373)

Wohl übersehen, was dieses li mod 1000 bewirkt

Ich hab Dich ja oben noch in Schutz genommen. ;-)
Aber andererseits haben die Kollegen natürlich Recht, dass das Testbeispiel nicht wirklich taugt.
Wenn es auf Performance ankommt, sollte man kein GUI-Refresh dazwischen schieben.
Wenn man dies macht, kann einem die Performance nicht so wichtig sein.

Also Deine Anforderungen sind da nicht wirklich klar.
Was willst Du denn eigentlich erreichen?

[BUG]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310375)

C++ war hier der "einsame" Verlierer.

Hu, wirklich? Da würde ich gerne mal was genaueres drüber lesen.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310378)

Damit habe ich Zeiten für länger andauernde Aktionen teilweise auf 1/5 der ursprünglichen Zeit verkürzen können.

Da gab es mal was schönes in Gamasutra: Don't Sync and Load.

[Bernhard Geyer]

Zitat:

Zitat von BUG (Beitrag 1310383)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310375)

C++ war hier der "einsame" Verlierer.

Hu, wirklich? Da würde ich gerne mal was genaueres drüber lesen.

http://www.heise.de/artikel-archiv/c...el-Duesentrieb
http://www.heise.de/artikel-archiv/c...el-Duesentrieb

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1310382)

Also Deine Anforderungen sind da nicht wirklich klar.
Was willst Du denn eigentlich erreichen?

:thumb:
Gute Frage. Solche Aufgaben/Anforderungen kommt mir verdächtig nach
"Wir haben schon immer mit Delph/C/Java/..." gemacht und jetzt sollen wir was anders machen. Schnell mal schauen ob wir Killerargumente finden".