Solche Benchmarks sind zwar eine lustige Übung, im Sinne von wie schnell kann ich einen bestimmten Code bekommen, aber so Vergleiche hinken hinten und vorn:
Zum einen sind manche Sprachen nicht auf Performance ausgelegt. Zum Beispiel, Idiomatisches Pascal arbeitet extrem viel mit Klassen (deshalb "Object" Pascal). Klassen in Pascal haben aber massiven Overhead (
schaut mal in die objpas.inc). Trotzdem ist es ganz normal das um z.B. um eine
einfache Base64 Konvertierung zu machen mal eben 2 Klassen erzeugt werden, virtuelle Methoden aufgerufen werden und am ende wieder gefreed werden. Gewinnt man damit einen Blumentopf was Performance angeht? Nein... Ist das was schlechtes? In den allermeisten Fällen auch nein.
Object Pascal ist keine High Performance Sprache, das ist halt einfach so. Die meisten Anwendungen sind durch Externe Events limitiert. Eine GUI Anwnedung kann eh nicht schneller sein als der Nutzer klicken kann. Ein Server ist durch Netzwerk IO limitiert, etc. Dazu kommt das CPUs mit 4 GHz und 16 Kernen mit Hyperthreading und Predictive Execution so unfassbar schnell sind das es für das allermeiste einfach Schnell genug ist. Es hat einen Grund warum so viel Software heutzutage in Java, C#, Python, Javascript oder anderen VM basierten Sprachen geschrieben wird, obwohl sie ja eigentlich "langsam" sind. Weils einfach egal ist.
Das zweite ist halt das eine Benchmark nur so gut ist wie sie an Idiomatischem Code ist. In deinem Code sehe ich sehr viel Pointer Arithmetik und Rechnen mit Integer typen, aber kurioser weise keine Klassen, keine Vererbung, keinerlei String verarbeitung, etc. Wenn ich aber auf GitHub irgendwelche Open Source Pascal Projekte anschaue ist das aber genau anders rum. Was sagt dieser Benchmark über die tatsächliche Geschwindigkeit von Pascal Code im Feld aus?
Zum Schluss natürlich noch, verschiedene technologien haben verschiedene Stärken und schwächen. Java wird generell als langsamer als Pascal bezeichnet, das stimmt vermutlich im allgemeinen, aber je nachdem was man Testet kann das auch mal ganz anders sein. Vor einiger Zeit hab ich diesen Vergleich im Englischen Forum gepostet:
Code: Alles auswählen
public class Main {
private final int adder;
Main(int a) {
adder = a;
}
int add(int i) {
return i+adder;
}
public static void main(String args[]) {
long startTime = System.currentTimeMillis();
int accum = 0;
for (long i=0;i<1000000000l; ++i) {
Main m = new Main((int)i);
accum=m.add(accum);
}
long endTime = System.currentTimeMillis();
System.out.println("Total execution time: " + (endTime-startTime) + "ms");
}
}
Als Pascal Code:
Code: Alles auswählen
program Project1;
{$mode objfpc}{$H+}
uses SysUtils;
type
TTest = class
private
adder: Integer;
public
function Add(i: Integer): Integer;
constructor Create(a: Integer);
end;
function TTest.Add(i: Integer): Integer;
begin
Result:=i+adder;
end;
Mit dem folgenden Ergebnis:
Code: Alles auswählen
Java: Total execution time: 200ms
Pascal (-O3): Total execution time: 22657ms
Java ist um einen Faktor 100 schneller als der FPC. Bedeutet das das Java die schnellere Sprache ist? Nein es bedeutet nur das das erstellen von Temporären Objekten in Java quasi kostenlos ist, während das erstellen von Klassen in Pascal extrem aufwendig ist.
C und C++ Compiler haben extrem gute Optimierungen, zum einen weil viel Arbeit in die Compiler reinfließt, zum anderen weil die Sprachen dafür gebaut das der Code möglichst viele Infos zum optimieren bereitstellen kann (z.B. über das Typsystem mit sachen wie restricted, const, etc.). Du kannst z.B. auch mit dem FPC das LLVM backend benutzen und hast einen großen Teil der Optimierungen die C und C++ haben damit auch in Pascal. Es wird dennoch ein bisschen was Fehlen weil C und C++ einfach von Sprachdesign her so gebaut sind schneller zu sein
Langer Rede kurzer Sinn: Auf so Benchmarks sollte man eh nicht zu viel geben. Am ende Zählt nur eins: Ist das Werkzeug was ich nutze das richtige für den Job. Mit hinsicht auf Performance: Erreicht FPC die notwendige Performance für ein bestimmtes Projekt, wenn ja, ist egal ob was anderes schneller ist.