Yeah, it would be interesting, but it’s not doable in either the original DBZ scenario, or in upload scenarios: you can’t emulate an emulator and get a speedup like that—the buckpassing doesn’t work, the computations still have to be done somewhere.
(Any optimization you could apply to emulating an emulation, like some sort of Futamura projection collapsing the emulated program and the emulated hardware, could be done at the original emulation level, so all it leaves you with is possible programming convenience and constant factors of inefficiency and indirection.)
You can have an arbitrarily deep sequence of speeding-up optimized nested emulations, with each subsequent emulation running faster by its container’s clock than the otherwise identical container would run by itself (by its own clock).
(The catch is that n obk gung’f ehaavat na rzhyngvba znl or fybjre ol vgf pbagnvare’f pybpx guna vs vg vfa’g.)
Yeah, it would be interesting, but it’s not doable in either the original DBZ scenario, or in upload scenarios: you can’t emulate an emulator and get a speedup like that—the buckpassing doesn’t work, the computations still have to be done somewhere.
(Any optimization you could apply to emulating an emulation, like some sort of Futamura projection collapsing the emulated program and the emulated hardware, could be done at the original emulation level, so all it leaves you with is possible programming convenience and constant factors of inefficiency and indirection.)
You can have an arbitrarily deep sequence of speeding-up optimized nested emulations, with each subsequent emulation running faster by its container’s clock than the otherwise identical container would run by itself (by its own clock).
(The catch is that n obk gung’f ehaavat na rzhyngvba znl or fybjre ol vgf pbagnvare’f pybpx guna vs vg vfa’g.)