www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/08/12/21:16:26

Subject: Re: Speed tuning programs
To: olly AT mantis DOT co DOT uk (Olly Betts)
Date: Fri, 12 Aug 1994 17:06:08 -0600 (CDT)
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
From: mcastle AT umr DOT edu (Mike Castle)

Amazingly enough Olly Betts said:
> The machine is a 486DX2, 66MHz, and I repeated each run until the time
> was repeated three times, to allow for the HDD card caching stuff.  The
> tests were done in a full screen DOS box in Windows.  The machine has
> 32Mb of RAM, so no swapping (hopefully).  Unfortunately, I don't have a
> larger input data set handy, but the timings on this one are fairly
> constant on repeat runs.
> 
> I read a message on this list suggesting that DJGPP is a bit weak if
> you're doing lots of I/O stuff, due to real/protected mode switching or
> something.  The program does read and write in a fair amount of data, so
> this may have a bearing.

If the amount of CPU time grows faster than the amount of I/O
time, I suspect that the DJGPP version will eventually out
perform the Borland version.  

> What I'd like are any tips or suggestions for tweaking the performance
> of the DJGPP code to make it closer to the BCC code.  Either compiler
> options or coding suggestions.  As things stand, I'm currently supplying
> both executables and suggesting folk use the DJGPP one if they need more
> memory.

Have you tried profiling (with either version) to find bottle
necks?  How centralizing is your IO?  Do you read everything in
at once, then process, or read/process/write/read/process/write?

If you could work the IO into larger chunks so there are fewer
RM/PM switches, that might help the djgpp version.

Another thing to consider is the start up.  For DJGPP programs,
you have a slightly larger overhead than Borland programs would
(initializing PM, loading the 32-bit code, jumping to it, and so
on).  Did you time with an external program, or an internal
function?

Try timing with an internal function.  Something along the lines
of:


int starttime;
main() {
  atexit(stoptimer());
  starttimer();
  
 ... your code ...
}

void stoptimer() {
  printf("time was %d seconds\n", time(NULL)-starttime);
}

void starttimer() {
  starttime=time(NULL);
}




Just off the top of my head.... might want to replace with more
precise time calls.

This would time just your code actually takes to run, and might
give a better feel for how the program would scale (the start up
time shouldn't change).

mrc


void starttime() {
  
> 
> Cheers,
> Olly
> 


-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle AT cs DOT umr DOT edu     and be right all the time, or not work at all
   mcastle AT umr DOT edu       and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019