Re: [Freedos-user] A tool for CPU-load measurement

[Eric A. <e....@jp...>]

Hi Z!

I like the idea from TJ Edmister with the background change as
easy to implement and easy to eyeball visual feedback of load,
but let me tell you an anecdote: Once I upgraded from a 386 to
a 6x86 CPU, but had no new VGA card yet. I played with an old
Mandelbrot set program and was surprised that recompiling with
floating point made little difference on the new CPU. But then
I realized that the EGA card, running on ISA bus might be the
bottleneck and indeed: Commenting out the code which SHOWS the
Mandelbrot set, I could indeed measure that CALCULATING it was
a lot faster in floating point than in fixed point compile :-)

Likewise, you could comment out parts of your fun project app,
even if it makes the graphics look bad, just for the "fun" of
knowing which parts take most of the graphics generation time.



> but being able to detect instantly the weak place in program, which is
> causing unnecessarily high CPU load (say: looping for a key without
> any "pause 10 ms"), is the other useful thing. Then actually I'm...

In DOS, you would probably only notice due to high CPU heat output.
Because when you press the key, even the weak program still reacts
immediately and most users are still happy.

You could use some advanced cache statistics to see which parts of
the program are accessed most often, some CPUs have very CPU model
specific functionality for that sort of stuff. Also, you could try
some interrupt counting TSR to see what is called how often, maybe
Rugxulo knows one. Plus of course if you have the SOURCE of a weak
program, or at least a binary debugging symbols, you can "profile"
it: e.g. in Java, you let the program run and tell the Java profile
function to check every X msec what your program is doing, by doing
a snapshot of the current call stack. Gives nice useful stats, and
you see which subroutines are active most of the time you look. You
can also profile by counting EACH call, instead of looking every X
milliseconds, but that makes the to-be-profiled program very slow.

Of course it is true that you cannot formally predict where slower
parts are, but I think running the program to measure is also nice.

Eric