Delphi vs. C# vs C++

[luisk]

Hier noch das Consolenprogramm von mkinzler
das ist unter C# 2008 in 4,134 sec durch !:idea:
Von wegen, der Code eignet sich nicht zum Performancevergleich !
C# ich staune, dachte immer, die VM wäre lahm.
Das mit dem Debuggen läuft halt nicht so flott wie bei Delphi.
Von 10 mal so langsam zu 3 mal so schnell bei c#2008, ist doch ne super Erkenntnis !

Code:

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

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

[Dalai]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310433)

Wie schon gesagt: Wer Mist mist, mist Mist.

Durch Wiederholung wird die Schreibweise nicht richtiger. Korrekt (nach aktueller Rechtschreibung): Wer Mist misst, misst Mist. Nach alter Rechtschreibung würde man die ss mit ß ersetzen. SCNR

MfG Dalai

[Bernhard Geyer]

Zitat:

Zitat von Dalai (Beitrag 1310435)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310433)

Wie schon gesagt: Wer Mist mist, mist Mist.

Durch Wiederholung wird die Schreibweise nicht richtiger. Korrekt (nach aktueller Rechtschreibung): Wer Mist misst, misst Mist. Nach alter Rechtschreibung würde man die ss mit ß ersetzen. SCNR

MfG Dalai

Ändert aber nix an der Aussage

[Dalai]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310436)

Ändert aber nix an der Aussage

Das hab ich ja auch nicht gesagt. Und ich stimme dir zu. Ich wollte nur die Schreibweise korrigiert wissen. Wir sind zwar nicht Google, die "first come first serve" mit "Wer zuerst kommt, malt zuerst" übersetzen, aber dennoch ;).

Sorry für OT.

MfG Dalai

[luisk]

Entscheidend bei den Messungen ist wohl das Kennen der Randbedingungen.
Für den eingangs gezeigten Code ist nun eines klar:

Delphi 6 : ca. 15 bis 16 sec. (Debug und Release) Super gut zu testen, da Debug so schnell wie Release.
C# 2015 : ca. 15 bis 16 sec. (Release) seltsam umständlich zu erstellen !
C# 2008 : ca. 4,2 sec. (Release) erstaunlich schnell !

C# 2015 : ca 199 sec im Debugmodus
C# 2008 : ca 118 sec im Debugmodus

damit kann man den gemessenen Mist schon mal etwas beurteilen.
Das tolle an Delphi ist, dass der Debugmodus im Prinzip genauso schnell ist, wie das Release.
Bei großen Datenmengen wird die Testerei bei C# wohl etwas langwierig.

Warum noch Delphi 6 ? Weils immer noch gut ist für Windows .... 32 Bit Anwendungen !

[creed steiger]

Zitat:

Zitat von luisk (Beitrag 1310439)

Warum noch Delphi 6 ? Weils immer noch gut ist !

Ergänzung:
Für den Anwendungsfall OS:Windows .... 32 Bit Anwendung erstellen

[mkinzler]

Fahradfahren ist auf einem Gehweg schneller als Stehen. Deshalb ist das Fahrrad auch das am Besten geeignete Fahrzeug für eine Reise zum Mars.

[Medium]

Abgesehen davon, dass dein Test auch nach Aquirierung von mehr Ergebnissen noch genau so aussagenbefreit ist wie zu Anfang, hier ein paar Gründe, warum Leute mit Sprachen programmieren, für die fragwürdige "Benchmarks" eher negativ ausfallen:

Für den gewerblichen Entwickler stellt sich die Frage nach roher Performance fast nie. Den weitaus größeren Optimierungsanteil findet man da eher auf ein paar Ebenen darüber, wie die verwendeten Algorithmen, das Design im Allgemeinen usw.
Der gewerbliche Entwickler muss auch gewaltig auf seine Produktivität achten. Wenn er gut in einer Sprache bzw. einem Framework geschulte Leute hat, kann ein Wechsel um ein paar Sekunden Laufzeit zu verkürzen gleich auch mal das nächste Release um Monate verschieben. Bis da hin ist die Firma in vielen Fällen platt, oder zumindest hinter der Konkurrenz. Hier ist auch extrem relevant, dass fast jedes Unternehmen auf millionen von Zeilen Legacy-Code sitzt, und nicht jeder Betrieb ist derart gut betucht, dass er mal eben einen kompletten Rewrite seiner gesamten Code-Basis stemmen kann. (Selbst wenn die Produkte an sich eigenständige Einheiten sind, die ohne Vorgängerversion waren, verliert man dennoch einen Haufen an Codefetzen, die man immer wieder mal einsetzt und Wochen einsparen können.)
Dort spielt auch die "Support-Infrastruktur" mit herein. Wenn ich für Delphi die Docs im Schlaf bedienen kann, meine Stammforen als Nachschlagewerke habe, weiss wo ich Komponenten und Codefetzen schnell beziehen kann, dann sind das alles Dinge, die ich mir über Jahre zusammengesucht und erprobt habe. Wechsle ich nun auf eine andere Sprache, hänge ich erstmal mächtig in der Luft. Das habe ich am eigenen Leibe erfahren, als ich für meine Bachelorarbeit interessehalbar erstmals C#, und auch gleichzeitig das erste Mal DirectX in die Hand genommen habe. Bis ich den ersten Code hatte, der ansatzweise das Erwartete gemacht hat, ist richtig Zeit vertrichen. Wohl dem, der früh genug anfängt. In der freien Wirtschaft hat man solche Leerläufe nicht.

Die Denke: "Ist langsamer, ich muss das andere nehmen" ist ausgeprochen kurzsichtig und, mit verlaub, kindisch und naiv. (Ich würde sogar ähnliche Adjektive für deinen konkreten "Test" hier ansetzen.)

Das zusammen mit der Tatsache, dass du seit 8 Seiten es nicht gebacken bekommst uns mitzuteilen welchem Zweck dein "Test" nachher dienen soll, lässt nur einen Schluss zu: Du vergeudest deine (und unsere) Zeit mit komplett irrelevanten Dingen, deren größerer Echtweltbezug mindestens höchst fragwürdig ist.

[jaenicke]

Auch wenn es schon ein paarmal geschrieben wurde...

Zitat:

Zitat von luisk (Beitrag 1310434)

Von 10 mal so langsam zu 3 mal so schnell bei c#2008, ist doch ne super Erkenntnis !

Dein Vergleich ist als ob du zwei Autowerkstätten vergleichst.

Du bringst in beide Werkstätten ein Auto mit Anhänger zum Tuning, weil du damit schnell eine größere Strecke zurücklegen möchtest.
Die eine Werkstatt schraubt jetzt den Anhänger ab, weil du ihn auf der Strecke gar nicht brauchst, die andere lässt ihn dran.

Und du vergleichst dann welches Auto schneller ist. Logisch, dass das Auto schneller ist, an dem der nutzlose Anhänger abmontiert wurde, oder?

Und genauso ist es bei deinem Code. Du packst eine leere Schleife hin, der eine Compiler merkt, dass sie nutzlos ist, und entfernt sie, der andere setzt deinen Code 1:1 um.
(Leere Schleifen kann man schließlich auch selber entfernen...)

Und jetzt vergleichst du welcher Code schneller ausgeführt wird. Logisch, der, bei dem die Schleife gar nicht mehr da ist zur Laufzeit.

Wenn du so etwas zumindest etwas realistischer vergleichen willst, musst du erstens in die Schleife auch etwas hineinpacken und darfst keine externen GUI Aufrufe oder ähnliches einbauen, weil die unberechenbare Auswirkungen haben und nichts mit der Umsetzung des Codes des Compilers zu tun haben.

[Daniel]

Moin,


dieses Thema bereitet mir Kopfschmerzen, weil der Themen-Ersteller gegen eine Wand läuft und aktuell nicht erkennst, dass da etwas im Weg ist. Selten waren sich die Foren-Teilnehmet so einig, dass dieser Weg der Vergleichsmessung nicht zum Ziel einer generellen Aussage führen kann. Die Gründe dafür wurden mehrfach genannt.

Performance-Messungen sind - so sie aussagekräftig sein sollen - mit erheblichem Aufwand verbunden, allein um eine Vergleichsfähigkeit der beteiligten Parteien wenigstens halbwegs herzustellen. "Kompilieren & Gucken was passiert" geht nicht einmal im Ansatz in Richtung dieses Ziels (insbesondere, wenn man sich in den Debug- und Release-Konfigurationen verheddert).


Ich mache hier mal zu.