Der anfang vom Ende von (Embarcadero-) Delphi

[marcov]

(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:
http://shootout.alioth.debian.org/u64/b ... g2=fpascal" onclick="window.open(this.href);return false;
http://shootout.alioth.debian.org/u64q/ ... g2=fpascal" onclick="window.open(this.href);return false;

in beide Fällen 8 zu 3 für Java

Aber das mit 5 Freizeit developer gegen IBM und Sun kombiniert

[mschnell]

C ist nicht Objektorientiert und dadurch schneller.

FPC ist nur Objekt-orientiert, wenn man auch den Code auch so schreibt.

Man müsste sich jetzt natürlich die Beispiele auf der Tast-Website im einzelnen ansehen um es genau nachzuvollziehen. Ich bin davon ausgegangen, das die da von C-Code ausgegangen sind und diesen mit so wenig Änderungen wie möglich in den verschiedenen Sprachen nachvollzogen haben - und vielleicht bei entsprechenden Testfällen noch ein paar Sprach-typische Optimierungen eingebaut haben, aber sicherlich keine Verschlimmbesserungen wie Objekt-Orientiertes Programmieren, wenn es nicht sinnvoll ist. Sonst wären die Tests ja wenig aussagekräftig.

Aber bei dem eigentlich relevanten Thema hier, wäre es natürlich viel sinniger, einen Test FPC gegen Prism/Oxygene (Auf .NET und MONO, auf 32 Bit und 64 Bit) zu machen. Dabei kann man recht ähnlichen Sorcecode verwenden (Ich glaube nicht, dass viele der Testbeispiele eine stakt Veränderte Programmierung für Prism/Oxygene nahelegen, die im CLR-Umfeld starke Optimierung bringen würde.)

-Michael

[mschnell]

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...?
... starten wir doch ein paar Threads...

Ein solche Vergleichs-Test ist natürlich völlig daneben ! Da sollte man die d'rauf hinweisen und mit entsprechendem Pascal-Code versorgen ! Kannst Du das tun ?

Man kann sich ja auf dieser Seite die eine 64 Bit 4-Prozessor Version und eine einfache 64 Bit Version Version aussuchen. Ich hatte mir die "einache" ausgesucht und bin davon ausgegangen, dass da nur ein Prozessor verwendet wird (aber kann man dem trauen ? ). Auch da ist Java fast überall schneller als FPC.

Offenbar hat sich bei Pascal noch niemand die Mühe gemacht, den Quelltext an moderne Prozessor-Architekturen anzupassen.

Wer traut sich ?!?!?!?

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.

Da hast Du natürlich recht. Aber auch das Gegenteil der spekulativen Aussage ist nicht mit Testergebnissen belegt.

Ich würde sehr gerne Vergleichstests mit entsprechend optimiertem Code für verschiedene Prozessoren (single core / dual core / quad core, 32 Bit / 64 bit) sehen. Vor allem der Vergleich FPC zu Prism/Oxygen wäre hier natürlich interessant.

-Michael

[mschnell]

... in beide Fällen 8 zu 3 für Java
Aber das mit 5 Freizeit developer gegen IBM und Sun kombiniert

Die ursprüngliche Behauptung war, dass native Code (eines sagen wir 'mal "ordentlichen" Compilers wie FPC) grundsätzlich wesentlich (die Annahme war mindestens 10 mal) schneller sei als nicht-Native-Code (der ein Framework benötigt Java Runtime oder CLR <=-.NET oder Mono).

Die FPV/Java Vergleichstests auf der angesprochen Website behaupten bei 32 Bit etwa Gleichstand bei 64 Bit eher das Gegenteil der ursprünglichen Annahme.

Jetzt ist die Frage, warum das so ist, und (weil es doch peinlich für die FPC/Lazarus Community ist, das so ein Ergebnis dort zu sehen ist) ob wir was dagegen tun können.

-Michael

[Euklid]

Jetzt ist die Frage, warum das so ist, und (weil es doch peinlich für die FPC/Lazarus Community ist, das so ein Ergebnis dort zu sehen ist) ob wir was dagegen tun können

Ein erster Schritt würde vielleicht darin bestehen, den Code Multithreaded zu machen und für 64bit zu optimieren.

Kannst Du das tun ?

Bei mir ist das immer ein Problem der Zeit - ich nehme an, es ergeht dir (und den anderen) ähnlich. Daher würde ich vorschlagen, dass wir - wenn wir uns dafür entschließen - den Code gemeinsam über dieses Forum optimieren und so die Arbeitslast teilen.

Was hältst du/ haltet ihr davon?

EDIT: Übrigends, bei dem Test, bei dem zwangsläufig alle Sprachen multithreaded programmiert sind, dem thread-ring, ist der FPC auch auf dem Intel Q6600 führend. Ich bin mir ziemlich sicher, dass wir durch einen optimierten Quellcode den FPC auf einen der forderen Tabellenplätze (nahe beim gcc) des Rankings hiefen könnten. Wäre bestimmt ne gute Werbung für den FPC.

[mse]

Jetzt ist die Frage, warum das so ist, und (weil es doch peinlich für die FPC/Lazarus Community ist, das so ein Ergebnis dort zu sehen ist) ob wir was dagegen tun können.

Der just in time Compiler kann den Code auf den tatsächlich angetroffenen Prozessor optimieren. Da FPC Programme auf einer ganzen Familie von Prozessoren laufen sollen, darf FPC die Optimierung nicht so aggressiv vornehmen.
Ich habe gelesen, dass FPC die zusätzlichen X64 Register nicht optimal ausnützt. Da 64Bit Code die Cache-Haltung und die Datenbusse stärker belastet, kann es tatsächlich vorkommen, dass 64Bit FPC-Programme auf dem gleichen Prozessor langsamer laufen als das 32Bit Äquivalent.
Das Argument, dass durch die 64Bit breiten Register schneller gerechnet wereden kann, trifft nur in Spezialfällen zu, da übliche Programme gar keinen so grossen Wertebereich für die Variablen brauchen. Für Boolean wird beispielsweise lediglich ein Bit benötigt.
Tun können "wir" dagegen vermutlich nichts, da die Implementierung von besseren Optimierungsalgorithmen in den Compiler absolute Spezialistenarbeit ist.

Martin

[mschnell]

(Ich glaube nicht, dass viele der Testbeispiele eine stakt Veränderte Programmierung für Prism/Oxygene nahelegen, die im CLR-Umfeld starke Optimierung bringen würde.)

Korrektur: Für ernsthafte Tests auf Multicore-Prozessoren, müsste man bei FPC explizit mit Threads programmieren, während Oxygen mit "parallel" eine komfortable Syntax zur Parallelisierung zur Verfügung stellt. (Das basiert da natürlich auf dem Framework, dieselbe Syntax ließe sich aber auch relativ einfach - unter automatischer Verwendung von Thredas in der RTL - in FPC einbauen. Solange es das nicht gibt, müsste der Anwendungsprogrammierer eben explizit TThread verwenden. Keine Kunst aber einige Mehrarbeit.)

-Michael