Hello, Guest the thread was called10k times and contains 278 replays

last post from EgonOlsen71 at the

Heute so compiliert...

  • 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


    Code
    1. -compression=true

    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)

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

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

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

  • Das ist ja kein Code und es auch Platz, den die anderen Kompilate im Speicher ebenfalls belegen würden.

    Stimmt nicht ganz, das Compilat des Petspeed hat auch alle Variablen in der Datei schon mit drin.

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

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

  • 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 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:


  • EgonOlsen71 Naja, ganz so sicher bin ich mir nicht, ob das nur uns 3 interessiert. Ich denke, wir werden noch einen Anteil stiller Mitleser haben, die das Thema auch spannend finden.


    Ich mache mir mal Gedanken, wie man das "Problem" mit Array-Zugriffen anders gestalten könnte. Auf der anderen Seite ist aber das alleine schon ein interessanter Benchmark, um genau die Performance zu messen. Konstruktionen wie DATA und FOR/POKE/NEXT hatte ich absichtlich ja nicht mit eingebaut, da gerade der Boss durch Optimierungen hier richtig auftrumpfen kann.


    Vielleicht wäre es auch ein Ansatzpunkt, einen neuen Benchmark so zu gestalten, dass man das Basic-Programm gar nicht mehr in zwei Teile teilt (Real und Integer-Schleifen), sondern stattdessen die möglichen Optimierungen einfließen lässt (Basic64 und Boss haben da schließlich einen deutlichen Handlungsspielraum). Den Mospeed kann man ggf. quasi außer Konkurrenz mit laufen lassen. Warum außer Konkurrenz? Weil ich auf Cross-Compiling gar nicht so scharf bin: :org:

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