Faster than real-time execution

Faster than real-time execution

[frankwmiller frankwmiller.net]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Greetings,
 
I've been contemplating using QEMU for faster-than-real-time execution of SPARC executables on an X86-64 machine.   It appears from the base architecture of QEMU that this is not possible if QEMU is using JIT of the SPARC to x86-84 since the resulting x86-64 will run on the hardware at the processor clock speed and there's not really any way around that.
 
However, is it possible to do something like this.  Execute the SPARC instructions in simulation, i.e. without any JIT, and then since everything is executed as simulated SPARC instructions, essentially speed up time in the simulated environment and execute FRT that way?
 
Thanks
FM
 
 

[-- Attachment #2: Type: text/html, Size: 1209 bytes --]

Re: Faster than real-time execution

[Alex Bennée]

"frankwmiller frankwmiller.net" <frankwmiller@frankwmiller.net> writes:

> Greetings, 
>   
> I've been contemplating using QEMU for faster-than-real-time execution of SPARC executables on an X86-64 machine.
>   It appears from the base architecture of QEMU that this is not possible if QEMU is using JIT of the SPARC to x86-84
> since the resulting x86-64 will run on the hardware at the processor clock speed and there's not really any way around
> that. 
>   
> However, is it possible to do something like this.  Execute the SPARC instructions in simulation, i.e. without any JIT, and
> then since everything is executed as simulated SPARC instructions, essentially speed up time in the simulated
> environment and execute FRT that way?

Have a look at icount mode:

  -icount [shift=N|auto][,align=on|off][,sleep=on|off][,rr=record|replay,rrfile=filename[,rrsnapshot=snapshot]]

      Enable virtual instruction counter. The virtual cpu will execute one instruction every 2^N ns of virtual time. If auto is specified then the virtual cpu speed will be automatically adjusted to keep virtual time within a few seconds of real time.

      Note that while this option can give deterministic behavior, it does not provide cycle accurate emulation. Modern CPUs contain superscalar out of order cores with complex cache hierarchies. The number of instructions executed often has little or no correlation with actual performance.

      When the virtual cpu is sleeping, the virtual time will advance at default speed unless sleep=on is specified. With sleep=on, the virtual time will jump to the next timer deadline instantly whenever the virtual cpu goes to sleep mode and will not advance if no timer is enabled. This behavior gives deterministic execution times from the guest point of view. The default if icount is enabled is sleep=off. sleep=on cannot be used together with either shift=auto or align=on.

      align=on will activate the delay algorithm which will try to synchronise the host clock and the virtual clock. The goal is to have a guest running at the real frequency imposed by the shift option. Whenever the guest clock is behind the host clock and if align=on is specified then we print a message to the user to inform about the delay. Currently this option does not work when shift is auto. Note: The sync algorithm will work for those shift values for which the guest clock runs ahead of the host clock. Typically this happens when the shift value is high (how high depends on the host machine). The default if icount is enabled is align=off.

      When the rr option is specified deterministic record/replay is enabled. The rrfile= option must also be provided to specify the path to the replay log. In record mode data is written to this file, and in replay mode it is read back. If the rrsnapshot option is given then it specifies a VM snapshot name. In record mode, a new VM snapshot with the given name is created at the start of execution recording. In replay mode this option specifies the snapshot name used to load the initial VM state.


You can read more about how it works at: https://qemu.readthedocs.io/en/latest/devel/tcg-icount.html

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro