Hi Z, > This time I would compare, how much CPU time will my "toy program" > need on different machines. I would to make it show, how many percent > of CPU time was needed, if this can be possible.
For total runtime, you could do RUNTIME YOURPROGRAM at the prompt... > > Why? Because I'm not going to make it "as fast as possible" - max. 50 > frames per second will do, and there's no need for more - but still That is an interesting question! FDAPM is pretty useless for it ;-) Instead, you could do as many other graphical programs: Add some benchmark mode where you make as many frames as possible, instead of waiting until the next screen refresh signal from the graphics card as in normal mode. For the user, it does not make sense to calculate more than one frame each time a frame is sent from the graphics card to the screen and actually it looks better to just wait and sync screen refresh with calculations as you know... But for benchmarking, you simply send a new frame of graphics as soon as you are done, and usually show a count of how many frames you were able to send the last second, an easy, useful speed test :-) Of course you said you do NOT want to make as fast as possible the normal mode of operation of your program. Still it might be good enough for load measurement. If you want REAL load measurement in NORMAL mode of your program, you would typically use a high speed clock, check how many milliseconds each graphics card frame stays on the display, and measure how many milliseconds before the next frame has to be ready you are done and how many milliseconds you were actually busy calculating the next frame :-) DJGPP has good support high resolution wall time: roughly microsecond resolution and normal timer chip based (as recently mentioned in this list). You can also use the TimeStampCounter of modern CPU, where modern is a very relative term. If a CPU has a few 100 MHz, it probably already has this counter. Sometimes it is throttled along with a power saving system as ACPI throttle or HLT, but I would say many CPUs explicitly take care to keep the TSC at fixed speed and you can always disable power saving to see if it makes a difference. You could check my NEWTRACK eyetracking software for a bit of C & inline assembly code for DJGPP to check if a TSC is available and to get a microsecond wall time. If there is no TSC, it just does: #include "time.h" uclock_t uclock_time = uclock (); unsigned int tsc_lo = uclock_time & 0xffffffff; unsigned int tsc_hi = uclock_time >> 32; return (unsigned int) ( (uclock () * (uclock_t)1000000) / UCLOCKS_PER_SEC ); If a TSC is available, it does, simplified: > __asm__ ( /* opcode is 0f 31 */ > "rdtsc" /* read 64bit CPU cycle count EDX:EAX */ > : "=a" (tsc_lo), "=d" (tsc_hi) /* returns EAX and EDX */ > : /* no inputs */ > /* modifies nothing except ret. values */ > ); and then divides the 64 bit count by the CPU clock in MHz. Actually my source code is pretty long because I also check for the presence of TSC and calibrate it to CPU frequency by doing two measurements with a one second CMOS time based wait between them and so on. Also the TSC division by clock speed is done in Assembly, which gives you a 32 bit result instead of the clumsy 2 x 32 bit value as which you get the 64 bit RDTSC output :-) Unfortunately, auersoft.eu is down (again...) so you cannot download NEWTRACK there. Mail me to get a ZIP. Eric ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Freedos-user mailing list Freedosfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/freedos-user