Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!convex!linac!att!cbfsb!cbnewsb.cb.att.com!feg
From: feg@cbnewsb.cb.att.com (forrest.e.gehrke)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Performance penalty from EMM386 ?!?!
Message-ID: <1991Jun28.122012.1030@cbfsb.att.com>
Date: 28 Jun 91 12:20:12 GMT
References: <1991Jun26.120951.18540@cbfsb.att.com> <1991Jun27.155203.3092@cpqhou.uucp>
Sender: news@cbfsb.att.com
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 29

In article <1991Jun27.155203.3092@cpqhou.uucp> randys@cpqhou.uucp (Randy Spurlock) writes:
>
>	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.


If you are right, then why are there such large differences between
the same program compiled by different compilers?

Using QEMM386 MSC v5.1 shows a 30% reduction in speed for floating 
point while their version 6.00a shows only 10%.  Their Alternate Flg.Pt. 
lib exhibits none at all, as does also Zortech's regular math lib.

There must be more to it than supplied by your explanation.

For any of my tests, QEMM showed far less slowdown than EMM386.
EMM386 is a disaster.  I am not happy with the slowdown seen
with QEMM but I will take that any day to EMM386.  Besides that
QEMM is much more versatile in poking stuff above 640KB.

-Forrest Gehrke feg\@dodger.att.com