Date:	Tue, 8 Sep 1998 15:57:22 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Tal Lavi <ranla AT post DOT tau DOT ac DOT il>
cc:	djgpp AT delorie DOT com
Subject:	Re: MAJOR slowdowns in translating TP7 gfx code to DJGPP2: Suplement
In-Reply-To:	<35F54641.14B6@post.tau.ac.il>
Message-ID:	<Pine.SUN.3.91.980908154235.28002B-100000@is>
MIME-Version:	1.0

On Tue, 8 Sep 1998, Tal Lavi wrote:

> The profiler says that __dpmi_int was used allot, but i swear I haven't
> put even one in the actual run-time part!

Read section 13.5 of the DJGPP FAQ list, it explains that `__dpmi_int' is
called by every low-level library function that calls either DOS or 
BIOS.  So if you use, e.g., `printf' or `getc', `__dpmi_int' gets linked 
into your program and gets called.

> Alas, the profiler won't tell me from which function was the
> _dpmi_int(s) was called. 
> Does anyone knows whether getch() or _far* calls __dpmi_int?

Use the sources.  v2/djlsr201.zip is the file with all the library 
sources.  Download it, and you can answer such questions yourself.

_far* functions never call any other functions, they expand into 2-3 
inline assembly instructions that access a memory address (see 
<sys/farptr.h> header file, it's all there).

`getch' calls DOS, so it calls `__dpmi_int', as explained above.  If your
program calls `getch' to read user's input, your profile will be totally
skewed because a normal human reaction to interactive prompts is so slow
that it will shadow the time spent in other functions.  Replace `getch'
with a stub that feeds the program with some input, and then profile it
again.  Only then will you see the real picture. 

> And yet another thing, the div function in stdlib.h takes allot of 
> computation time too! I only do two division with it per loop cicle!!!
> what's wrong with that picture?!? 

How many times does `div' get called (it's in the profile)?  Post here 
how much time PER CALL does `div' take, and then we can discuss is 
something's wrong with that.  For all I know, you could call it 
gazillions of times.

Why do you need `div', anyway?  Are you sure you can get away with simple 
32-bit division?

> div is a integer based division, right?

Yes.

> then why does it take over 40% of the computation time?

The interesting thing is how much time per call does it take.  And then 
we need to know what kind of CPU do you have.

> I'de like to try to inline my putpixel routine myself, instead of using
> _far* but I can't get it to work!

This is dead end.  _farptr functions are already written in inline
assembly, and they are as fast as you can get (you *did* compile with -O2,
did you?), so you won't find any faster way of doing that part.  _farptr
is NOT your problem, look for the reasons of the slow-down elsewhere. 

- Raw text -