Mail Archives: djgpp/1998/09/08/09:01:33
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 -