Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Newsgroups: comp.os.msdos.desqview
Subject: Re: Qemm slows floating point
Keywords: Any solution?
Message-ID: <1991May14.142323.1929@maytag.waterloo.edu>
Date: 14 May 91 14:23:23 GMT
References: <1991May14.123233.17734@cbfsb.att.com>
Sender: news@maytag.waterloo.edu (News Owner)
Distribution: na
Organization: University of Waterloo
Lines: 41

In article <1991May14.123233.17734@cbfsb.att.com> feg@cbnewsb.cb.att.com (forrest.e.gehrke) writes:
>I have a Gateway 386/33 with Micronics Asic motherboard
>and no coprocessor.  4MB ram, 32 ram cache.
>
>When I load qemm.sys and run a Whetstone benchmark (or any
>floating point operations program), I find that there is
>about a 30% reduction in speed.  This occurs even with 
>no features of qemm in use, i.e. merely loading qemm.sys
>with the line   device=c:\qemm.sys with no other parameters
>in the config.sys file, and no programs loaded into
>high memory.
...
>I can not envision any reason for these results unless
>QEMM inserts useless code to be executed when floating
>point operations are involved.  The same QAPLUS includes
>the Dhrystone benchmark; there is no difference in its
>report with or without QEMM.SYS loaded.
>
>Has anyone else noticed this?  Is there a solution
>for it?

I haven't noticed it, but haven't done any tests.  Here's a guess at why
it's happening:  

Most compilers use interrupt calls in place of each floating point instruction
to jump to the emulator when there's no FPU installed.  (Borland's TP does
this on the first call whether the emulator is installed or not; MS languages
seem to do it on the first call only if there's an emulator there.  Both
of them patch the code back to a FPU instruction if there's an '87 there, so
you only execute the interrupt once.)

QEMM runs the 386 in protected mode, with your session running in V86
mode.  I don't have 386 timings handy, but I think the INT instruction is
much slower in V86 mode than in real mode.

So it appears the only solution is to buy a 387 - then your program will
be slower on the first pass through each instruction, but will go full
speed after that.

Duncan Murdoch
dmurdoch@watstat.waterloo.edu