Der anfang vom Ende von (Embarcadero-) Delphi

[mschnell]

in beide Fällen 8 zu 3 für Java :-(Gruß, Bernd.

Gilt bei 64 Bit Systemen anscheinend nicht nur für Java, sondern auch für CLR. Bei 64 Bit Systemen ist auch der Dateigrößen-Vorteil von FPC nicht mehr so relevant.

-Michael

[ovidius]

Vielleicht darf ich mal einen weiteren Punkt hinzufügen:

Sicherlich ist nativer Byte-Code in den meisten Fällen schneller, aber zumindest ich meine momentan einen Trend in Richtung Web-Apps zu sehen, die ganz sicher nicht schneller, als normale Anwendungen sind, aber sie werden trotzdem benutzt. Geschwindigkeit spielt bei vielen (einfachen) Anwendungen doch eine untergeordnete Rolle und dann Rest kann man dann auf die entsprechenden nativen Frameworks schaufeln, wenn man eine Desktop-Anwendung schreiben will.

Mir jedenfalls gefällt der Gedanke, das ich mit einem Delphi-Produkt auch direkt für den Mac mit Cocoa entwickeln könnte, in der Sprache meiner Wahl. Kaufen werde ich das ganze aber sicher nicht.

Ingolf

[Christian]

Es ging ja eher darum: Warum JIT oder interpretierten Code nehrmn wenn man genauso einfach nativen Code haben kann

[Euklid]

(Manche Javas sind übrigens etwa gleich schnell wie Free Pascal....)

Bei den 64-Bit Maschinen sieht es dann gar nicht mehr so gut aus für Free Pascal:

Wenn man sich den Sourcecode der 64bit-FPC-Tests mal anschaut: Der ist nicht für 64bit-Maschienen geschrieben, sondern nur für 32bit-Maschienen - er nutzt die Vorteile von 64bit also nicht aus. Verwendet 32bit Datentypen, vezichtet auf die Nutzung von CPU-Einheiten, u.s.w.

Zusammengefasst: FreePascal ist in den 64bit-Tests nicht zuletzt deshalb vergleichsweise langsam, weil sich noch niemand die Mühe gemacht hat, den Code an 64bit anzupassen.

[mschnell]

Anscheinend ist in diesem Fall der Code des Java JIT Compilers und des CLR Compilers und die Library Funktionen der Frameworks in der Lage, von der 64-Bit Architektur mehr zu profitieren als der 64-Bit direct-native-Code Compiler.

-Michael

[Euklid]

Anscheinend ist in diesem Fall der Code des Java JIT Compilers und des CLR Compilers und die Library Funktionen der Frameworks in der Lage, von der 64-Bit Architektur mehr zu profitieren als der 64-Bit direct-native-Code Compiler.

mschnell: Der maßgebliche Geschwindigkeitsvorteil von 64-Bit liegt in den _rechenintensiven_ Tests darin, dass dank der Registerbreite von 64bit (statt 32) nun größere Zahlen mit gleicher IPC verrechnet werden können. Im Idealfall kann dadurch die Rechenzeit fast halbiert werden. Voraussetzung ist natürlich die Verwendung von 64bit-Variablen im Programm.

Wenn man sich den Quelltext der FPC-Tests mal anschaut, wird man feststellen, dass ausschließlich 32bit-Variablentypen verwendet werden.

Wie soll das Programm dann von einer 64bit-Architektur profitieren, so wie du es offenbar verlangst?

[mschnell]

Wenn man sich den Quelltext der FPC-Tests mal anschaut, wird man feststellen, dass ausschließlich 32bit-Variablentypen verwendet werden. Wie soll das Programm dann von einer 64bit-Architektur profitieren, so wie du es offenbar verlangst?

Wenn ich mich nicht täusche sind die Java und C# Versionen des Sourcecodes ebenfalls nicht auf 64 bit optimiert.

Leider ist auf der Test-Website kein Vergleich 32-Bit 64 bit möglich. Ich habe aber gehört, dass viele für 32 Bit geschriebenen FPC (und C/C++) - Programme auf 64 Bit übersetzt langsamer werden. Java und CLR - Programme scheinen auf 64 Bit schneller zu werden.

-Michael

[Christian]

Java und c# können das aber zur Laufzeit optimieren was der fpc nicht kann.

[mschnell]

Java und c# können das aber zur Laufzeit optimieren was der fpc nicht kann.

Verstehe ich nicht.

Von Java habe ich gar keine Ahnung, aber C# ist - soweit ich weiß - recht ähnlich zu Object Pascal. als z.B. "streng typisiert". Man muss also für jede Variable einen Typ angeben. Und der hat eine mindest-Anzahl an Bits. sind die Zahlen kleiner, werden die oberen Bits nicht verwendet. Das User-Programm muss sicherstellen, dass für die Aufgabe genügend Bits im Typ vorhanden sind. Und wenn der Sourcecode von 32 Bits ausgeht, weiß ich nicht, wie der Compiler besser optimieren soll, wenn er weiß, dass 64 Bits zur Verfügung stehen.

Außerdem wird bei C# genauso ein Compiler verwendet wie bei FPC. Dass der letzte Compile-Schritt erst beim Laden passiert und nicht schon beim Erstellen der "ausführbaren" Datei ist im Grunde völlig unerheblich. Eigentlich ist das sogar ein Nachteil für C#, weil der FPC schon von Anfang an weiß, dass er für 64 Bit übersetzen soll, während C# die Datei ohne diese Kenntnis erstellen muss: sie muss auch auf 32 Bit Systemen verwendbar sein.

Die 64-Bit Version von FPC ist offensichtlich nicht sehr effektiv. (GNU C ist in diesen Tests bei 32 Bit ein wenig flotter als FPC, im 64 Bit Modus ist es aber erheblich schneller.)

Was mich bei der ganzen Sache am meisten erstaunt, ist dass Java fast immer schneller ist als C#. Das hätte ich nicht gedacht. Es wäre 'mal interessant die ergebnisse von verschiedenen Frameworks zu vergleichen: Java: (keine Ahnung welche es da gibt), C# (CLR): .Net und Mono.

-Michael

[Christian]

Der code wird aber vor der Ausführung compiliert. Und der Compiler kann dort auf der Maschiene entscheiden das es keinen Sinn macht mit 32 bit Variablen zu arbeiten und bastelt die selbst auf 64 bit um weils dann schneller ist.
Du ziehst daraus schon wieder schlüsse

Die 64-Bit Version von FPC ist offensichtlich nicht sehr effektiv.

Die einfach falsch sein können. Da du gar keine Hintergünde kennst. Das ziehst sich jetzt schon über mehrere Theman hin.
Der fpc hat einfach keine Chance auf die maschiene zu optimieren auf der der Code ausgeführt wird. Das hat c# und java.

[mschnell]

Der fpc hat einfach keine Chance auf die maschiene zu optimieren auf der der Code ausgeführt wird. Das hat c# und java.

Warum sollte der fpc wenige Chancen haben als GNU C ?

Warum hat FPC keine Chance ? Es wird doch die 64 Bit version des FPC eingesetzt (oder habe ich da was falsch verstanden ? )

(Nur am Rande: C# hat tatsächlich u.U. weniger Chancen, weil hir nur der letzte Übersetzungsschritt (den das Framework vollzieht) weiß, dass es sich um ein 64 Bit und nicht um ein 32 Bit System handelt, die CIL-Datei wird unabhängig davon identisch erzeugt. Aber Deine Antwort bezog sich auf den von mir aus den angegeben Tests zitierten Ergebnissen für FPC und GNU C.)

-Michael

[Christian]

Warum sollte der fpc wenige Chancen haben als GNU C ?

Jetzt werf doch nicht noch mehr durcheinander. C ist nicht Objektorientiert und dadurch schneller.

Warum hat FPC keine Chance ? Es wird doch die 64 Bit version des FPC eingesetzt (oder habe ich da was falsch verstanden ? )

Da hast du eig recht. Fpc ist da etwas strenger er könnte aber Warnungen ausgeben.
Fpc geht halt davon aus das der Programmierer zumindest in der Variablenwahl weiss was er tut. Wie gcc oder gnu c auch.

[Euklid]

Die 64-Bit Version von FPC ist offensichtlich nicht sehr effektiv.

Michael: Mach dir doch bitte mal die Mühe und vollziehe unsere Begründung nach. Ich kann auch kein Java, aber das die Optimierung des Java-Quelltextes bei alioth wesentlich besser ist als die des FPC-Quelltextes ist völlig offensichtlich.

Beispiel: Quelltext zur Mandelbrot-Menge.
FPC: http://shootout.alioth.debian.org/u64/b ... ascal&id=3" onclick="window.open(this.href);return false;
Java: http://shootout.alioth.debian.org/u64/b ... &lang=java" onclick="window.open(this.href);return false;

Der Intel Q6600 ist nicht nur ein 64bit-, sondern auch ein Vierkernprozessor. Diese Profitieren besonders vom Multi-Threading, welches sowohl mit Java als auch mit dem FPC möglich ist, da so die Rechenlast auf die Threads und die Threads auf die unterschiedlichen Prozessorkerne verlangert werden kann.

Der FreePascal-Quelltext ist hier wenig optimiert - die ganze Berechnung erledigt nur einer von den vier Kernen des Prozessors. Nun werfen wir mal einen Blick auf den Java-Quelltext.

... wieviele Kerne gibt es denn...?

Code: Alles auswählen

public mandelbrot(int size) {
        this.size = size;
        fac = 2.0 / size;
        nThreads = Runtime.getRuntime().availableProcessors();
    }

... starten wir doch ein paar Threads...

Code: Alles auswählen

public RowRenderer() {
            workBuf = new byte[(size + 7) / 8];    // Length = ceil(size/8)
            rowReady = false;
            row = -1;
            Thread thread = new Thread(this);
            thread.setDaemon(true);
            thread.start();
        }

... und zwar so viele, wie Kerne vorhanden sind.

Code: Alles auswählen

RowRenderer[] r = new RowRenderer[nThreads];
        for (int i = 0; i < r.length; i++)
            r[i] = new RowRenderer();

Nicht Java, sondern der verwendete Java-Quelltext ist intelligent. Denn die Rechenlast wird auf alle Kerne verteilt.

Der FPC-Quelltext ist dagegen überhaupt nicht optimiert. Vergleiche obigem Quelltext mit dem Quelltext für die 32bit-Maschiene
http://shootout.alioth.debian.org/gp4/b ... ascal&id=3" onclick="window.open(this.href);return false;
und du wirst feststellen: Der Quelltext ist identisch.

Offenbar hat sich bei Pascal noch niemand die Mühe gemacht, den Quelltext an moderne Prozessor-Architekturen anzupassen. Kein Wunder - die Community ist auch viel kleiner als bei Java.

Aussagen wie "der FPC arbeitet für 64bit-Architekturen offensichtlich nicht effektiv" nur auf solche ungleiche Vergleiche zu stützen greifen zu kurz und schädigen mehr als das sie helfen.

[marcov]

Wenn Delphi auf Mono anstelle von MS.NET setzen würde, könnte die IDE auch auf Linux und MacOS laufen.

Und wann ich fluegel hatte, kontte ich fliegen. Wir haben schon mit "Kylix" gesehen wie schlecht Codegear portabilitaet versteht.

[marcov]

Wie kommst du auf "Der anfang vom Ende"? Ist doch gar nicht so dumm...

Hab' ich gesagt, dass ich das dumm finde ? Im Gegenteil !
Meine Überlegung: Delphi geht seit Jahren Richtung .NET (Ohne installiertes .NET Framework, kann man dioe IDE garnicht installieren).

Das IDE issue ist ganz irrelevant. Wie ich das verstanden habe, ist das nur wegen das die neueren (D2005+) Codetools vom Together team kommen und in Java geschrieben sind, und die man via j# ans laufen hat bekommen. (und man kan die in D2006 sogar rausholen glaube ich). ES IST KEIN .NET SPRACHE IN DER IDE (bis D2006 lediglig)

Der von Codegear (oder wem auch immer) auggezeigte Upgrade-Pfad für die Zukunft, die in .NET gesehen wurde, war "Delphi for .net". und das wird nun eingestellt und durch das (sicherlich viel besser geeignete) Prism (=Oxygene) ersetzt. Daraus folgt: Keine Zukunft für Delphi .

Oder das wird einfach fehl slagen, wie alle andere versuchen von Codegear die Delphi massen von win32 ab zu lenken. Kylix, Delphi.NET usw.

Wenn menschen 3 jahren MS+CG propaganda ueberlebt haben, haben sie veilleicht einen grund um nicht .NET zu machen.