4 ms·

QEMU interpreter uses all the tricks? Very much doubt that. QEMU is a JIT first, built around maximum flexibility, not performance. A dedicated, optimized x86

• kragen 2y ago
  i wouldn't describe sacrificing 80% of the machine's native performance as 'very fast'. a moped goes 40 km/hour; a ferrari goes 200 km/hour. you're paying for a ferrari but getting a moped
  • ant6n 2y ago
    An interpreter that runs at 20% native speed would be considered a very fast interpreter. That would be an order of magnitude faster than a „trickle“.
    • kragen 2y ago
      what i'm saying is that, because an interpreter that runs at 20% native speed would be considered a very fast interpreter, which is still very slow, there are in most cases no tricks for making interpreters very fast
• deaddodo 2y ago
  Do you actually have any experience with systems emulation, JIT/AOT compilation, Apple's x86->ARM hardware assistance that it's JIT interfaces offer, etc? Or are you just speaking off the cuff in a very general manner? Because it very much sounds like the latter. I have, quite extensively. I can assure you, that the source set they are using most definitely does use all the "tricks" (the chief two being threaded code [no, not that threading] and preoptimized jump tables). I can also assure you that losing the hardware acceleration offered by Apple's extensions and the general performance boost JIT/AOT offer is much more than 80%. But, sure. For argument's sake, let's accept your (incorrect) premise. Taking a 1ghz potential emulated target processor down to 200mhz is a fairly drastic drop. Disallowing a whole slew of modern code/target OSes and verging the usability on nil.