Date: Tue, 8 Sep 1998 15:57:22 +0300 (IDT) From: Eli Zaretskii To: Tal Lavi 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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 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.