Virtueller Hive
Re: Virtueller Hive
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?
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
- Beiträge: 57
- Registriert: Di 21. Jan 2020, 19:20
Re: Virtueller Hive
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.
Re: Virtueller Hive
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.Wuerfel_21 hat geschrieben: ↑Mo 19. Okt 2020, 08:28 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.
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
- Beiträge: 57
- Registriert: Di 21. Jan 2020, 19:20
Re: Virtueller Hive
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.
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.
Re: Virtueller Hive
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.Wuerfel_21 hat geschrieben: ↑So 8. Nov 2020, 20:45 Läuft der JIT asynchron auf 'nem eigenen Thread und/oder mit Cache?
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.Wuerfel_21 hat geschrieben: ↑So 8. Nov 2020, 20:45 VCFG/CTRA/CTRB-Änderung wär nicht gut, gibt einige Fälle wo die ziemlich oft geändert 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
- Beiträge: 2835
- Registriert: Fr 30. Sep 2011, 13:08
Re: Virtueller Hive
Bei selbstmodifizierenden Code gäbe es keine Optimierung?Die Instruktionsoptimierung wird derzeit angeworfen, wenn ein PASM Befehl 1000x ohne Änderung (außer dem SRC Opcode Teil) ausgeführt wurde.
Sowas setzt man bei schnelllen Sprungveteilern ein.
Gruß
PIC18F2550
drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
PIC18F2550
drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
- Wuerfel_21
- Beiträge: 57
- Registriert: Di 21. Jan 2020, 19:20
Re: Virtueller Hive
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.
Die Probleme sind ja bei den Propeller Cog-CPUs mehr oder weniger ähnlich.
Re: Virtueller Hive
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.
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.
- PIC18F2550
- Beiträge: 2835
- Registriert: Fr 30. Sep 2011, 13:08
Re: Virtueller Hive
Ja so isses zurück zu den Wurzeln der CPU.
Gruß
PIC18F2550
drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
PIC18F2550
drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo