Das deutsche QBasic- und FreeBASIC-Forum

[Marc Bonus]

Vielleicht finde ich hier Gleichgesinnte. Mich würde es interessieren, wie schnell die verschiedenen Sprachen sind. Natürlich ist ein Vergleich nicht einfach. Habe im Web auch nicht genau das gefunden was ich suchte. Das hier ist schon ähnlich, doch nur mit Strings, darum schneidet Perl so gut ab:

https://raid6.com.au/~onlyjob/posts/arena/

Doch so ähnlich könnte man es aufbauen. Ein Testprogramm, das die wichtigsten Operationen in Schleifen misst, das dann in alle Sprachen übersetzt werden könnte, wie am Ende des Links gezeigt. Dieses Testprogramm sollte möglichst einfach sein, damit es leicht übersetzt werden kann.

Die erzeugten .exe-Dateien könnten dann die benötigte Zeit ausgeben und auf einem Referenzrechner gestartet werden. Dann werden alle Werte in ein Koordinatensystem eingetragen und wir haben einen Vergleich.

[grindstone]

Es würde mich sehr wundern, wenn das nicht irgend jemand schon eingehend untersucht hätte...

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[Marc Bonus]

Also, ich habe so schnell nichts gefunden im Web. Wo wäre denn so etwas zu finden?

[Marc Bonus]

Das Programm zum Test könnte etwa so aussehen, in einem spontanen ersten Entwurf:

[nemored]

http://benchmarksgame.alioth.debian.org/
mit einem schönen Zitat:

[Marc Bonus]

[nemored]

Nun, wie einfach es ist, mit Perl ein Grafikfenster einzurichten, weiß ich nicht - bei Scheme z. B. würde mir da von vornherein jeglicher Ansatz fehlen. Man kann natürlich Allegro nutzen, aber das ist ja dann eigentlich C. Für Perl würde mir als erstes GD einfallen (aber das ist auch wieder C).
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Marc Bonus]

Fürs Erste könnte man C, PureBasic und XProfan nehmen, das wären die Sprachen die ich installiert habe.

[Jojo]

Bei C hinge das Ganze dann schon wieder davon ab, welche Grafikbibliothek du verwendest, wenn du überhaupt eine nutzt, und auf welchem Wege die Grafik dann zum Betriebssystem gelangt, und am Ende kommt es natürlich auch bei allen Sprachen darauf an auf welchem Betriebssystem der Test durchgeführt wird. Generell kommt es häufig nicht auf die Sprache an, sondern auf die Abstraktionsebene, auf der man arbeitet - selbst dein FreeBASIC-Beispiel ließe sich schon dadurch beschleunigen, indem man LINE und CIRCLE durch eine eigene Implementierung ersetzt, die genau auf den getesteten Fall zugeschnitten ist (z.B. bei CIRCLE so implementieren, dass es keine beliebig verformten Ellipsen zulässt, Rechteck-Code in LINE optimieren, etc). Oder man ersetzt die FreeBASIC-Gfxlib durch was ganz anderes. Und schon ist FreeBASIC schneller als FreeBASIC.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[Marc Bonus]

Es sollte mit "Bordmitteln" sein, also bei C dann wohl mit "graphics.h".

Natürlich kommt es bei der Geschwindigkeit auf den Rechner und sein Betriebssystem an, Da gäbe es zwei Möglichkeiten:

1. Alle kompilierten Programme werden auf einem Referenzrechner ausgeführt und verglichen.

2. Alle kompilierten Programme werden nach einem Schema benannt wie "Speedtest C.exe", Speedtest FB.exe" usw. und werden irgendwo zum Download gestellt, sodass jeder den Vergleich selber machen kann.

[nemored]

Ich würde das ganz dann aber umbenennen von "Geschwindigkeitstest von Programmiersprachen" zu "Geschwindigkeitstest von Bibliotheken". Ansonsten ist nämlich alles, was (ausschließlich) in C geschrieben C-Boardmittel; und eine FB-Zeichenroutine mit direktem Speicherzugriff (ebenfalls Boardmittel) ist deutlich schneller als die Gfxlib (ganz einfach, weil man sich im Spezialfall die kostenaufwendigen, aber im Allgemeinen lebensrettenden Sicherheitsprüfungen sparen kann). Wenn du aber Gfxlib mit graphics.h vergleichen willst, in Ordnung. Trotzdem würde ich jede Zeichenroutine (Rechteck, Kreis) extra messen; und auch bei der Kombination zwischen Zeichen- und Berechnungsroutine ist nicht klar, wessen Geschwindigkeit du misst.

Bei zufälligen Größen der Rechtecke und insb. Kreise sehe ich außerdem die Gefahr, dass eines der Testprogramme zufallsbedingt mit überdurchschnittlich großen Kreisen zu tun bekommt und allein deshalb länger rechnen muss.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Marc Bonus]

Das wäre ein Argument, dass der Zufall das Ergebnis ungenau macht. Habe tatsächlich mit dem Testprogramm leicht abweichende Ergebnisse. Warum du aber Kreise und Rechtecke getrennt messen willst verstehe ich nicht.

[Jojo]

Bei C gibt es wie gesagt keine eingebaute oder standardisierte Grafikbibliothek - es gibt viele verschiedene, von denen man sich die aussucht, die dem Zweck am besten entspricht. Das könnte hier z.B. SDL sein, was auch direkt unter FB verwendbar wäre, und ein messbarer Unterschied wäre dann (sofern das Rahmenprogramm sinnvoll programmiert ist) nicht vorhanden.

[Marc Bonus]

Vielleicht könnte man auch noch mehr Befehle in den Test aufnehmen und einzeln messen. Das macht es aber komplizierter in andere Sprachen zu übersetzen. Ich selber will auch nicht behaupten, ich hätte den vollen Überblick, welche Befehle besonders signifikant für die Geschwindigkeit wären.

Obiges Programm ist nur ein erster Entwurf, es bringt um rund 10% abweichende Ergebnisse. Absolute Exaktheit sieht anders aus.

Aber hier sieht man in dem Link von Nemored in der unteren Grafik, dass ein Geschwindigkeitsvergleich möglich ist:

http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html

Links sieht man C erwartungsgemäss sehr schnell. Free Pascal ist verglichen damit schon eine Schlaftablette. Perl und Lua völlig abgeschlagen. Da sieht man wie verzerrt die Darstellung im ersten Link war.

Nun müsste man wissen wo FreeBasic da liegt...

[grindstone]

Perl und Lua sind Scriptsprachen und deshalb schon vom Prinzip her langsamer als Compilersprachen wie C oder FB. Und Pascal wurde zu Lehrzwecken entwickelt, um Anfängern das strukturierte Programmieren beizubringen. Die Arbeitsgeschwindigkeit war dabei (ebenso wie die Praxistauglichkeit) zweitrangig.

Die meisten Programme, die heute auf Superrechnern laufen (Klimamodelle, Wetterprognosen etc.), sind übrigens in FORTRAN geschrieben.

[nemored]

Wieso verzerrt? Dass Perl z. B. bei Grafik nicht gut so gut abschneidet, ist völlig klar - die Sprache hat vollkommen andere Ziele. Und das Hauptziel von Lua ist nicht die Geschwindigkeit im Vergleich zu Compilersprachen, sondern seine effiziente Verwendbarkeit als eingebettete Skriptsprache - geringe Interpretergröße, Speichereffizienz - und in diesem Rahmen auch eine hohe Ausführungsgeschwindigkeit. In meinem Link findest du eine Vielzahl von getesteten Programmen, und bei weitem nicht immer geht "Sprache X" als Gewinner oder als Verlierer heraus. Je nach Anwendungsgebiet ist das sehr unterschiedlich. (Dass Lua als Skriptsprache langsamer ist als ein compiliertes C-Programm, wundert mich wenig; aber ob sich umgekehrt C als eingebettete Skriptsprache eignet ...)

[Marc Bonus]

[Marc Bonus]

[Jojo]

Die "Lesbarkeit" von C ist eigentlich weniger ein Gegenargument (die meisten modernen Programmiersprachen fußen auf derselben Syntax) - viel wichtiger ist eigentlic eher, dass es verdammt einfach ist, sich in den eigenen Fuß damit zu schießen, weshalb sicherheitsrelevante Software eigentlich auf einem höheren Level programmiert werden sollte. An den vielen { und } wirst du dich spätestens erfreuen, wenn es dir zu langatmig wird, ständig "END FUNCTION" oder so einzugeben.
Man kann übrigens auch nicht einfach sagen dass interpretierte Sprachen immer langsamer sind als kompilierte, da inzwischen z.B. das .NET-Framework oder auch die Java-Runtime einen Just-In-Time-Compiler enthalten, um so kritischen Code (also z.B. Schleifen, die sehr häufig ausgeführt werden) zu kompilieren und zu optimieren, während das Programm läuft. Somit können diese teilweise schnelleren Code für die aktuelle Plattform (z.B. CPU) erzeugen, als ein für die Allgemeinheit (also für mehrere CPU-Typen) vorkompilierter Code.

[nemored]