Path: 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

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