Re: [Qemu-devel] Profiling Qemu for speed?

["André Braga" <meianoite@gmail.com>]

The problem with table lookups (I'm assuming you're talking about
function pointer vectors) is that they *destroy* spatial locality of
reference that you could otherwise attain by having series of
if-then-else instructions and some clever instruction prefetching
mechanism on modern processors... Not to mention the function call
overhead.


However, for puely aesthetical reasons:
(Disclaimer: I'm not familiar (lack of time, sorry) with what
disas_insn does apart from what is obviously implied by its name, so
maybe the following may make any sense or not...)

If it happens to be the case that disas_insn decodes the instruction
and then proceeds to the native implementation of the opcode in
question, if you used the table lookup only to find the function entry
point and then paste its CONTENT on a code buffer and then concatenate
this with the rest of the translated code, and the whole basic block
would be run from there from that part on (caveat self-modifying
code), then it would really clean up that piece of code. But I suspect
it wouldn't be any faster than the current approach.


-- 
"A year spent in artificial intelligence is enough to make one believe
in God"-Alan J. Perlis


2005/4/17, Nathaniel G H <rice_burners_suck@yahoo.com>:
> Unless someone can show me that GCC produces table-lookups for the
> switches in disas_insn(), there's a good opportunity for increased
> speed by doing this manually. Do you agree with this assessment?
> 
> Please let me know if I'm on the right track. :-)