Wenn ich mich nicht verrechnet habe, kommt dabei raus:
2009 SYS2088
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
Wenn ich mich nicht verrechnet habe, kommt dabei raus:
2009 SYS2088
Heute so angekommen & heute so gebastelt...
eine Mini Antonov AN-225 aus China
Update auf V1.06 behebt ein Problem beim ändern der Uhrzeit über das Feld "Datum/Zeit" rechts oben... (keine Eingaben möglich).
Sonst keine Änderungen.
Gibt es dazu einen Downloadlink?
Ich habe für meine Tests ein eigenes QSORT-Beispiel im Bestand, das dürfte von den Performancecharakteristiken [...] natürlich ziemlich anders sein
Ich hab mir das mal angesehen. Dein Algo arbeitet natürlich ganz anders, mit Peek & Poke lässt sich natürlich saumäßig viel gewinnen. Trotzdem "Danke!" für das Beispiel!
Wieso hast Du EgonOlsens Cross-Compiler ausgelassen?
Weil ich - wie schon seit dem ersten Posting - nur native Compiler berücksichtige.
Sodele, Stephan Scheuer ist schuld
Ich habe die ganze Geschichte nochmal aufgerollt. Nebenbei habe ich im delayed-replacement noch einen Abtippfehler festgestellt, der sich aber anscheinend gar nicht groß auswirkt.
Bemerkung: es ist bei diesem Test nicht das Ziel, das Allerletzte aus den Compilern raus zu holen - hier steht die Kompatibilität zu Basic im Mittelpunkt; deswegen gibt es auch keine Integer-Laufvariablen.
Als Erweiterung habe ich den Basis-Boss und den Basic64 versucht zu optimieren. Für den Boss war es kein Problem (allerdings auch nicht bis zum letzten Taktzyklus), aber Basic64 mag Integer-Variablen nicht mit STEP-1 verarbeiten; damit ist ein riesiges Potential im Eimer. Aus dem Grund taucht Basic64 weiterhin nur mit einem Eintrag auf, denn die TI-Laufzeiten sind identisch, die anderen Variablen spielen halt einfach nicht die Rolle.
Viel Spaß beim Stöbern
Du muss auch die Variabeln als Byte oder Word deklarieren, dann sollte es schneller werden.
Meinst Du? Im Handbuch ist dadrauf kein Hinweis zu finden. Nur bei fastarray findet sich der Hinweis, dass die bad-subscript-Prüfung wegfällt. Bei shortif ein anderes Konstrukt und bei fastfor darf nur ein next pro for verwendet werden. Kein Wort auf die Art der Variablen. Aber vielleicht teste ich das noch
Petspeed ist ziemlich gut bei Arrayzugriffen. Und Basic-Boss ist im Verhältnis eher langsam bei Arrayzugriffen. Vermutlich kommen die Unterschiede daher.
Ich kanns nicht lassen
Hab ich mich hingesetzt, die 3 Direktiven fastfor, shortif, fastarray eingebaut.
Und dann kam das Ergebnis. Exakt gleich schnell!
Also dachte ich, die Direktiven wären in der 2.42 schon vorgegeben, also slowfor, longif, slowarray. Und wieder: exakt gleich schnell!
Das Gleiche habe ich dann noch mit der 2.40 gemacht, keine Unterschiede. Das finde ich schon sehr merkwürdig.
Petspeed setzt alles, was möglich ist, in Integer-Werten um. Deshalb ist der so schnell. Der hat sogar den Basic Boss, ohne Optimierungen, geschlagen. Und das Programm ist von 1982.
Einziges Manko ist, dass das Compilat sehr groß werden kann.
Petspeed müsste noch älter als 1982 sein, oder? Der Name sagt es ja schon, den gab es für die PETs ursprünglich.
Der Basic-Boss schaut im Sortier-Test gar nicht gut aus ohne Optimierungen, wie ich finde. Selbst der Basic64, der ca. 1985 war, schlägt den Boss, selbst im P-Mode und auch Austro, ursprünglich auch für PET, ist schneller.
Das Compilat vom Petspeed ist deswegen so groß, weil der ja sämtliche Variablen und Felder mitschleppt.
Und wie schnell ist die Assembler Version?
Das ist der Fred "Heute so compiliert..."
So, Freunde des gepflegten Compilierens
Jetzt etwas ausführlicher zum Sortier-Test.
Angetreten zum Einen mein kleines Programm, mit dem ich meine Lego-Sets verwalte und sortiert drucke. Ab Zeile 2000 sind die Data-Zeilen, die im folgenden Format aufgebaut sind:
2000 DATA lego-nummer,"bezeichnung des sets"
In Zeile 9999 ist die Endmarkierung bereits enthalten. Sortiert wird ausschließlich nach der Lego-Nummer NR(), die Bezeichnung ist in BE$() enthalten.
Ich habe 4 Sortierverfahren implementiert, man hat die Wahl: Straight insertion (aus 64er), Minisort (aus 64er), Delayed replacement (C= Sachbuch 9) und Quicksort (aus 64er). Ich habe derzeit 49 Einträge; die sind nicht im angehängten Programm enthalten.
Optimierungen sind absolut keine vorhanden; einzig in Zeile 40 ist eine Compiler-Direktive für den Speedcompiler, der die Stringlänge des Feldes auf 40 Zeichen begrenzt (die Zeilenbreite meines Druckers ); andernfalls steigt der beim Compilieren aus.
Angetreten zum Anderen sind folgende, native Kandidaten: Basic-Boss, Basic64, Austro-Comp, Austro-Speed, Petspeed, DTL, LaserBasic-Compiler, Speedcompiler, Hypra-Compiler und unser Spezialfreund BASS.
Hier die Tabelle der Ergebnisse (TI vornedran und in Klammern TI$):
Nanu, da fehlen ja 2 Compiler in der Tabelle? Ja!
Der Hypra-Compiler ist bei einer einfachen Stringoperation ausgestiegen. Nicht einmal der Speedcompiler, der da gerne empfindlich ist, hat irgendwas bemängelt.
Und Spezialfreund BASS ist (natürlich?) auch nicht dabei. Grund: in Pass 4 (was mal eben geschätzte 15 Min gedauert hat und meine 1571 fröhlich geschnurrt hat) hat er einen angeblich unbekannten Sprung entdeckt. Das Ding hat einfach selber einen Sprung
Absolut erstaunlich ist der Petspeed, der mit großem Abstand gewonnen hat. Da der Quicksort keine FOR-Schleifen nutzt, kann das schon mal nicht die Erklärung sein. Das alte Ding hat einfach mehr auf dem Kasten.
Ich habe heute wieder eines meiner Lieblingsspiele gemacht: Compiler quälen. Mehr dazu folgt im Compiler-Fred in Kürze
Wenn du TI verwendest, würdest du die Jiffies kriegen. Sechzigstel Sekunden. Wär dann noch etwas nerdiger
TI verwende ich auch, aber mit meinem Löchergedächtnis sind die Zahlen zu schnell weg, bis ich am PC bin
Mich würde interessieren wie viele Datensätze das sind?
Knappe 50. Wollte es noch dazu schreiben, habs dann aber doch vergessen.
Heute mal wieder einen kleinen Compiler-Test gemacht. Ganz ohne Optimierungen. Und auch nur mit TI$ gemessen.
Meinen Lego-Set-Bestand verwalte ich am C64; die Nummer plus Bezeichnung.
Implementiert habe ich den Quicksort aus 64er 86/07; es wird nach der Lego-Nummer sortiert.
Hier habe ich mal die Ausführungszeiten aufgeführt:
Basic: 9 sek
Austro-Comp 3 sek
Basic-Boss 2 sek
Austro-Speed 1 sek
Basic64 (M-Code) 1 sek
Petspeed 0 sek (nicht vertippt, der war wirklich praktisch direkt fertig!)
und es hat keinen Batteriebetrieb oder eingebauten Akku.
Das ist zwar richtig; aber nachdem der TV ein Netzteil hat, dürfte sich das "nachrüsten" lassen
denn das scheint zum einen ein schon älteres Modell zu sein
Ja, das ist es. Der einzige, kleine Fernseher mit massig Anschlüssen und sogar SD-Slot.
muffi Da gehen unsere Ansichten wohl etwas auseinander, denn das Bild über Antenne (du meinst schon RF?) ist doch bekanntermaßen das schlechteste? 10" ist zumindestens eine ausreichende Bildgrösse.
Hast du Links zu den Geräten, vielleicht auch mal ein Beispiel, wie das bei dir aussieht?
https://www.grundlagen-compute…d-83688-led-tv-ab-09-juni
https://www.hifitest.de/test/a…ife-p73011-md-83688--7337
Ich glaube nicht, das man an diesen modernen Geräten ein akzeptables Bild über die Composite- AV- Buchse bekommt.
Ich habe hier 2 10,1" TFT Tevion-Fernseher, die bringen über die Antenne ein wunderbares Bild vom C64.
Du, nein, danke, muss nicht auf dem C64 laufen. Und deine Vorschläge kommen alle in die engere Auswahl!
Wenn es nativ am C64 sein soll, würde ich zum Basic-Boss raten, weil der von den Optimierungen her die besten Einstellmöglichkeiten bietet. Und einen Grafikpixel zu berechnen, das geht im compilierten Basic auch recht fix, wenn man nicht die Routinen einbaut, die eine Potenz nutzen. Das muss man ersetzen.
Ja, ich weiß, ich müsste mal wieder updaten