Virtueller Hive

[thiloa]

Danke zille9 für deine motivierenden Worte

Ich bin zur Zeit noch mit dem Beschleunigen des Propelleremulators beschäftigt bevor ich mich dann dem Hive selbst zuwenden werde.

Aktuell interpretiere ich die entstehenden Code Bäume meines JIT Ansatzes noch, wodurch der Propelleremulator jetzt erst einmal einige tausendmal langsamer geworden ist

Meine ursprüngliche formale Verifikation ist durch die ganzen Code Transformationen jetzt leider erstmal futsch...
Kennt jemand eigentlich eine gute Testsuite für den Propeller?

[Wuerfel_21]

Meine ursprüngliche formale Verifikation ist durch die ganzen Code Transformationen jetzt leider erstmal futsch...
Kennt jemand eigentlich eine gute Testsuite für den Propeller?

Wär mir jetzt nicht bekannt. Für die ALU-Instruktionen könnte man die Tabellen aus dem Propeller Manual durchtesten, da sind meistens all die komischen Fälle drin.

[thiloa]

Wär mir jetzt nicht bekannt. Für die ALU-Instruktionen könnte man die Tabellen aus dem Propeller Manual durchtesten, da sind meistens all die komischen Fälle drin.

Hm, ich dachte da eher an zusammenhängenden Code, der nicht nur die ALU sondern auch die ganze interne Statemachine und Counter/Video/Hub testet.

Zumindest habe ich jetzt mal mit dem JIT angefangen. Als ersten Test habe ich mal nur die quasi statischen Register (VCFG,CTRA/CTRB, COG_RUNNING) dynamisch heraus optimieren lassen. Da ich das gcc Backend (libgccjit) zur Assemblercodegenerierung nutze, dauert so ein Aufruf leider schon ca. 100msec, dafür scheint der Code sehr gut optimiert zu werden.

Sobald der Init Code der Matrix Demo abgeschlossen ist, läuft sie mit 2,7 MHz statt 1,7 MHz vorher ohne JIT, scheint also schon etwas zu bringen.

Als nächstes möchte ich dann häufiger ausgeführte COG Speicherstellen, bei denen sich die Instruktion über einige Zyklen nicht geändert hat, individuell auf die jeweilige Instruktion hin optimieren lassen. Hier verspreche ich mir einen höheren Geschwindigkeitszuwachs.

[Wuerfel_21]

Klingt vielversprechend - 2,7 MHz sind ja fast zwei(!!!!) Bilder pro Sekunde. Weiter so!

Läuft der JIT asynchron auf 'nem eigenen Thread und/oder mit Cache? 100ms pro VCFG/CTRA/CTRB-Änderung wär nicht gut, gibt einige Fälle wo die ziemlich oft geändert werden.

[thiloa]

Läuft der JIT asynchron auf 'nem eigenen Thread und/oder mit Cache?

Aktuell läuft der Einfachheit halber alles in einem Thread. Später soll der Compiler in anderen Threads laufen und der Propeller solange mit nicht optimiertem Code weiter emuliert werden. Ein Cache wäre eventuell zusätzlich auch eine gute Idee, daran habe ich noch gar nicht gedacht.

VCFG/CTRA/CTRB-Änderung wär nicht gut, gibt einige Fälle wo die ziemlich oft geändert werden.

Die Register habe ich in ihre einzelnen logischen Teile zerpflückt. Derzeit ist die APIN/BPIN Gruppe z.B. ausgenommen, da sie in meinen Beispielprogrammen zu häufig geändert wurden und auch in der dynamischen Auswertung nur wenig Mehraufwand bedeuten. Später baue ich evtl eine einfache Heuristik ein. Außerdem ist mir aufgefallen, dass Änderungen eines Registers häufig kurz nacheinander fallen und somit manchmal Code erzeugt wird, der nur wenige Takte verwendet wird. Hier könnte ich noch etwas sparen, wenn eine Registeränderung erst dann neu kompiliert wird, wenn einige hundert Takte ohne Änderung vergangen sind. In der Zwischenzeit würde dann der unoptimierte Code verwendet werden.

Die Instruktionsoptimierung wird derzeit angeworfen, wenn ein PASM Befehl 1000x ohne Änderung (außer dem SRC Opcode Teil) ausgeführt wurde. Leider scheinen in der libgccjit ein paar Fehler enthalten zu sein, die zu Abstürzen führen, womit ich die Performance noch nicht testen konnte. Eventuell wechsel ich auch auf das LLVM Backend.

[PIC18F2550]

Die Instruktionsoptimierung wird derzeit angeworfen, wenn ein PASM Befehl 1000x ohne Änderung (außer dem SRC Opcode Teil) ausgeführt wurde.

Bei selbstmodifizierenden Code gäbe es keine Optimierung?
Sowas setzt man bei schnelllen Sprungveteilern ein.

[Wuerfel_21]

Vielleicht interessant: Artikel über einen 6502 JIT Emulator: https://scarybeastsecurity.blogspot.com ... 15ghz.html

Die Probleme sind ja bei den Propeller Cog-CPUs mehr oder weniger ähnlich.

[thiloa]

Hallo,

nach etwas längerer Pause habe ich den letzten zwei Wochen "weitergebaut". Den libgccjit Ansatz habe ich verworfen, da es hier für mich nicht nachvollziehbare Abstürze gab und mir auch die Kompilierzeiten zu lange waren. Stattdessen habe ich die Cog und Hub Statemaschine teilautomatisiert umgeformt und CPU freundlicher gestaltet.

Unter anderem werden die Opcodes jetzt mit einer Sprungtabelle (obersten 9 Bit) abgearbeitet. Der ganze Propeller läuft jetzt in x86-64 Assembler (auch teilautomatisiert erzeugt). Hierdurch werden z.B. die Flagberechnung nativ vorgenommen (sowas kann man ja in C/C++ nicht direkt nutzen sondern muss da auf die Intelligenz es Compilers hoffen).

Die Counter, Videogeneratoren und Pin Outs werden immer noch mit dynamisch generiertem Code betrieben. Der Code wird allerdings nicht mehr mit einem klassichen Jit erzeugt, sondern aus kurzen vorerstellten Assemblerroutinen nur noch zusammenkopiert. Damit ist die Codeerzeugung jetzt extrem schnell und fällt gar nicht mehr auf (~10µs statt >100ms).

Die Simulationsgeschwindigkeit konnte ich damit auch etwa verdoppeln, die Turbulence Demo läuft jetzt mit etwa 4,6 MHz.

Gibt noch ein paar Baustellen, eventuell ist noch etwas mehr an Geschwindigkeit rauszuholen.

[digger]

Ist ja eine krasse Steigerung

[PIC18F2550]

Ja so isses zurück zu den Wurzeln der CPU.