Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!uunet!cpqhou!randys
From: randys@cpqhou.uucp (Randy Spurlock)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Performance penalty from EMM386 ?!?!
Message-ID: <1991Jun27.155203.3092@cpqhou.uucp>
Date: 27 Jun 91 15:52:03 GMT
References: <1991Jun26.120951.18540@cbfsb.att.com>
Organization: Compaq Computer Corporation
Lines: 62

in article <1991Jun26.120951.18540@cbfsb.att.com>, feg@cbnewsb.cb.att.com (forrest.e.gehrke) says:
> 
>>     ***** Program Description Deleted *****
>>
>>When I run this simulation without EMM386.SYS installed, it blazes.  When I
>>install EMM386.SYS with the noems switch, it crawls. We're talking 45 secs
>>versus 20 seconds for a typical run; this is no quibbling about a few
>>percent.
> 
> 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.
> 
> If you can compile your program with MSC, try their Alternate Floating
> Point emulator, you will encounter no slowdown with it, but with
> less accuracy.  This applies only to floating point emulation.  
> If you had a coprocessor, you would not see any slowdown, but display 
> writing would still be affected.
> 
> 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.
> 
> These results appear to point to the compilers introducing a problem
> in programs when working with expanded memory managers, and not to the
> expanded managers themselves.
> 
> -Forrest Gehrke feg\@dodger.att.com

	The problem lies with the EMM386 and not the compiler. The 386
	expanded memory managers perform their magic via the 386 virutal
	paged mode. This mode allows 8086 real mode emulation with paging
	to map physical memory into different positions in the logical
	address space. This is all very neat stuff...but there is one
	side effect from running in the virtual 8086 mode. Software
	interrupts, i.e. BIOS interrupts, floating-point emulation packages,
	etc. all get trapped and vectored to a "virtual" mode interrupt
	handler who has to direct the interrupt to the correct "real mode"
	handler. All of this "handling" takes time and depending upon
	how the EMS manager software was written this can result in a 
	slowdown of anywhere from 10 to 50%. Also the video can be affected
	because some of the video BIOS routines make nested BIOS calls,
	i.e. more software interrupts that take even more time. I don't
	like the slow down but given the choice between EMS and no EMS,
	I'll take the slow down every time.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
          - Randy Spurlock -	      |      Compaq Computer Corporation    
---------------------------------------------------------------------------
These opinions are mine...all mine... | He fired his hyper-jets and...  
just ask anyone who's heard them!     | blasted into the 5th dimension!
--------------------------------------| 
UUCP: ...!uunet!cpqhou!randys         |                     Space Man Spiff
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=