marovada, I wouldn't take it too personally.
Maybe a further possible explanation would help. These sorts of "benchmarks" are usually simple tests meant to determine the clock speed of a fixed CPU architecture. They're actually a lot like "bogoMIPS" on Linux. Because of this, any instruction with a predictable number of cycles is fair game. This includes some really slow instructions like divides. This is especially true as processors get more complex and harder to count cycles for; the big slow instructions ran back to back will be more stable. Code sequences like this might perform really well in qemu and other binary translators, because very roughly speaking part of CPU emulator overhead is proportional to the number of cycles vs the number of instructions. That's because things like translation overhead, hit to instruction cache, register allocation, cycle counting, etc etc are more proportional to number of instructions, whereas the actual execution of the instruction might be similar on both architectures. Another big part of this is that these benchmarks will avoid memory accesses, because the timing of these are a lot less stable/predictable. Memory accesses can be one of the most expensive parts of a CPU emulator. A similar thing can be said for branches, on both counts. So you'll get highly predictable, many iteration, moderate length (not so large as to blow cache, not so small as to incur branch overhead) loops of slow instructions. Something that plays really nicely with an emulator and isn't the least bit representative of real code.
'course, any or all of that could be completely false for this particular test, so just take that as a hypothetical..