Beiträge von Tale-X im Thema „Pixel über Array statt Poke setzen“

    Ich schätze, der Unterschied wäre nur minimal. Der Haken ist, dass wohl alles über Fließkommazahl geht. Bei a%=b% wird zuerst Integer in Fließkomma und dann Fließkomma in Integer umgewandelt.

    Und so ist auch mein Testergebnis bei 1000 Zuweisungen: a=b ist schneller als a%=b das schneller als a%=b% ist. Die Zeiten (nach ti): 140 zu 160 zu 180, also nicht die Welt

    Wenn's um den letzten Prozentpunkt Performance geht - nicht auf Integer setzen...

    Stimmt, ich unterschätze das Parsen des Interpreters, Compiler versauen einen in der Beziehung :whistling:

    Hab' mal beides auf Variablen umgestellt - a%(i)=i% und pokea,i. Dann ist Array max. 25% schneller. Spannend ist der Unterschied bei den verschiedenen i% Werten.

    Bei i% scheint es umso länger zu daueren, je mehr bits gesetzt sind und umso höherwertiger sie sind. -1 dauert am längsten (klar alle Bits gesetzt). Bei den einzelnen Bits: 16384 am Kürzesten. 8192 dauert einen kleinen Hauch länger... usw usf. bis 1 (bei meinem Programm sind es jeweils 5 TI-Einheiten). Nur -32768 schlägt aus der Reihe, das braucht ungefähr solange wie 2048. Och nöööö... wenn ich einem INTEGER-Array eine Fließkommazahl zuweise ist er in der Regel schneller als bei einer INTEGER-Zahl. Das hat dann aber nichts mehr mit Interpreter vs. Compiler zu tun, sondern dass Basic V2 schräg ist.

    Aber der Vorteil schrumpft deutlich und wenn die Auslese und Oder-Verknüpfungen bei Ganzzahlen ähnlich schleichen wie der zum setzen wundert mich gar nix mehr.

    Die Idee beschäftigte mich schon vor Urzeiten, als das erste Mal das Thema Löschen mit Array aufkam. Außerdem hatte sich bei mir irgendwie festgesetzt, dass die Implementierung des Poke-Befehls ineffizient sein soll (hab' ich aber nie überprüft). Von daher musste ich das einfach mal ausprobieren...

    Die Modifikationen bringen etwas, allerdings auch beim Ausgangsprogramm - das leider so schon nen kleinen Tick schneller ist.

    Was mich fuchst - eigentlich ist das Array *deutlich* schneller:


    Hmmm...

    Mir hat's beim Anblick des Listings im Thread Bitte melde dich an, um diesen Link zu sehen. in den Fingern gejuckt, insbesondere bei dem Trick mit DIMF%(8000). Ich hatte mich schon lange gefragt, ob über das Array auch Grafik erzeugt werden kann (Antwort ja) - und ob es performanter ist (im konkreten Fall ... eher nein).

    Warnhinweis am Anfang:
    Das ist eine reine Machbarkeitsstudie. Der Ansatz ist robust wie ein Kartenhaus - eine unbedachte Änderung im Code und die Grafikerzeugung macht Murks. Nett, es mal gesehen bzw. gemacht zu haben. Ich hab viel über Speicherverwaltung im C64 gelernt.

    Vorüberlegungen:
    Ausgangspunkt bei meiner Überlegung war das Integer-Array F%. Integer ist beim C64 ein 16Bit-Zweierkomplement, erstes Bit ist das Vorzeichenbit (Wert -32768), der Rest ganz normal (16384, 8192,...,1). Abgelegt wird der Integerwert wie folgt: zuerst das höherwertige Byte, dann das niederwertige. Da im Array alle Werte ohne Lücken aufeinanderfolgen kann über den Index indirekt auf den darunterliegenden Speicher zugegriffen werden.

    Zuerst heißt's herausfinden, wo genau das Array im Speicher liegt. Und da gibt's den großen Pferdefuß: die Zuordnung ist nicht fest. Sobald eine neue Variable eingeführt wird, verschiebt sich das Array - samt Inhalt (und aus Grafik wird Murks). Ergo: zuerst alle Variablen definieren und erst danach herausfinden, wo das Array liegt. Am besten das Array als letztes anlegen - so gibt es kein zeitraubendes Verschieben durch neue Variablen und die Adresse kann über die Endeadresse des Arrayspeichers (in $31,$32 bzw. 49,50) ermittelt werden und damit der Startbereich des Grafikspeichers in F%. Es macht das Leben einfacher, wenn man in dem Zuge gleich dafür sorgt, dass die Arrayelemente auf einer geraden Adresse beginnen (falls das nicht der Fall ist - einfach eine Zahlenvariable einführen, der Speicher verschiebt sich dann um 7 Byte).

    Genug der Worte, hier der abgewandelte Code aus dem anderen Thread - er hat leider nicht gewonnen durch die Eingriffe. Ich hab' versucht, den Kern und die Bedeutung der Variablen beizubehalten.

    Die wichtigsten Zeilen:
    13 - Ggf. Verschiebung des Speichers durch Hinzufügen der Variable QQ
    14 - Berechnung, an welchem Index die Speicheradresse 8192 liegt. Danach wird auch keine Variable mehr hinzugefügt
    29 - Bildpunkt setzen

    Viel Spaß beim Ausprobieren und Experimentieren. Kleines Beschleunigungspotenzial sehe ich noch in Zeile 29 bei int(xp/z8)*z4, da könnte man ein Wertearray für xp verwenden.

    Ach ja, die Zeiten:
    Das ursprüngliche Listing hatte im Vice 53:17 Minuten gebraucht, diese Fassung hier 54:09.

    Viele Grüße
    Tale-X