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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to