The Evolution of the QEMU Translator

Re:The Evolution of the QEMU Translator by thesz on Friday January 29, 2021 @05:01PM (#25963267)

Of course, hardware helps a lot. But I doubt that getting from typical 5%-10% of native performance to 70% (7-14 times speedup) can be attributed only to hardware assistance. MIPS is way too different from x86.

[ Parent | on HN ]

Re:The Evolution of the QEMU Translator by saagarjha on Saturday January 30, 2021 @05:54AM (#25968068)

5%-10% is typical performance for a pure interpreter; a good JIT can hit 30%-50%. After that the main issue is going to be the MMU that I mentioned, and having hardware support there gets you to nearly native.

[ Parent | on HN ]

Re:The Evolution of the QEMU Translator by thesz on Wednesday February 03, 2021 @08:18PM (#26021422)

"The good JIT" is a TCG at the time. Is it good for you?

MIPS needs about 20 to 40 cycles for page fault handling. For 500MHz MIPS (Verilog/VHDL implementation synthesized to 90nm - yes, I am that old) it translates to latency from 1us to 2us. [1] shows that typical x86 page fault latency is ~7.8us, about at least twice as much. [2] (best I've found, sorry) speculates that functions compute x86 status codes and allow 80-bit long double operations natively.

[1] https://makedist.com/posts/2016/10/10/measuring-userfaultfd-...

[2] https://news.ycombinator.com/item?id=15543718

Excuse my rant, but MIPS has just one mistake - delay branch slot. It complicates implementation immensely. Other than that, it is a fascinating architecture. They claimed that their CPU can be programmed using regular instructions as effective as others do with microcode and thus MIPS does not need that and my experience had shown that.

[ Parent | on HN ]