Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Hier könnt Ihr gute, von Euch geschriebene Codes posten. Sie müssen auf jeden Fall funktionieren und sollten möglichst effizient, elegant und beispielhaft oder einfach nur cool sein.
DarkDragon
Beiträge: 6267
Registriert: 29.08.2004 08:37
Computerausstattung: Hoffentlich bald keine mehr
Kontaktdaten:

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von DarkDragon »

Blitzer hat geschrieben: 23.09.2022 12:56 Übrigens: Sie programmieren seit 30 Jahren... Ich programmiere genau 41 Jahre (ZX81, Amiga, Spiele zum Abtippen in Zeitschriften veröffentlicht) und glauben Sie es mir, das sind die wichtigen 11 Jahre.
Aber für ein kommerzielles Produkt muss diese Frage allemal erlaubt sein.
Dann dürften Sie wissen, dass Basic im allgemeinen nicht mehr von Relevanz ist, das nutzt keine größere Firma und wenn, dann wird es von der nächsten Generation nicht mehr weiter gewartet. Kommerzielle Produkte dieser Preisklasse sind auch nicht mehr als Hobbyprojekte. Wer einmal 200€ hinlegt kann heutzutage doch nicht viel erwarten. Es wird ja auch immer mehr zum Trend lokal einzukaufen obwohl es teurer ist, nur um heimische Geschäfte zu unterstützen. Nicht jedes Projekt eignet sich für kostenlose Geschäftsmodelle, z.B. im Randgebiet "Basic" wo es kaum noch freiwillige Unterstützer gibt.
Blitzer hat geschrieben: 23.09.2022 15:49 Also, fakt ist und bleibt es, das die Seite im Internet https://openbenchmarking.org/ genau das macht, was ich Euch aufgezeigt habe, nämlich Formeln in Code zu packen um Geschwindigkeitsunterschiede zu erhalten.
Fast alle Hersteller von Hardware auf dieser Welt nutzen diese Seite ausgiebig.
Richtig, Hardware benchmarking lässt sich so aber nur bedingt auf Software übertragen. Da geht es viel mehr um konstantzeitfaktoren heutzutage als bei Software, wo es eher nur noch um asymptotische Laufzeiten geht. Sonst würde niemand Python verwenden oder Java. Nach der Logik würden wir alle in C und Rust programmieren.

Platform Server: Cloud oder QISKIT
Platform PC/Handy: ab damit auf die GPU.
Platform Embedded: VHDL/Verilog auf FPGAs testen und dann zu einer Chipmanufaktur senden und für wenig Geld ASICs bekommen.

Das sind gute Lösungen. Selbst wenn man mit C arbeitet muss man zur Nutzung von SIMD aktiv den Code verändern:
https://stackoverflow.blog/2020/07/08/i ... use-cases/

Bei C kann man immerhin von einer standardisierten Sprache sprechen, hier ist ja schon die Syntax der Dialekte anders. Wer weiß welche Sprache Schleifen wie weit ausrollt? Passt das Code-Segment dann noch in alle Caches aller Computer? Wir wissen nicht mal deine Spezifikationen. Im Prinzip hast du nur einen Anwendungsfall gezeigt wie er für dich optimal übersetzt wurde, aber auf die einzelnen Sprachen bist du gar nicht näher eingegangen. Selbst bei C sollte man beim for loop increment eher ++i statt i++ schreiben, d.h. man muss sich auf die Sprache einstellen. Was nötig wäre, wäre das ganze entweder auf Assembler level zu analysieren oder zumindest mehr Anwendungsfälle dazu zu packen, aber das verhält sich wie formale Verifikation zu Testen.
Zuletzt geändert von DarkDragon am 24.10.2023 09:07, insgesamt 2-mal geändert.
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
SMaag
Beiträge: 150
Registriert: 08.05.2022 12:58

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von SMaag »

abgesehen davon, dass wohl alle irgendwie recht haben!

Der PureBasic Compiler verwendet keine Optimierungen, um Variablen in den Registern zu halten.
Die Laufvariable I und die Berechnungsvariable X wird immer vom Stack geholt und wieder auf den Stack zurückgepackt.

Hält man die beiden Variablen I, X direkt in Registern, holt man da noch einiges raus!
Mit dem C-Backend und aktivierten Optimierungen könnte das evtl. erreicht werden!

Sobald ein Compiler das Halten von Variablen in Registern verwendet wird es schneller!

In PB kann aber direkt im Basic Code Assembler eingefügt werden und das kollidiert mit Variablen in Registern halten!
Wenn man also in PB den letzten Speed braucht, dann hat man die Möglichkeit dies per Hand in Assembler schneller zu machen.
Was übrigens auch viele so machen, wenn es wirklich zeitkritisch ist.

Interessant wäre noch zu sehen, was als decompilierter ASM-Code im Vergleich dabei rauskommt!
Blitzer
Beiträge: 79
Registriert: 26.09.2004 14:33
Wohnort: Lower Saxony

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von Blitzer »

Ich denke, ich habe mein Ansinnen hier nicht gut genug beschrieben.

Was ich bzgl. der Programmiersprachen gemeint hatte, war der direkte Vergleich von versch. Basic-Dialekten. Hier ergeben sich unterschiedliche Laufzeiten bei ähnlich gelagerter Syntax.

A) Der Vorteil ist der direkte Vergleich (Software) auf ein und denselben Computer. - Softwarevergleich
B) Herkömmliche Vergleiche bzgl. Benchmark benutzen immer dieselben Softwarevarianten auf ähnlichen Computern. - Hardwarevergleich

Daher möchte ich zur Verdeutlichung die Tests erweitern und zwar auf das Handy, wie unter A) beschrieben.

Dazu habe ich 4 Mobile-Apps geschrieben, die diesen Primetest durchlaufen.
1) Diese Apps können auf otp-crypt.com direkt mit dem Handy geladen und nach Freigabe installiert werden.
2) Mit dem PC können Sie nach dem Download aus dem Download-Ordner und einem USB-Kabel genau diese Apps auf den Download-Ordner ins Handy übertragen und anschließend nach Freigabe installieren.

Die Programmiersprachen und die Ergebnisse im Einzelnen:

Spiderbasic:
Laufzeit: 12638 ms
Paketgröße: 2441 KB
download

AppGameKit:
Laufzeit: 48505 ms (Tier 1)
Paketgröße: 12232 KB
download

B4A:
Laufzeit: 2070 ms
Paketgröße: 125 KB
download

Processing:
Laufzeit: 1837 ms
Paketgröße: 2003 KB
download

Die absoluten Laufzeiten sind nicht von Bedeutung, da ich ein älteres Gerät für die Softwareentwicklung benutze. Die relativen Laufzeiten hingegen zeigen sehr große Unterschiede auf.

Der Schwerpunkt für den Spielebereich ist bei 'AppGameKit' zu sehen. Für den kommerziellen Bereich ist ganz klar 'B4A' zu nennen. Bei 'SpiderBasic' bin ich mir nicht so sicher (Camera, QR-Code, ?, etc.). Bei 'Processing' ist es eher die schnelle Programmierung im Alltag (Einstieg für Schüler und Studenten).
Processing bietet ferner die Möglichkeit unter Python und R zu programmieren. Hunderte 'Snippets' werden mitgeliefert. Mehrere Dutzende Bücher sind im Umlauf.
Noch ein Wort zur App-Entwicklung. Die Android Emulatoren NOX und LDPlayer sind wertvolle Helfer, in Sekunden werden die Apps ausgeführt. Die Laufzeit-Einbußen im Emulator betragen in der Regel ca. 50% der PC-Laufzeit. Die Entwicklung der 4 Apps hat keine 5 Min. pro App betragen.

Selbstverständlich sind in diesem Forum auch App-Programmierer die gerne sinnvolles ergänzen können.
(Ich wünsche jeden der mich kennt, 10 x soviel wie er mir gönnt)
Benutzeravatar
Kiffi
Beiträge: 10621
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von Kiffi »

Ändere mal für PureBasic / SpiderBasic die Schleife auf

Code: Alles auswählen

Define a.s = ""
[...]
For i = 0 To 999999
  a + "a"
Next
und für B4J / B4A auf:

Code: Alles auswählen

Dim a As String
[...]
For i = 0 To 999999
  a = a & "a"
Next
SpiderBasic belegt auf meinem Rechner Platz 1 mit 0.05 Sekunden

Danach kommt B4J (B4A) mit knapp 54 Sekunden.

Und PureBasic... 1349 Sekunden... auweia!

Aber wie bereits trefflich formuliert:
ccode_new hat geschrieben:solche Vergleiche sind ziemlich irrelevant und haben keinen besonders hohen Aussagewert.
Rings hat geschrieben:Eine Kernaufgabe beim Programmieren ist das nicht.
Hygge
Blitzer
Beiträge: 79
Registriert: 26.09.2004 14:33
Wohnort: Lower Saxony

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von Blitzer »

Hier handelt es wahrscheinlich um Software-Anomalien, die dem Parser/Compiler zuzuschreiben sein könnten.(Konjunktiv)

Ich habe für Spiderbasic die Zuweisung mit einem Gleichheitszeichen versehen, also: a = a + "a", und mir verschiedene Ergebnisse anzeigen lassen. Plötzlich zeigte Spider wieder das gewohnte Verhalten im ms-Bereich.

Danach wieder ohne dem a =. Keine Anomalien mehr festzustellen, auch nicht nach einem Neustart.

So zeigte es sich jedenfalls bei mir ...
(Ich wünsche jeden der mich kennt, 10 x soviel wie er mir gönnt)
Benutzeravatar
mk-soft
Beiträge: 3695
Registriert: 24.11.2004 13:12
Wohnort: Germany

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von mk-soft »

Das mit String und Zeichen für Zeichen hinzufügen ist in PB bekannter weise nicht besonders schnell, da jedes mal das NULL Zeichen gesucht wird und stückweise der Speicher vergrößert und umkopiert wird.
Da ist WEB-Java (Spiderbasic) in diesen Bereich ausnahmsweise schneller. WEB-VBS ist da auch nicht besonders schnell.

Das ist mir auch aufgefallen als ich mit den ActiveScriptControl unter PB ein Java-Script aufgerufen habe.


Das alles ist aber für mich nicht relevant ob eine Programmiersprache schneller oder langsamer ist.
Für mich ist relevant wie schnell ich eine kleine oder mittler Anwendung schreiben kann und welchen Aufwand ich betreiben muss um alle erforderlichen Funktionen zusammengestellt bekomme.

Da ist für mich Purebasic unschlagbar!
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Benubi
Beiträge: 186
Registriert: 22.10.2004 17:51
Wohnort: Berlin, Wedding

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von Benubi »

Ich bin schon neugierig wie die Leistung von PB im Vergleich zu anderen Sprachen ist, insbesondere alternative Basic Dialekten. Ich programmiere auch seit 30 Jahren, aber nur hobbymäßig und nur kurz "beruflich" während meiner Ausbildung vor 20 Jahren. Auf meinem Win10 64bit allein kann ich 4 Verschiedene Kompiler je PB Version auswählen (C/Asm x86/x64). Und es gibt noch die Kompiler-Optionen "dynamisch/alle CPU" etc. Dann habe ich eine überfüllte VM für Linux 64, und einen Raspberry mit zwei OS 32bit/64bit Debian (aber nur C Backend auf letzter Architektur). Die Leistungsergebnisse je Auswahl können stark variieren, selbst bei kleinen Programmen wie dem da oben.

Man kann die Optimierung beim Kompiler einschalten. Ich glaube bei 32bit ASM ändert sich aber nichts. Ich habe mich auch ein wenig über Leistungsunteschiede gewundert, insbesondere die atan2() Funktion die in C "viel" schneller läuft (in einer Lua Implementation ca. 30% schneller) als die in PB fest verbaute; daher habe ich versucht die atan2 nachzuschreiben/neuzuschreiben und nur mäßigen "Erfolg" hierbei gehabt.

Bei Hardware Wechsel zwischen 10 J alter und neuer Rechner gab es interessante Entwicklungen. "Optimierungen" die auf dem alten schneller liefen waren auf dem neuen kaum schneller und manchmal sogar "bedeutend" langsamer (ähnliche Abweichungen wie in den Primzahl-tests vom Verhältnis her).

Ich bevorzuge jetzt meistens die C-Backends und orientiere mich mehr daran wegen Portierung. Ich habe manuelle Optimierungen vorgenommen und fast identische Speedtests erhalten wie wenn der C optimizer an ist. Im Prinzip spare ich nur Zeiger Zugriffe, indem ich den Wert in eine lokale Variable schreibe.

Code: Alles auswählen

While ...
  *MainObj\MyCallBack(*Item,x,y)
Wend

; wird zu:

Protected MyCallBack.MyCallBack = *MainObj\MyCallBack
While ...
 MyCallBack(*item,x,y)
Wend

Ich bin ja auch ein wenig ein "Purist" wie der Blitzer (?) - ultra schnelle und kleine Executables werden ja bei der Werbung angegeben. Manche Leute interessieren sich eben für solche Experimente wie oben oder behalten diesen Anspruch. Hier geht's vielleicht nicht um Pragmatismus oder Usability, sondern um Treue! :wink:

In irgend einer PB Version, ich denke wenn die Runtime Lib dazu kam oder ein wenig früher, blähten dann die Executables etwas auf wenn man eine Windows/GUI Anwendung kompilert. Da werden sehr viele Strings exportiert/in die Exe kompiliert die vorher nicht notwendig waren. Man kann damit nur schwer an einem 32k bzw. 64k App-Contest teilnehmen (mini games oder sowas schreiben) bzw. fällt dann das ansehbare Ergebnis vermutlich viel bescheidener aus.

Ohne VB als Test-Teilnehmer fehlt mir mein Lieblingsbuhmann. Ich bin mir sicher VB kann alles langsamer machen, insbesondere String Operationen. Aber sag niemals nie. Ich kann mir vorstellen dass einige Basic Dialekte oder andere Sprachen intern einen Längen-Präfix oder sowas einsetzen um ihre String-Operationen zu beschleunigen.


Ich glaube PB schneidet bei diesem Test etwas langsamer ab, weil die Modulo Funktion nicht inline implementiert ist, und bei den anderen Dialekten möglicherweise schon. (Edit: FALSCH! Keine Modulo... ich sollte den geposteten Code besser studieren)
funkheld
Beiträge: 636
Registriert: 31.12.2009 11:58

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von funkheld »

Ich habe jetzt mit 74 Jahren auch wieder dieses Blitzmax installiert.

Ist Freeware.
Hat viele neue Module drin.
Ist ein wunderbares Komplettpaket. Man braucht sich um das "C" nicht mehr kümmern mit den Einstellungen, wird alles funktionsfähig installiert.

Mir macht es spass damit zu proggen.
Hat insgesamt eine enorme Geschwindigkeit in der Grafik 2d/3d und den Berechnungen.
Progge auch gerne kleine C-Module dafür , hält mein Geist wach.

Gruss
Blitzer
Beiträge: 79
Registriert: 26.09.2004 14:33
Wohnort: Lower Saxony

Re: Vergleich: Win11 /Linux mit Purebasic, Freebasic, Blitzmax

Beitrag von Blitzer »

Der Vergleich der Geschwindigkeit mit verschiedenen Software-Varianten (mit gleicher Testroutine) auf nur einem einzigen Rechner ist in der Aussage als sehr wertvoll anzusehen. Dieser Vergleich ist sehr schwer herzustellen. In dieser Form ist er mir im Internet noch nicht begegnet.

Der Vergleich richtet sich nur an Spezialisten in der Programmierung, die in der Lage sind als Muttersprache "Basic" zu verwenden und den Quelltext in "C" übersetzen zu lassen. Verschiedene auf dem Markt befindliche C-Compiler können so unabhängig voneinander getestet werden. Die Kernaufgabe eines Compilers liegt in der Übersetzung eines vorliegenden Quellcodes in ein für den Benutzer lauffähiges Programm, und das möglichst mit hoher ausführbarer Geschwindigkeit.

Hier dient als Quellcode-Basis die Programmiersprache "Basic", egal welcher Dialekt verwendet wird. Damit wird klar, dass "Basic" als Muttersprache jetzt und auch zukünftig an Bedeutung zunehmen wird.

Wenn hier im Forum Aussagen getroffen werden um den Test grundsätzlich zu negieren, so ist die Rede von -irrelevant, -kein Aussagewert, -Schwanzvergleich, -Leistungsvergleich schwierig, -Primzahlen nicht notwendig (gibt es zu kaufen), -usw. ...

An dieser Stelle möchte eine der ältesten Basic-Sprachen nennen. Es ist das altbekannte BCX (https://bcxbasiccoders.com/smf/index.php).

Mit BCX besteht die Möglichkeit direkt unter verschiedenen Compilern ausführbare Programme zu erzeugen. Geeignet sind grundsätzlich alle C-Compiler. Es werden per Menü 4 Compiler zur Übersetzung angeboten: PellesC, Lcc-Win32, MinGW G++ und MS Visual C++. Auch ein Radiobutton für das binäre Ziel ist vorhanden (GUI, Console oder DLL).
Ich persönlich benutze PellesC im 32-bit und 64-bit Modus. MinGW G++ wird nur im 64-bit Modus mit Optimierungsstufe -O3 benutzt.

Hier die ungefähren Zeiten [ms] im direkten Vergleich:
PellesC und Purebasic = 475
Freebasic = 400
Blitzmax = 320
MinGW G++ = 280 (optimiert)

Unterschied MinGW zu PureBasic; 280 zu 474 = +71% (PB langsamer)

Erwähnen möchte ich auch noch den Compiler TinyCC. Wenn im "BCX BASIC to C/C++ Translator" das Flag 'ZAP' gesetzt und anschließend mit TinyCC übersetzt wird, so entsteht ein "Hallo-Welt" Programm im Konsolen-Modus von nur 2 KB Größe.

Eine Programmierung erfolgt heutzutage noch über die Tastatur. Daher ist hier auch der Vergleich zur erzeugten Größe zwischen Quelltext.bas und Quelltext.c erlaubt. Ein komplettes GUI-Sample über die Leistungsfähig der Software in Quelltext.bas ist unter 700 Byte groß. Das entsprechende Quelltext.c belegt schon 18.315 Byte. Das bedeutet Faktor 26.

Die Programmiersprache "Basic" wurde früher mit einem Interpreter zur Laufzeit versehen und war daher in der Ausführung sehr langsam. Die Programmiersprache "C" war um einiges schneller und hat damit langsamere Sprachen verdrängt. Nun sieht alles nach umgekehrten Vorzeichen aus.
- Happy Coding -
(Ich wünsche jeden der mich kennt, 10 x soviel wie er mir gönnt)
Antworten