Article View: comp.os.msdos.programmer
Article #7379Re: Performance penalty from EMM386 ?!?!
From: Ralf Brown
Date: Thu, 27 Jun 1991 16:08
Date: Thu, 27 Jun 1991 16:08
43 lines
2703 bytes
2703 bytes
In article <1991Jun26.120951.18540@cbfsb.att.com> feg@cbnewsb.cb.att.com (forrest.e.gehrke) writes:
}Having spent several hours trying to get HIMEM.SYS and EMM386.SYS to
}give me as much usable low memory as QEMM386 does (both with dos=high)
}and, BTW I nearly got there-600KB vs 632KB, I can confirm the big
}slowdown you encountered. Not only does floating point emulation
}take a big hit but so does display writing--something of the order
}of 50%.
}
}QEMM also encounters this problem but not nearly to this extent--about
}10 to 15% when using programs compiled with MSC or Borland's C.
A slight slowdown is to be expected when running in virtual-86 mode
(as all 386 memory managers do when providing EMS). In V86 mode, *any*
interrupt kicks the processor into full protected mode. The memory
manager then has to mess with the V86 stack and simulate a real-mode
interrupt by reading the real-mode interrupt vector table and dropping
back into V86 mode. On return, the processor gets kicked back into
protected mode, the memory manager messes with the real-mode stack again,
and finally returns to V86 mode for a second time to complete the
program's interrupt call. QEMM does all of that much faster than EMM386--
Manifest reports that the timer interrupt latency is on average five
times as high for EMM386 as for QEMM; comparing worst cases for the two
yields a factor of *twelve*. It can take over TWO MILLISECONDS for
Manifest to get control once the clock interrupt is invoked, when running
under EMM386 on my 386/33.
}Tests I have done with floating point programs compiled with the
}Zortech v2.1 C compiler show no slowdown with their emulator when
}using expanded memory managers, but their emulator is much slower
}to begin with.
No slowdown probably means it uses calls rather than interrupts.
Please excuse any garbage, I hit a really trashy line this time.
--
{backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/53
BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask
DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's
I claim something?| what we know that ain't so. --Will Rogers
Technical Details
Message-ID:
<13664@pt.cs.cmu.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!europa.asd.contel.com!gatech!udel!rochester!pt.cs.cmu.edu!ralfReferences:
<6455@tellab5.tellabs.com> <1991Jun26.120951.18540@cbfsb.att.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!europa.asd.contel.com!gatech!udel!rochester!pt.cs.cmu.edu!ralf From: ralf+@cs.cmu.edu (Ralf Brown) Newsgroups: comp.os.msdos.programmer Subject: Re: Performance penalty from EMM386 ?!?! Message-ID: <13664@pt.cs.cmu.edu> Date: 27 Jun 91 16:08:50 GMT References: <6455@tellab5.tellabs.com> <1991Jun26.120951.18540@cbfsb.att.com> Organization: School of Computer Science, Carnegie Mellon Lines: 43