Heute so compiliert...

Quote from 1570

Arrays sind vorbelegt? IFATHENDIMB(100), IFNOTATHENDIMB(1000,100) unterstützt MOSpeed nicht?

Nein, das würde einen Redim'ed array error oder so ähnlich auslösen. Macht min. der Basic-Boss (Edit: und auch Basic 64) übrigens genauso. Außer A wäre ohnehin konstant, dann würde eine der Bedingungen schon vorher wegfliegen.

Quote

Ja, die Angabe ist schwierig zu interpretieren, aber schon wichtig zur Einschätzung des belegten Diskettenplatzes, Ladezeit, Größe im Speicher, also auch relevant, wenn man noch Zeugs "außenherum" machen will (geänderter Zeichensatz etc.).

Aber aus der Größe der Datei kannst du gar nicht ableiten, ob deine Zeichensätze noch passen oder nicht, weil eben bei den meisten Compilern die variablen Daten erst zur Laufzeit "dazukommen". Du kannst das Zeugs bei MOSpeed auch "mittenrein" machen, indem du um Speicherbereiche herumkompilieren lässt. Aber dann wird die Datei noch größer, weil viel Luft drin ist. Oder du lässt statt einer großen Datei mehrere kleine erzeugen. Wegen dieser "Löcher" habe ich irgendwann dieses

Flag eingeführt. Damit wird das Ergebnis gepackt und der Benchmark läge bei 38 Blocks. Also bei Platz und Ladezeit gehe ich mit (wobei ich auch da sagen würde, dass die Relevanz dieser Werte nicht mehr so hoch ist, wie noch in den 80ern, als alles ohne Speeder auf echten Disketten gelandet ist), aber bzgl. tatsächlicher Speichernutzung sagt das nicht viel aus.

Das ist dann aber nicht BASIC V2!!1!

Blitz! kann das.

Ja, was Dateigröße/Code-Größe/... angeht, wären differenzierte Angaben schön, aber wer kann das schon für alle Compiler herausfinden...

Mir geht es in erster Linie darum, mal genauer rauszufinden, wie das mit M-Code vs. P-Code in Sachen Platzverbrauch genauer ist.

Und allgemein ist sicher spannend zu sehen, bis zu welcher Input-Größe der jeweilige Compiler noch sinnvollen Output generiert. (und klar, da gibt's viele Nuancen, aber zwischen z.B. Basic Boss und Blitz liegen da anscheinend Welten)

Quote from 1570

Blitz! kann das.

Ich habe nichts anderes erwartet...(Edit: siehe unten)

Ich denke aber, wer sowas baut, hat jede erdenkliche Strafe verdient. Ich bin, bevor ich dein Beispiel gesehen habe, noch nicht einmal auf die Idee gekommen, dass man das machen könnte. Das muss man dann ja durchziehen im Code...völlig gaga! Ist mir auch auf all meinen Reisen ins Land des grauenhaften BASIC-Codes noch nie untergekommen. Also ich kann damit leben, das nicht zu unterstützen.

Quote

Ja, was Dateigröße/Code-Größe/... angeht, wären differenzierte Angaben schön, aber wer kann das schon für alle Compiler herausfinden...

Mir geht es in erster Linie darum, mal genauer rauszufinden, wie das mit M-Code vs. P-Code in Sachen Platzverbrauch genauer ist.

Und allgemein ist sicher spannend zu sehen, bis zu welcher Input-Größe der jeweilige Compiler noch sinnvollen Output generiert. (und klar, da gibt's viele Nuancen, aber zwischen z.B. Basic Boss und Blitz liegen da anscheinend Welten)

Ich weiß nicht, was die anderen Compiler an Nicht-Code in die Datei packen (wenn überhaupt was), aber was MOSpeed angeht, kann man mit -generatesrc=true compilieren. Dann fällt auch eine .dbg-Datei mit raus. Wenn man in der nach "CONSTANTS" sucht, kommt man an das Ende des erzeugten Codes mit der entsprechenden Adresse. Beim Benchmark (ohne den Integerteil) sind das dann 30 Blöcke Code, 14 Blöcke davon sind compiliertes Programm (da ist das Ende etwas schwieriger zu finden...eine Suche nach "END" hilft), 16 Blöcke Runtime. Aber die Runtime ist ja dynamisch gelinkt, also immer unterschiedlich groß, je nach Programm bzw. den verwendeten Befehlen.

Quote from 1570

Blitz! kann das.

Sicher?

Ah witzig, das ist ein Bug im Compiler, danke! Die Runtime kann das...

Aber nehmen wir den einfachen Fall IF...DIMA(10)...(else)DIMA(100). Ohne das jetzt getestet zu haben sollte Blitz DAS können.

Und klar ist DIM mal so mal so hirnverbrannt, aber halt Teil der Sprachdefinition.

Quote from 1570

Aber nehmen wir den einfachen Fall IF...DIMA(10)...(else)DIMA(100). Ohne das jetzt getestet zu haben sollte Blitz DAS können.

Ja, das scheint zu klappen.

Edit: Habe für MOSpeed mal eingebaut, das zumindest das (also wenn die Anzahl Dimensionen gleich sind) dort auch geht. Nicht dynamisch, er nimmt einfach die größte Dimension, aber Wayne interessierts.

muffi In #8 ist auffällig, dass die Petspeed-Ergebnisse für Integer und Real so gut wie gleich sind und Petspeed im Real-Bereich meist die anderen Compiler abhängt. Ist da was schiefgelaufen beim Abtippen oder schummelt Petspeed und macht einfach immer Integer oder ähnliches?

Quote from muffi

1570 Das Phänomen habe ich auch bemerkt. Ich weiß ehrlich gesagt nicht, was der Petspeed da anders macht. Interessanterweise erzeugt er aber beim Monopoly ein vollkommen normal lauffähiges Compilat. Es scheint auch keine Überläufe zu geben, Zahlen >65535 scheint er auch zu verarbeiten. Ob da eine eigene Logik dahinter steckt, müsste man mal eruieren. Ausschließen will ich es nicht, denn die Runtime ist mit 33 Blöcken ja durchaus erwähnenswert.

Das "Problem" mit dieser Art von Micro-Benchmarks ist meiner Ansicht nach, dass sie in jeder Disziplin eine großen Overhead für FOR-NEXT und Arrayzugriffe mit sich schleppen. Vor allem wenn die Operation in der Schleife trivial ist, misst man hier zu großen Teilen einfach die Schleifenperformance (+Arrays) immer und immer wieder. Dadurch sieht Petspeed super aus, weil der (aus mir völlig unbekannten Gründen...das sollte mal jemand rausfinden...) zumindest bei den Schleifen immer sehr gut ist. Dafür kompiliert er sich auch gerne mal großen Käse zusammen. Ich habe für ein kurzes Video mal vier Programme mit allen gängigen Compilern im Vergleich compiliert (Raytracer, Boulder Dash-Levelaufbau (hier aus dem Forum), Labyrinth und ein "Speedrun" von Brotquest 2) und Petspeed hat nur den Raytracer korrekt übersetzt. Der BD-Level läuft durch, sieht am Ende aber falsch aus, das Labyrinth bleibt nach kurzer Zeit einfach hängen und Brotquest 2 würfelt seine Texte wild über den Bildschirm.

Quote from muffi

Ich bin gerne bereit, das Benchmarking komplett zu überarbeiten und das tagelang erneut durchzunudeln. Nur müssten wir uns darauf einigen, was wir statt Micro-Benchmarks machen. Mein Ziel war es ja genau gewesen, einzelne Aspekte zu benchmarken und nicht eine gemischte Geschichte (die aber durchaus auch reizvoll sein könnte). Ohne FOR/NEXT wird man aber nicht auskommen können schätze ich.

Ich hatte für meine Zwecke mal das hier gebaut: https://github.com/EgonOlsen71…ain/basic/egonseleven.bas

Aber da drin habe ich die heilige Integerkuh nicht genug gestreichelt, also müsste man das zumindest erweitern. Und eigentlich müsste man auch prüfen, ob das Ergebnis korrekt ist (siehe Petspeed...der erzeugt eben oft Quatsch, der aber u.U. nicht sofort auffällt)....das war mir dann irgendwann zu viel Aufwand. Ich habe jetzt zwei Abende damit verbracht, diese vier oben angesprochenen Programme auf allen (üblichen) Compilern zum Laufen zu bringen und zu vergleichen (und dabei aufzunehmen)...und das Ergebnis ist dann schon wieder obsolet, wenn ich an MOSpeed was signifikantes ändere.

Das ist ein komplexes Thema und außer uns Dreien hier juckt das, glaube ich zumindest, eigentlich da draußen auch niemanden. Ich bin nicht sicher, wieviel Aufwand man da reinstecken will...

Konkret für deine Benchmarks denke ich, die wären etwas aussagekräftiger wenn:

1. ...nicht alles mit Arrays passieren würde. So hat die Implementierung der Arrayzugriffe einen zu großen Einfluss, wenn man eigentlich Stringfunktionen oder ähnliches testen will
2. ...mehr Code zwischen FOR und NEXT wäre. Je mehr in der Schleife gearbeitet wird, desto geringer wird der Einfluss der Schleifenperformance selbst auf das Ergebnis sein

Generell finde ich diese Micro-Benchmarks gut, um Probleme zu erkennen und ggf. daran zu arbeiten. Für einen wirklichen Vergleich finde ich "echte" Programme besser geeignet. Aber selbst da sind die Unterschiede teilweise unerklärlich. Hypra-Comp ist z.B. eigentlich nicht berühmt...schneidet aber beim Raytracer relativ gut ab.

So sieht übrigen DALL-E Mini die Integerkuh, die ich oben erwähnte:

Ich lese hier still mit. Compiler sind spannend, auch wenn ich nix konkret umsetzen werde.

Quote from Hoogo

Ich lese hier still mit. Compiler sind spannend, auch wenn ich nix konkret umsetzen werde.

Ok, also vier...

Quote from EgonOlsen71

Quote from Hoogo

Ich lese hier still mit. Compiler sind spannend, auch wenn ich nix konkret umsetzen werde.

Ok, also vier...

Fünf

sechs

Tatsächlich sind die Schleifen, darin die IFs und viele Arrayzugriffe doch exakt genau das, was in der Praxis in geschwindigkeitskritischem Code häufig passiert. Benchmark 7 in #9 ist 1:1 aus Gold Quest 6 übernommen, und in GQ6 taucht solcher Code noch an weiteren Stellen (z.B. beim Generieren des Labyrinths) auf. Genaugenommen ist das in GQ6 fast die einzige Stelle/Art von Code, bei dem Kompilieren sich überhaupt wirklich lohnt.

Aber grundsätzlich stimmt schon insbesondere dass bei Microbenchmarks mehr zwischen FOR/NEXT stehen muss (genau das hatte ich auch schon in PMs mit muffi angesprochen).

Vielleicht die Microbenchmarks etwas anpassen (mehr zwischen FOR/NEXT, noch z.B. eben String-Manipulationen dazu, was noch?) plus zwei, drei Non-Micro-Benchmarks? Realer ausgekoppelter Code aus bestehenden Applikationen/Spielen wäre toll.

Sieben