Sender: "Rolf Campbell" <cp1v45 AT nortelnetworks DOT com>
Message-ID: <376E4264.9812134D@americasm01.nt.com>
Date: Mon, 21 Jun 1999 09:47:16 -0400
From: "Rolf Campbell" <cp1v45 AT nortelnetworks DOT com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp AT delorie DOT com
Subject: Re: [AL] Compilers comparisson, some opinions about the generated , 
         assembler
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990620104256 DOT 16821G-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:

> On Thu, 17 Jun 1999, Rolf Campbell wrote:
> >     I suspect it's the windows DPMI stuff, and in general, all vm interupts.
> I would like to see some hard evidence before I believe in this.  Most
> of the jobs I was talking about don't do anything of the above too
> much.  They don't launch too many sub-programs, they don't call sbrk
> too much, and they certainly don't enable/disable interrupts.

    It was just speculation..., but even text output uses interrupts.  It being
buffered makes it more stable, but this could account for part of the difference.
I don't think it should have more than a +-7% effect <wild geuss>, but it should
have something.

> > When I ran it in real DOS with the same input file, it
> > always ended up taking the exact same amount of time.  Under W95, not only
> > was it running at 10-30% slower, but it would vary greatly from one moment to
> > another.  I would run it twice in a row, and one would be 9.8 seconds, the
> > other would be 7.6 seconds.
> This probably means that your DOS configuration didn't have any disk
> cache, or its cache was too small.  I always get shorter times when I
> run a disk-bound program the second time, both in DOS and in Windows.
> Sometimes the difference is 10-fold, it really depends how large is
> the file that the program reads.

    I was running without any disk-cache in DOS.  And I understand how a program
can speed up under a cacheing system the 2nd time it runs, but I'm fairly
confident that the file i/o wasn't the bottle-neck (I profiled it).  And it wasn't
just the first couple of times that it changed speeds, it was constantly changing
speeds under Win95 (the 10th time was distinctly different than the 11th and
12th).

--
     -Rolf Campbell (39)3-6318