> My quote didn't mention polymorphism at all, only "OO," and I don't see any
> reason why polymorphism is required to be considered object-oriented.
Oh, right of course. I just thought you referred to my earlier comment about polymorphism.
> The overhead stems from the increased latency of instruction execution on a
> given processor and the effect that latency has on timing events. The raw
> cycles spent on bookkeeping is pretty much linearly proportional to the number
> of processors being emulated. On the other extreme, a program that has a main
> processor waiting for coprocessors to finish tasks, and/or uses vsync will
> suffer a non-linear slowdown factor due to a couple reasons. One big one is
> that that idle coprocessors still need to be emulated. Putting idle processors
> to sleep might not be an option if they do more than spinwait. This means that
> the slower your emulator is, the more idle processing instructions you emulate.
Maybe I don't understand you correctly, but shouldn't that be: The less interleaving you do, the more idle processing instructions you emulate? I mean I can understand that if a main cpu triggers a coprocessor to do something, the coproc. should leave any idle loops as fast as possible. One simple way to do that is to increase interleaving, right?
> These emulated cycles are a complete waste if the processor is just spinwaiting.
> Additionally, if the program is vsync based where the rendering must occur
> during vblank, the wasted cycles may cause vblanks to be missed. A vicious
> cycle forms and as you make the core faster, you end up seeing a non-linear
> speed gain due to the timing dependencies.
> Parallel code adds overhead by nature. On a real multi-processor machine, more
> function calls and instructions may be executed when a program is configured to
> use multiple processors versus a single processor. This can end up being faster
> on a real system because the code is executed in parallel. An emulator running
> on a single processor has to emulate the instructions sequentally in an
> interleaved fashion. This is not parallel and depending on the slowdown factor
> of the emulator, the overhead of a parallel program may be expanded to such an
> extent that it creates noticable performance degredation.
Hmmm, so what you're saying is that to ensure proper synchronization you have to interleave as much as possible, right? In my own emulator, the only overhead this adds just is more interrupt checking. Sure this adds overhead and it can add up, but the overhead is not really noticable on my emu but maybe that's because I only emulated fairly simple machines.