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 Zurück  1, 2
 
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
Jojo
alter Rang


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

BeitragVerfasst am: 18.09.2017, 18:37    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
Man kann übrigens auch nicht einfach Ich würde zwar Java nicht zu den Scriptsprachen zählen, aber auch bei Perl weiß ich, dass da vorcompiliert wird.

Deswegen habe ich auch "interpretiert" gesagt - ursprünglich lief Java 100% im Java-Interpreter, aber wie gesagt gibt es auch die Möglichkeit, dass Teile des ausgeführten Codes optimiert und kompiliert werden, und es gibt auch Cross-Compiler, die Java-Code vollständig in nativen Code übersetzen.

Die drei meistverbreiteten C(++)-Compiler (GCC/Clang/MSVC) optimieren alle übrigens sehr aggressiv, aber natürlich gibt es einfach abertausende Möglichkeiten, Code zu optimieren, so dass kein Compiler jemals das optimalste Programm in jeder Situation erzeugen könnte. Es gibt sogar einen formalen Beweis dafür, dass es solch einen optimalen Compiler nicht geben kann - sonst könnte man auch das Halteproblem lösen...
Letztenendes kann auch ein schlauer Compiler keinen doof formulierten Code schnell machen. grinsen
_________________
» 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
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2445
Wohnort: Hofen SH (Schweiz)

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

Der Titel müsste evtl. anders lauten: "Die schnellste Programmier-Hochsprache", denn sonst wäre typischerweise Assembler die Antwort.

Natürlich hängt die Geschwindigkeit bei Assembler vom Programmierer ab, wie weit er seinen selbstgeschriebenen Maschinencode optimiert. => An dieser Stelle auch beachten, dass die Compiler in den letzten Jahren recht viel Fortschritt gemacht haben hinsichtlich Code-Optimierung. => So hängt die Ausführgeschwindigkeit nicht zuletzt vom verwendeten Compiler ab. Und ebenfalls zu beachten: Optimierungsoptionen beim Compilieren.

So war es früher häufig üblich, eine schnelle .EXE-Version zu bauen auf Kosten von Range-Checks, d.h. bei einem Programmierfehler wie Array-Überlauf wurde dann einfach benachbarter Speicher überschrieben. => Für einen aussagekräftigen Vergleich der Programmiersprachen müssen also Randbedingungen wie Laufzeitfehler-Erkennung (Range-Checks usw.) klar definiert und überall vorgegeben werden.

Auch die Hardware-Bedingungen sind auch nicht mehr so einfach wie seinerzeit beim Commodore 64, wo man als Assemblerprogrammierer die benötigte Laufzeit noch auf einzelne CPU-Taktzyklen genau bereits auf dem Papier bestimmen konnte. => So haben die Anzahl Kerne und CPU-Cache auch einen nicht unerheblichen Einfluss bei Messungen. => Für so eine Messung müsste man die Hardware auch genau definieren bzw. ich würde sogar empfehlen, 5-6 unterschiedliche Hardware-Generationen zu definieren, das Testprogramm überall laufen zu lassen und die Performance beispielsweise als Durchschnitt jeder einzelnen Laufweit berechnen, dabei evtl. sogar statt dem arithmetischen Mittel das geometrische Mittel nehmen.
_________________
Teste die PC-Sicherheit mit www.sec-check.net
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 19.09.2017, 00:28    Titel: Antworten mit Zitat

Die zwei ersten Plätze stehen bereits fest, da sind wir uns bestimmt alle einig:

1. Handoptimierter Assembler

2. C

Interessant wird es für mich danach, vor allem auf welche Plätze FreeBasic, PureBasic etc kommen. Und ich gestehe gern, dass ich mich mit einer Sprache auf den hinteren Rängen eher nicht weiter befassen würde. Denn wenn ich eines nicht mag beim Programmieren dann ist das wenn man beim Aufbau jedes einzelnen Quadrates zuschauen und Kaffee kochen gehen kann. grinsen
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 19.09.2017, 01:09    Titel: Antworten mit Zitat

dreael hat Folgendes geschrieben:
Auch die Hardware-Bedingungen sind auch nicht mehr so einfach wie seinerzeit beim Commodore 64


Habe noch mal experimentiert mit dem Speedtest-Programm. Auch wenn man den Zufall raus nimmt sind die Ergebnisse nicht immer gleich. Eine Null an die Schleifen zu hängen, also auf 1 Mio zu erhöhen scheint auch nicht viel zu bringen.

Bei dem "Benchmark-Game" haben sie einfach normale Programme gemessen. Mein Ansatz wäre ein spezielles Testprogramm wie oben zu erstellen, das immer den gleichen Wert liefert. Ich weiss aber nicht, ob das überhaupt möglich ist.

Habe jetzt drei Rechner auf dem Schreibtisch. Einer ist ein 1GHz Single Core mit XP. Vielleicht wären auf dem die Ergebnisse gleich. Der ist übrigens auch im direkten Vergleich mit dem 3 GHz noch heute recht flott. Wenn man es nicht wüsste würde man ihn wohl für den etwas Schnelleren halten. Vielleicht auch wegen der Geforce-Graka. Der 3 GHz hat Onboard-Grafik.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


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

BeitragVerfasst am: 19.09.2017, 01:34    Titel: Antworten mit Zitat

Selbst die ersten beiden Plätze sind alles andere als eindeutig.
Zitat:
1. Handoptimierter Assembler

Moderne CPUs und ihre Befehlssätze sind so kompliziert, dass ein Mensch kaum einen Überblick über alle Optimierungsmöglichkeiten haben kann. Natürlich gibt es immer noch viele Fälle, in denen man den Compiler schlagen kann, aber häufig ist der vom Compiler erzeugte Code so gut wie handgeschriebener Code oder sogar besser. Man kann natürlich versuchen diesen Code noch weiter von Hand zu verbessern, aber meist sprengst das jegliches Maß an Zeit.

Zitat:
2. C

Auch das kann man nicht einfach so stehen lassen, wie schon weiter oben erwähnt können Just-In-Time-Compiler ein vorab kompiliertes C-Programm schlagen, da dem Just-In-Time-Compiler z.B. die konkreten Programmeingaben vorliegen. Nimmt man als sehr simples beispiel mal die Implementierung des CIRCLE-Befehls von FreeBASIC, so enthält diese Programmabschnitte, die z.B. für das Zeichnen von Ellipsen relevant sind und somit deren Präsenz/Ausfürhung für reine Kreise einen Overhead darstellen kann. Hätte man dieselbe Prozedur in C# geschrieben und ein Just-In-Time-Compiler würde feststellen, dass niemals verformte Ellipsen gezeichnet werden, könnte er diesen Code einfach rauswerfen und somit den restlichen Code beschleunigen.

Es kommt, wie nun schon mehrmals erwähnt, immer auf den Kontext an. "Die schnellste Sprache" oder "den schnellsten Compiler" gibt es im Allgemeinfall einfach nicht.

Zitat:
Einer ist ein 1GB Single Core mit XP. Vielleicht wären auf dem die Ergebnisse gleich.

Windows ist kein Echtzeitbetriebssystem, der Scheduler kann dort auch (oder sogar insbesondere) auf einem Single-Core-System die Messergebnisse verfälschen. Lässt man das Programm sehr lange laufen (also mehr als nur ein paar Sekunden), fällt das aber quasi nicht mehr ins Gewicht.
_________________
» 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
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 767
Wohnort: Ruhrpott

BeitragVerfasst am: 19.09.2017, 10:20    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
Ich hoffe ja immer noch darauf, dass jemand FBScript implementiert.

Da wären wir dann wieder bei QBasic. grinsen

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: 4143
Wohnort: ~/

BeitragVerfasst am: 19.09.2017, 14:51    Titel: Antworten mit Zitat

Naja, hoffentlich mit einer IDE, die über eine TUI hinausgeht. grinsen
Nein ernsthaft, ich meine eine eingebettete Skriptsprache für FB - das ist natürlich nicht ganz wirtschaftlich, wenn es doch schon eine gute Lua-Anbindung gibt, aber ich fände das schon reizvoll. Die kann ja durchaus im Sprachumfang abgepeckt sein.
_________________
Meine Großeltern waren als junge Menschen sehr modern - sie hatten schon damals in der Badewanne Email.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 19.09.2017, 18:17    Titel: Antworten mit Zitat

Jojo hat Folgendes geschrieben:
Lässt man das Programm sehr lange laufen (also mehr als nur ein paar Sekunden), fällt das aber quasi nicht mehr ins Gewicht.


Und dann würde sich auch ein Geschwindigkeitsunterschied zwischen Sprachen wie FreeBasic, PureBasic und XProfan auf dem gleichen Rechner zeigen, denn sie haben je nur einen Compiler. Das ist das worauf ich hinauswill. cool
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 19.09.2017, 18:41    Titel: Antworten mit Zitat

Doch bevor ich anfange das Testprogramm in verschiedene Sprachen zu übersetzen hätte ich gerne gewusst, ob es eurer Meinung nach überhaupt geeignet ist die Geschwindigkeit zu messen, wenn man es so verlängert, dass es sagen wir mal etwa eine Stunde läuft. Oder wie müsste man es verändern?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 19.09.2017, 18:57    Titel: Antworten mit Zitat

Ich denke auch nicht, dass wenn ein Programm auf Kubuntu 17 deutlich schneller ist, es auf einem anderen OS plötzlich umgekehrt ist.

Sprachen wie C und Pascal haben viele Dialekte, doch sind das streng genommen verschiedene Sprachen mit je einem Compiler und könnten auch gesondert behandelt werden. cool
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



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

BeitragVerfasst am: 20.09.2017, 15:43    Titel: Antworten mit Zitat

Zitat:
Und dann würde sich auch ein Geschwindigkeitsunterschied zwischen Sprachen wie FreeBasic, PureBasic und XProfan auf dem gleichen Rechner zeigen, denn sie haben je nur einen Compiler

Zu FreeBASIC: Ja und Nein. Der fbc übersetzt den Programmcode (standardmäßig) nach ASM und lässt dann den gcc den Maschinencode erstellen. Allerdings kannst du ohne großen Aufwand statt gcc einen anderen Compiler verwenden. Oder du lässt den fbc für LLVM compilieren und arbeitest dann damit weiter. Ggf. kommt da dann bein Linken eine bessere Optimierung heraus (min Wissen über LLVM beruht nur auf einem sehr kurzen Überfliegen des Wikipedia-Artikels). Von daher kann es bei ein und demselben FB-Programm durchaus zu unterschieden kommen.

Wie es bei PureBASIC und XProfan genau aussieht, kann ich nicht sagen. Prinzipiell kann aber "jeder" zur gegebenen Sprache einen eigenen Compiler schreiben.

Zu C gibt es zwar verschiedene Varianten, die durchaus Dialekte darstellen. Es gibt aber auch mehrere Compiler für ein und dasselbe Standard-C. Bei diesen kann man keinesfalls von Dialekten sprechen.
_________________
Meine Großeltern waren als junge Menschen sehr modern - sie hatten schon damals in der Badewanne Email.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 20.09.2017, 17:05    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
Prinzipiell kann aber "jeder" zur gegebenen Sprache einen eigenen Compiler schreiben.


Prinzipiell kann auch "jeder" eine Rakete bauen und auf dem Mond landen, Doch komischerweise macht es in der Praxis ausser John F Kennedy kaum jemand. grinsen

In der Praxis kompiliert man FreeBasic-Programme mit dem fbc usw. lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



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

BeitragVerfasst am: 20.09.2017, 19:25    Titel: Antworten mit Zitat

Naja, der fbc macht ja nur den ersten Schritt der Compilierung. grinsen Aber Fakt ist, dass man C eben nicht immer mit [HierEinenSpeziellenC-CompilerEinsetzen] compiliert, sondern mit verschiedenen.

Aber vielleicht mal zurück auf deine eigentliche Frage: Da sich FreeBASIC (meiner Meinung nach) besonders durch die einfach bedienbare On-Board-Grafik auszeichnet, macht es durchaus Sinn, einen Test im Grafikbereich anzusetzen. Ich persönlich verwende in meinen Programmen CIRCLE nicht sehr häufig, und wenn doch (z. B. bei Spielsteinen, die nicht über eine extra Bilddatei eingebunden werden sollen), dann zeichne ich eher einmal in einen Grafikpuffer und PUT-te den dorthin, wo ich ihn gerade brauche. Für mich ist PUT einer der wichtigsten Grafikbefehle überhaupt. Allerdings "befürchte" ich, dass sich gerade bei Befehlen wie PUT die Geschwindigkeit der verschiedenen Compiler kaum unterscheiden wird.

In der Regel wirst du ja das testen, was du am häufigsten einsetzen willst. Willst du FB nutzen, um viele Kreise unterschiedlichster Größe zu zeichnen, ist diese Geschwindigkeit wichtig. Brauchst du ein Programm zur schnellen Datenverarbeitung - Datei einlesen und Inhalte auswerten - dann muss der Test daraufhin ausgelegt sein. Kurz gesagt: es gibt keine "wichtigsten" Befehle zum testen - das ist eine Frage des eigenen Bedarfs.

Wenn du Neulinge mit der Geschwindigkeit von FB begeistern willst, kannst du natürlich auch einfach die Befehle testen, bei denen FB besonders gut abschneidet. grinsen


Zitat:
Prinzipiell kann aber "jeder" zur gegebenen Sprache einen eigenen Compiler schreiben.

Was ich damit sagen wollte: Vergleichen kannst du nur die Compiler, nicht die Sprache. (Deine Raketen-Analogie ist übrigens gar nicht so schlecht - nicht jede Rakete ist nämlich gleich schnell. grinsen )
_________________
Meine Großeltern waren als junge Menschen sehr modern - sie hatten schon damals in der Badewanne Email.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marc Bonus



Anmeldungsdatum: 19.11.2016
Beiträge: 43

BeitragVerfasst am: 20.09.2017, 19:50    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
Naja, der fbc macht ja nur den ersten Schritt der Compilierung. grinsen Aber Fakt ist, dass man C eben nicht immer mit [HierEinenSpeziellenC-CompilerEinsetzen] compiliert, sondern mit verschiedenen.


Da habe ich genau die gegenteilige Erfahrung gemacht. Wenn ein Code für MS-C geschrieben ist bekommst du Probleme wenn du ihn mit GCC kompilieren willst.

Zitat:
Ich persönlich verwende in meinen Programmen CIRCLE nicht sehr häufig,


Das stimmt. In dem Testprogramm kommen weit überdurchschnittlich viele Kreise vor. Kaum ein Programm zeichnet so viele Kreise.

Zitat:
In der Regel wirst du ja das testen, was du am häufigsten einsetzen willst.


So ist es.

Zitat:
Wenn du Neulinge mit der Geschwindigkeit von FB begeistern willst, kannst du natürlich auch einfach die Befehle testen, bei denen FB besonders gut abschneidet. grinsen


Das will ich ja nun auch nicht. Es soll schon ein ehrlicher Test sein. happy
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 Zurück  1, 2
Seite 2 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