On Wed, 13 Dec 2000, Kevin Lawton wrote:
> Just a quick note on progress of turning off SBE (code prescanning)
> for user code (ring3).
>
> I've put in the framework for doing this. Only support it for
> paging-off for the moment - will fill in for paging-on soon.
>
> I modified the cooperative guest microkernel to test the
> performance difference with prescanning on and off. Made
> the test thrash the living crap out of the SBE code by
> contantly jumping between pages for no reason. Maybe not
> realistic but it makes my numbers look good. :^) Here's
> the results. I used a stopwatch to time how long a number
> of iterations took:
>
> with user-code prescanning on ............ 120 seconds
> with user-code prescanning off ........... 2 seconds
>
> With user-code prescanning off, code which is doing number
> crunching etc runs at near native speed. :^)
Looks very promising! I've done some benchmarking as well:
to comment on some testing I did and have an excuse for not having vga
planar VGA video modes (like 640x480x16 colors) speed-ups I wrote
about ready for plex86 yet, here are some tests:
Program: Borland Turbo Pascal bgidemo.exe setaspectratio
demonstration. CPU: AMD K6/2 300.
plex86 with freedos guest: 250 sec.
bochs with freedos guest: 8 sec.
dosemu with freedos guest: 6.5 sec.
The read/write memory optimizations would only matter for Bochs at this
time: I think they would shave around 1.5-2 sec off the total. For
plex86 that's not noticeable at this point in time.
You cannot really just turn prescanning off for this kind of
code. Generating a page fault for each read/write in VGA memory is too
expensive as well. The fastest I know of is to emulate the CPU for a
while after a PF, what is what we're doing in dosemu: making it almost as
slow as Bochs for graphically intensive code. [for dosemu] We'll still
need to integrate this with Alberto Vignani's dynamic translation cpu
emulation however, which should speed things up.
Bart
