Re: [Freedos-user] A tool for CPU-load measurement
Hi, some interrupt counting TSR to see what is called how often, maybe Rugxulo knows one. There are various tools (Trace, UI21DEB, KGB, Argus) that work in limited situations, or presumably you could also just run through an emulator with built-in debugger (BOCHS? DOSBox?). I don't know... In Linux, the easy choice is dosemu: It has command line options to enable interrupt logging, a number of categories are available for that and you can even switch logging on the fly when you open the dosemu debugger dosdebug (in a separate window on your Linux). 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
Re: [Freedos-user] A tool for CPU-load measurement
Hi, On Thu, Mar 29, 2012 at 3:03 PM, Eric Auer e.a...@jpberlin.de wrote: 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. There are various tools (Trace, UI21DEB, KGB, Argus) that work in limited situations, or presumably you could also just run through an emulator with built-in debugger (BOCHS? DOSBox?). I don't know, it's a tricky situation because apps tend to be quite complex and don't always interact well in weird situations (e.g. under a debugger). Though who knows, perhaps 386SWAT could handle it.;-) I just stumbled upon this TSR, Dostap, but I didn't try it. Though it has sources (MS C + MASM) but isn't redistributable except by them (eh?). It's fairly old, circa 1996, so maybe one of you could *nicely* ask them to GPL it or some such. It's meant to lure you to port to their proprietary (embedded?) software. ( support _AT_ smxrtos _DOT_ com ) http://www.smxrtos.com/demo/dostap.zip DOStap (DOS BIOS interrupt logging program) 68K (multiple files, compressed) This TSR will unobtrusively log the DOS BIOS calls that your program makes. With the list produced, you will see which calls will need to be emulated if DOS is removed from your system (such as when moving to protected mode). Check the list in the unDOS documentation to see what calls we already have emulated. This program is supplied free of charge to prospects considering purchasing unDOS and is not to be distributed, except by Micro Digital. -- 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
Re: [Freedos-user] A tool for CPU-load measurement
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 -- 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
Re: [Freedos-user] A tool for CPU-load measurement
Hi Zbigniew, There are various tools for Windows/Linux, which can display actual CPU workload. Since DOS doesn't do multitasking, my guess is, that here external utility won't be of any use. But DOS-program... Actually you can use FDAPM for that: While the APMDOS function is active, FDAPM keeps MSDOS POWER compatible statistics of which percentage of the timer tick time slices contains signs of DOS and the apps being idle. In such situations, the cpu is halted with HLT and/or BIOS APM calls until the next IRQ (next timer tick or any other IRQ based event that happens eariler). There is no measurement of whether the next IRQ is from the timer and no measurement of how much of the time slice elapsed until DOS went idle, but the statistics still are pretty useful to get an idea :-) If your programs behave do everything as fast as possible even if there is nothing to do, FDAPM will believe that your CPU is 100% busy, but most programs do use FDAPM-visible idle by for example waiting for the next keypress if there is nothing else to do. I remember that EDIT needed a small patch long ago to help FDAPM and that SSH2DOS is one of the examples of invisibly idle programs, as the waiting for network activity state is not recognized as a state of boredom by FDAPM :-) 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
Re: [Freedos-user] A tool for CPU-load measurement
2012/3/28, Eric Auer e.a...@jpberlin.de: Actually you can use FDAPM for that: While the APMDOS function is active, FDAPM keeps MSDOS POWER compatible statistics of which percentage of the timer tick time slices contains signs of DOS and the apps being idle. In such situations, the cpu is halted with HLT and/or BIOS APM calls until the next IRQ (next timer tick or any other IRQ based event that happens eariler). [..] Never before did anything like that. If/when you'll find some free time, maybe could you, please, paste some example procedure - can be in plain C (KR, rather not C++)? Could be also assembler, if it can be better fit. I would to use such module in my DX-Forth exercises, since it'll give me information, is my program about optimal, or in a need for further polishment. -- Z. -- 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
Re: [Freedos-user] A tool for CPU-load measurement
On Wed, Mar 28, 2012 at 5:21 PM, Zbigniew zbigniew2...@gmail.com wrote: There are various tools for Windows/Linux, which can display actual CPU workload. Since DOS doesn't do multitasking, my guess is, that here external utility won't be of any use. But DOS-program could have it built-in. Could someone tell me the basic algorithm, which could be used in DOS applications, to build such CPU-load-display directly into program? While it *can* be done, I'm not sure why you want to. On a multi-tasking OS like Windows or Linux, I'll use Process Explorer (Win) or top (Linux), to get an idea of which programs are hitting the CPU. But I'm usually interested in more than CPU load. Most PCs are I/O bound, not compute bound, and the CPU spends a lot of time in an idle loop waiting on something. For a DOS program where I was concerned in getting the maximum performance, I'd probably insert profiling code to see just where the CPU was spending its time to optimize critical parts, but that would generate an after run report, not a real-time display. I'm not sure what the value of a real-time display of CPU load on a DOS app would be. It actually *is* possible to get DOS to multi-task. The PRINT command did that to create a background print spooler, so you could send a job to the printer and not have to wait till it finished printing to return to your program. PRINT installed as a resident extension to DOS and grabbed CPU cycles from the foreground task to handle the spooling. (I ran the MKS Toolkit, which provided a Unix like environment, and used MKS Korn shell aliases to fake the Unix lp command using PRINT.) Programmers reverse engineering what MS had done created the whole TSR mini-industry. Z. __ Dennis https://plus.google.com/u/0/105128793974319004519 -- 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
Re: [Freedos-user] A tool for CPU-load measurement
Hi Zbigniew, Actually you can use FDAPM for that: While the APMDOS function is active, FDAPM keeps MSDOS POWER compatible statistics of which percentage of the timer tick... You do not have to explicitly program anything for this: Just run FDAPM APMDOS at some time, e.g. in your autoexec and then run FDAPM STATS to see how much of the time the CPU was idle - to be exact, which percentage of the time slices contained any idle time, so idle-ness is always over-estimated. Example: C:\fdapm stats Performing action: STATS Found resident FDAPM / POWER driver version 1.0 Savings mode: BIOS APM plus interrupt hooks (MAX setting) CPU was idle 99% of the time So just getting the answer to how much of the time was the CPU idle since I loaded FDAPM by typing a command at the prompt is very easy. But you say that you wanted to display real-time information about how busy you are inside your program. For that, you can add some queries to FDAPM to your app. A good example would be a game as Chess or Go: Sometimes you do heavy calculations, while at other times, your software just sits there and waits for the player to make the next move. You could display information about this as part of the game... If you want, you can also query the stats in your apps: 1. set ax=5400h, bx=0, call int 2f, check if bx is 504dh on return. If yet, FDAPM, POWER or similar are running. 2. set ax=5401h, bh=0, call int 2f, check if (ax3) 0 to see if ... is in a state where idle stats do matter. 3. now that you know that FDAPM or similar is active and updating statistics, you can start polling them for some sort of display inside your program - although I do not know what type of program you are planning to write, it is possible that it will be idle so often on modern CPU that displaying the load is not even worth the effort. In the example of the Chess or Go game, your game could easily display a RED OR GREEN BOX for is busy thinking about the next move versus is bored - waiting for the next human move because CPU load is always either NONE or FULL 100%. In this situation, FDAPM statistics would be only interesting to show how much of the time since the start of the current ROUND the CPU was busy, versus how much of the time the CPU waited for the player, not which percentage the last SECOND the game was busy :-) Set ax=5481h, bx=0, cx=1ch, dx:si=pointer to a buffer of seven 32bit long ints size, call int 2f, now if ax is returned as 0 (okay) your buffer array will contain the values, in this order: - total number of timer ticks (time slices) counted - number of timer ticks containing idleness - (number of idle calls) - (int 2f idle ticks: triggered by command.com waiting) - (int 28 idle ticks: official DOS idle state call...) - (int 16 idle ticks: idle while waiting for keypress) - (int 2a idle ticks: network related keypress idle) The easiest idea is probably to make a snapshot of the first two array items, wait until total number of timer ticks (FDAPM uptime, you could say) grew by, say, 100 (which takes a bit more than 5 seconds) and then display an indication of how much number of ticks ... idleness has grown in the same time (in my example, it would grow by at most 100 because you waited 100 ticks of uptime). If you want to update your load info display more often you can of course only reach smaller counts of idleness in the same time and your display would jump in steps of multiple percent as smallest measurable load difference. The other way round, in the Chess or Go game, you might want to display thinking TIME per game, not percentage, so you only snapshot once when a game starts, then show total times after each turn, instead of per second load. I hope this gives you an idea to get you started. Maybe you could tell more about your project :-) 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
Re: [Freedos-user] A tool for CPU-load measurement
2012/3/28, dmccunney dennis.mccun...@gmail.com: While it *can* be done, I'm not sure why you want to. On a multi-tasking OS like Windows or Linux, I'll use Process Explorer (Win) or top (Linux), to get an idea of which programs are hitting the CPU. 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. 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 I'm interested, how much processing power it'll need to achieve these 50 frames. And how much will be still left for me (DX-Forth has multitasking support). I would to test it on my Sempron 2 GHz, and on... very old 386SX25. But I'm usually interested in more than CPU load. Most PCs are I/O bound, not compute bound, and the CPU spends a lot of time in an idle loop waiting on something. You're right - but I've got to start with just something, and it can be then developed further. -- Z. -- 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
Re: [Freedos-user] A tool for CPU-load measurement
2012/3/28, Eric Auer e.a...@jpberlin.de: You do not have to explicitly program anything for this: Just run FDAPM APMDOS at some time, e.g. in your autoexec and then run FDAPM STATS to see how much of the time the CPU was idle - to be exact, which percentage of the time slices contained any idle time, so idle-ness is always over-estimated. Example: C:\fdapm stats Performing action: STATS Found resident FDAPM / POWER driver version 1.0 Savings mode: BIOS APM plus interrupt hooks (MAX setting) CPU was idle 99% of the time Thanks, it's worthy to know it - but... So just getting the answer to how much of the time was the CPU idle since I loaded FDAPM by typing a command at the prompt is very easy. But you say that you wanted to display real-time information about how busy you are inside your program. ...yes, that's the thing I'm looking for in this particular case. For that, you can add some queries to FDAPM to your app. A good example would be a game as Chess or Go: Sometimes you do heavy calculations, while at other times, your software just sits there and waits for the player to make the next move. You could display information about this as part of the game... If you want, you can also query the stats in your apps: [..] Thanks: I'll start with your clues. Fortunately, every Forth has assembler built-in. Maybe you could tell more about your project :-) Well, this time it'll be just Forth programming exercise. DX-Forth has BGI graphics driver, and I'm going - as weekend fun project - to translate Polyhedra script ( http://wiki.tcl.tk/14283 ) from TCL into Forth. Of course it has to be done smart way - not mechanical, direct translation. I'm curious, whether am I able to create s.c. good Forth code. ;) Hope weekend will be enough for this. -- Z. -- 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
Re: [Freedos-user] A tool for CPU-load measurement
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 0x; unsigned int tsc_hi = uclock_time 32; return (unsigned int) ( (uclock () * (uclock_t)100) / 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
Re: [Freedos-user] A tool for CPU-load measurement
You know: graphics is one thing - this is just actual fun project - 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 looking for something of more general nature, that can be then used also in program, that has quite nothing to do with graphics. -- Z. -- 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
Re: [Freedos-user] A tool for CPU-load measurement
On Wed, 2012-03-28 at 23:27 +, Zbigniew wrote: You know: graphics is one thing - this is just actual fun project - 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 looking for something of more general nature, that can be then used also in program, that has quite nothing to do with graphics. WARNING, you can't write a program that takes another arbitrary program as input and tells you whether or not it halts. This is called the halting problem. As far as loop troubleshooting, you may want to use another OS and a debugger to write your program. If the language is truly portable, you should be able to take your debugged program and compile or interpret it in Freedos. Since Freedos probably doesn't protect memory, programming in an environment that does is most likely a good idea. -- 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
Re: [Freedos-user] A tool for CPU-load measurement
On Wed, 28 Mar 2012 18:33:42 -0400, Zbigniew zbigniew2...@gmail.com wrote: 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. 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 I'm interested, how much processing power it'll need to achieve these 50 frames. And how much will be still left for me (DX-Forth has multitasking support). I would to test it on my Sempron 2 GHz, and on... very old 386SX25. Is your screen update syncronized with the monitor`s vertical retrace? There is an old trick for CPU load measurement in video game development where you change the screen`s background color after processing for that frame, and reset it at the beginning of the next frame. So when you run the program, and see that the color changes half-way down the screen, then you know that the CPU was busy for the first half of the frame until it caught up with the CRT beam and then it was idle for the remaining time. (you don`t actually need a CRT, as the video card timing will be the same even if the signal is actually going to an LCD) -- 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
