Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Die schnellste Programmiersprache
Gehe zu Seite 1, 2  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Computer-Forum
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 16.09.2017, 16:08    Titel: Die schnellste Programmiersprache Antworten mit Zitat

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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 836
Wohnort: Ruhrpott

BeitragVerfasst am: 16.09.2017, 18:13    Titel: Antworten mit Zitat

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

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


Zuletzt bearbeitet von grindstone am 16.09.2017, 22:53, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 16.09.2017, 18:25    Titel: Antworten mit Zitat

Also, ich habe so schnell nichts gefunden im Web. Wo wäre denn so etwas zu finden? lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 16.09.2017, 21:47    Titel: Antworten mit Zitat

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

Code:
' Speedtest.bas ' Speed-Test für FreeBasic 1.05

Dim Shared As Double Start,Ende
Start = Timer

DIm Shared As Integer i,x,y,z,x1,y1,x2,y2

#Include "fbgfx.bi"

IF SCREENRES(1024,768,32)THEN
  PRINT "Fehler: Grafikfenster konnte nicht initialisiert werden!"
  SLEEP
  END
END If

Color RGB(0, 0, 0), RGB(255, 255, 255)
Cls

randomize timer
     
' Kreise                               
     For i = 0 To  100000
        x=int(rnd*1024)
        y=int(rnd*768)
        z=int(rnd*768)
        Circle(x,y),z,RGB(int(rnd*255),int(rnd*255),int(rnd*255)),,,,F
     Next
     
' Rechtecke                             
      For i = 0 To  100000
        x1=int(rnd*1024)
        y1=int(rnd*768)
        x2=int(rnd*1024)
        y2=int(rnd*768)
        Line (x1,y1) - (x2,y2), _
               RGB(int(rnd*255),int(rnd*255),int(rnd*255)),BF
     Next

' Linien                           
     For i = 0 To  100000
        x1=int(rnd*1024)
        y1=int(rnd*768)
        x2=int(rnd*1024)
        y2=int(rnd*768)
        Line (x1,y1) - (x2,y2), _
               RGB(int(rnd*255),int(rnd*255),int(rnd*255))
     Next
     
' Zeichen                           
     For i = 0 To  100000
        Print chr(int(rnd*255));
     Next

Ende=Timer-Start

Print:Print:Print:Print:Print:Print "Benoetigte Zeit:";Ende

Sleep
End


Verbesserungsvorschläge willkommen.


Zuletzt bearbeitet von Marc Bonus am 17.09.2017, 14:56, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4204
Wohnort: ~/

BeitragVerfasst am: 17.09.2017, 11:17    Titel: Antworten mit Zitat

http://benchmarksgame.alioth.debian.org/
mit einem schönen Zitat:
Zitat:
Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!

Auf der Seite fällt auch (wenig überraschend) auf, dass verschiedene Sprachen in unterschiedlichen Bereichen ihre Stärken haben. Manche Programme, die in der einen Umsetzung nur wenige Sekunden brauchen, benötigen in einer anderen (ebenfalls insgesamt sehr schnellen) Sprache mehrere Minuten.

Eine Zeitmessung über deinen gesamten Programmcode halte ich daher nicht für sehr sinnvoll; wenn dann würde ich jede Anweisung(sschleife) für sich selbst messen. Außerdem habe ich bei den Forenbeiträgen die Erfahrung gemacht, dass die einen Benutzer berichten, Befehl X wäre bei ihnen deutlich schneller als Befehl Y, bei anderen war es genau anders herum. Auf jeden Fall dürfte auf dem Referenzrechner keinesfalls ein Multitasking-System laufen. happy
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 17.09.2017, 14:31    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
http://benchmarksgame.alioth.debian.org/


LOL, die Programme in dem Link sind schon rund zehnmal länger und komplizierter als meins...

Aber ernsthaft, ich denke mir mein Programm macht es bereits und es ist in kurzer Zeit in anderere Sprachen zu übersetzen, Es soll ja keine abendfüllende Angelegenheit werden. lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4204
Wohnort: ~/

BeitragVerfasst am: 17.09.2017, 17:08    Titel: Antworten mit Zitat

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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 17.09.2017, 17:50    Titel: Antworten mit Zitat

Fürs Erste könnte man C, PureBasic und XProfan nehmen, das wären die Sprachen die ich installiert habe.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 17.09.2017, 18:20    Titel: Antworten mit Zitat

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. zwinkern
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 17.09.2017, 18:35    Titel: Antworten mit Zitat

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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4204
Wohnort: ~/

BeitragVerfasst am: 17.09.2017, 19:44    Titel: Antworten mit Zitat

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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 17.09.2017, 20:06    Titel: Antworten mit Zitat

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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 18.09.2017, 00:47    Titel: Antworten mit Zitat

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.

Zitat:
Warum du aber Kreise und Rechtecke getrennt messen willst verstehe ich nicht.

Ein Kreis ist z.B. ungleich komplizierter zur Zeichnen für einen Computer als ein Rechteck. Ist der Kreis in Grafikbibliothek A effizienter implementiert als in Grafikbibliothek B, verschwimmt dieser vielleicht deutliche Unterschied dadurch, dass du die Messergbnisse mit denen der Linienfunktion vermischst.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 18.09.2017, 01:07    Titel: Antworten mit Zitat

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. grinsen

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. lächeln

Nun müsste man wissen wo FreeBasic da liegt...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 836
Wohnort: Ruhrpott

BeitragVerfasst am: 18.09.2017, 09:40    Titel: Antworten mit Zitat

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.

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

FB kann man guten Gewissens in der Nähe von C ansiedeln.

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4204
Wohnort: ~/

BeitragVerfasst am: 18.09.2017, 09:52    Titel: Antworten mit Zitat

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 ...)

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

Natürlich ist er möglich; ob er so pauschal aber sinnvoll ist, ist eine andere Frage. grinsen

Zitat:
Habe tatsächlich mit dem Testprogramm leicht abweichende Ergebnisse.

Unterschiede können auch durch Hintergrundprogramme entstehen - in einem Multitasking-System sind Geschwindigkeitsmessungen systembedingt immer ungenau. 10% Abweichung sind da nicht besonders viel.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 18.09.2017, 11:43    Titel: Antworten mit Zitat

grindstone hat Folgendes geschrieben:

FB kann man guten Gewissens in der Nähe von C ansiedeln.


Das ist eigentlich auch mein Eindruck. Vieles läuft schon recht zackig bei FreeBasic. Doch schöner wäre es, wenn man es schwarz auf weiss hat. lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 18.09.2017, 11:55    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
aber ob sich umgekehrt C als eingebettete Skriptsprache eignet ...)


Das ist es eben, C ist kryptisch und schwer zu lesen. Sonst würden ja alle in C programmieren.

Da ist Freebasic wesentlich einfacher und bequemer zu benutzen, wenn es auch minimal langsamer sein mag. Bei Menüs und Texten merkt man das kaum. Höchstens wenn sehr viel zu rechnen ist oder viele Grafikoperationen könnte es sinnvoll sein Teile mit C oder ASM einzubinden. lächeln

Der Nutzen von einem Geschwindigkeitsvergleich ist, dass man Newbies zeigen könnte "Sieh her, so schnell und gut ist FreeBasic wirklich!".
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 18.09.2017, 15:46    Titel: Antworten mit Zitat

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. zwinkern
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.

Zitat:
Und Pascal wurde zu Lehrzwecken entwickelt, um Anfängern das strukturierte Programmieren beizubringen. Die Arbeitsgeschwindigkeit war dabei (ebenso wie die Praxistauglichkeit) zweitrangig.

Das ist ebenfalls veraltet und moderne Pascal-Compiler können auch sehr schnell sein. Wofür eine Sprache mal gedacht wurde und wofür sie heute eingesetzt wird sind häufig zwei paar verschiedene Schuhe - vergleiche mal einen JavaScript-Interpreter von vor 10 Jahren mit einem aktuellen JavaScript-Interpreter und wundere dich, wie viel schneller der aktuelle ist, einfach weil JavaScript heute für ganz andere Dinge eingesetzt wird und die Browserhersteller deswegen auch ihre JavaScript-Engines optimieren mussten.

Zitat:
aber ob sich umgekehrt C als eingebettete Skriptsprache eignet ...

PicoC existiert grinsen
...und ist als Interpreter natürlich wesentlich langsamer als ein optimierender C-Compiler, womit wir wieder beim Thema "eine Sprache hat keine fest definierte Geschwindigkeit" wären.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4204
Wohnort: ~/

BeitragVerfasst am: 18.09.2017, 17:41    Titel: Antworten mit Zitat

Jojo hat Folgendes geschrieben:
Man kann übrigens auch nicht einfach sagen dass interpretierte Sprachen immer langsamer sind als kompilierte

Ja, das war natürlich etwas vorschnell verallgemeinert. grinsen Ich würde zwar Java nicht zu den Scriptsprachen zählen, aber auch bei Perl weiß ich, dass da vorcompiliert wird.

Wie Jojo zwischen den Zeilen auch schon andeutet, ist Geschwindigkeit sowieso keine Frage der Sprache, sondern des Compilers (oder sonstigen Ausführungsorgans). Für C bspw. gibt es nicht "den" Compiler, sondern ziemlich viele, und nicht alle sind richtig optimiert. D. h. je nach verwendeten Compiler kann das resultierende Programm auch mal schneller oder langsamer sein. (Wie verbreitet schlechte C-Compiler allerdings sind bzw. ob sie in der Praxis eine Rolle spielen, kann ich nicht sagen.)

Jojo hat Folgendes geschrieben:
PicoC existiert grinsen

Sieh an. grinsen Ich hoffe ja immer noch darauf, dass jemand FBScript implementiert. happy
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Computer-Forum Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite 1, 2  Weiter
Seite 1 von 2

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz