Bochs IPS
-
Ryu
Bochs IPS
In bochsrc.txt I'm guessing this stands for instructions per second? I was wondering if I wanted to emulate a 1ghz processor what is the formula to convert into IPS. If setting this number to bochs, using rdtsc instruction (with cache and so on applied) are reliable? There are some calls I like to time that is in the more critical sections, and I also have only one monitor of the few systems at hand :/
Re:Bochs IPS
Hi,
Unfortunately, for this to work you'd probably need a 200 GHz CPU because Bochs isn't that fast...
It also depends on how you set the "clock: sync=" line in "bochsrc.txt".
If you set it with something like "clock: sync=none, time0=utc" then Bochs will go as fast as it can without trying to keep the time inside the emulator the same as the time on the real computer. In this case the IPS= value should be calibrated to match how fast the emulator can run, so that the time inside the emulator isn't completely messed up.
Instead, if you use "clock: sync=slowdown, time0=utc" then Bochs will slow down when the time inside the emulator gets ahead of the time on the real computer. In this case you'd need to set the IPS= value to something that Bochs can actually achieve, otherwise the time inside the emulator never gets ahead of the time on the real computer, and the time inside the emulator still gets messed up.
Lastly, you could try "clock: sync=realtime, time0=utc" so that the time inside the emulator is the same as the time on the real computer and Bochs goes as fast as it can. This means that IPS is partly ignored, and in one second it might do 1234567 instructions and another second it might do 87654321 instructions.
For the first 2 options, Bochs is "deterministic". This basically means that if you do the same thing twice you should get the same result both times. For the third option it's not deterministic, so if you've got a bug that depends on timing it'll happen sometimes but not others.
Also there's other settings that depend on the number of IPS that Bochs actually does (which is different to the IPS that you tell Bochs to try to do). Most common is the "vga_update_interval: 50000" setting, which would tell Bochs that after each group of 50000 instructions it should update the screen. If you want Bochs to run faster you could increase this setting (and reduce the time it spends updating the screen), but you might not be able to see what you're doing. There's a few other delays that work like this (e.g. keyboard_serial_delay, keyboard_paste_delay and floppy_command_delay).
For performance tuning, Bochs doesn't emulate caches (although it does have something slightly similar to a trace cache, and does emulate TLBs), so it won't make any difference if the caches are enabled or not. It also doesn't emulate instruction pipelining or out of order execution, and register dependancies don't matter. If you combine this with the "every instruction takes 1 cycle" then you'll realise how useful it is for accurate performance tuning....
Cheers,
Brendan
For Bochs, every instruction takes 1 cycle, so IPS = cycles per second. For real computers most instructions take more than one cycle, so for 1 GHz you'd probably want something like "IPS=500000000".Ryu wrote:In bochsrc.txt I'm guessing this stands for instructions per second? I was wondering if I wanted to emulate a 1ghz processor what is the formula to convert into IPS. If setting this number to bochs, using rdtsc instruction (with cache and so on applied) are reliable? There are some calls I like to time that is in the more critical sections, and I also have only one monitor of the few systems at hand :/
Unfortunately, for this to work you'd probably need a 200 GHz CPU because Bochs isn't that fast...
It also depends on how you set the "clock: sync=" line in "bochsrc.txt".
If you set it with something like "clock: sync=none, time0=utc" then Bochs will go as fast as it can without trying to keep the time inside the emulator the same as the time on the real computer. In this case the IPS= value should be calibrated to match how fast the emulator can run, so that the time inside the emulator isn't completely messed up.
Instead, if you use "clock: sync=slowdown, time0=utc" then Bochs will slow down when the time inside the emulator gets ahead of the time on the real computer. In this case you'd need to set the IPS= value to something that Bochs can actually achieve, otherwise the time inside the emulator never gets ahead of the time on the real computer, and the time inside the emulator still gets messed up.
Lastly, you could try "clock: sync=realtime, time0=utc" so that the time inside the emulator is the same as the time on the real computer and Bochs goes as fast as it can. This means that IPS is partly ignored, and in one second it might do 1234567 instructions and another second it might do 87654321 instructions.
For the first 2 options, Bochs is "deterministic". This basically means that if you do the same thing twice you should get the same result both times. For the third option it's not deterministic, so if you've got a bug that depends on timing it'll happen sometimes but not others.
Also there's other settings that depend on the number of IPS that Bochs actually does (which is different to the IPS that you tell Bochs to try to do). Most common is the "vga_update_interval: 50000" setting, which would tell Bochs that after each group of 50000 instructions it should update the screen. If you want Bochs to run faster you could increase this setting (and reduce the time it spends updating the screen), but you might not be able to see what you're doing. There's a few other delays that work like this (e.g. keyboard_serial_delay, keyboard_paste_delay and floppy_command_delay).
For performance tuning, Bochs doesn't emulate caches (although it does have something slightly similar to a trace cache, and does emulate TLBs), so it won't make any difference if the caches are enabled or not. It also doesn't emulate instruction pipelining or out of order execution, and register dependancies don't matter. If you combine this with the "every instruction takes 1 cycle" then you'll realise how useful it is for accurate performance tuning....
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Ryu
Re:Bochs IPS
Hmm, yes the 1 instruction per cycle can be useful if your looking for instruction effeciency, but when pentiums and up theres so much optimizations perfomed by the cache and UV pipelines that is going to dratically change the result of clocks to preform some given task. I've tested the call I was wanting to test, disabling the cache resulted roughly 23,000 clocks while cache on resulted roughly 3200 clocks. What bochs gives me in result seems to suffice for generally how quick it will be, just sometimes like in my case I was looking for more efficiency on the cache lines.
Thanks for explaining all the bochs options, infact it helped my bochs run quicker then my usual session in bochs! Before I was waiting a good 3-5 seconds on the "booting from floppy screen".. now theres probably a split second delay, and reading from the floppy is much quicker.
Thanks for explaining all the bochs options, infact it helped my bochs run quicker then my usual session in bochs! Before I was waiting a good 3-5 seconds on the "booting from floppy screen".. now theres probably a split second delay, and reading from the floppy is much quicker.
