[quote] REM Work out the CPU clock frequency. REM Unfortunately the RDTSC instruction won't run unless CPU is in REM protected mode or REAL mode so I need to run in either REAL mode or REM using a DOS Protected Mode Interface memory manager (as in Win9x/Win3.1. [/quote] If executed under a protected mode OS (i.e., under Windows), any test such as this one is destined to return inconsistent and unrealiable results, with the effort to disable interrupts probably reducing reliablility even further. [i]Only[/i] if attempted in real mode can truly reliable CPU benchmarking occur. In other words, simply achieving access to the time stamp counter is not enough. Moreover, reliable benchmarking requires attention to some other critically important issues (including the effects of the cache and data alignment), and the code presented here makes no provision for any of them. Just my unsolicited crabby thoughts.
[quote]why should the code return inconsistent results? Protected mode is NOT Windows, its a state of the CPU. Windows is a piece of software...[/quote] The simple answer is that, for a DOS app, Windows is not just a piece of software which happens to run in protected mode. (In the same way, the landlord who lives upstairs is not just a neighbor.) To point out only one fundamental issue, a DOS app cannot disable interrupts under Win32 in the same way that it can under DOS 6.x. The "try it and you'll see" method, despite its appeal, has to take second place to understanding the facts. Lots of good explanations of protected mode exist, as do explanations of DPMI and DOS apps when run inside a virtual machine under Win32. Barry Kauler's _Windows Assembly Language and Systems Programming_ is certainly thorough. [quote]As for 'reliable benchmarking', all I claim from this code is the correct CPU clock speed. Cache, memory, video etc. are all irrelevant as they do not alter the CPU clock.[/quote] And the CPU clock speed is being determined how? By timing a loop. The relevance of the cache and data alignment should be pretty obvious.
[quote]I believe I understand the facts in this case but I would say that the practical application of any method is more important than any underlying fact. Try it and see is the final proof of anything.[/quote] Faith in this approach makes unlikely the success of any explanation anyone might offer. 'Try it and see' reminds me of the shareware programmer who became notorious for antagonizing beta testers when they'd reports bugs. His response was invariably, 'Well, it runs fine on my system.' He had tried it and found it good. He also couldn't keep beta testers. Testing on one's own system is the logical, inevitable first step--and the last thing to rely on. Unless, of course, someone intends to create software exclusively for the system on which it's created. [quote]It's determined by a non-stoppable, non-resetable, read only counter implemented in hardware which counts CPU clock cycles since the last reset (called the Time Stamp Counter or TSC). Turn your cache off, align the code how you wish and run the test and you'll see that the code still works i.e. you get the correct CPU clock frequency to within a few ppm.[/quote] As I said, it's determined by timing a loop: ww: !call waitforrtc !dec cx !jnz ww Or, more accurately, by timing that relies on a loop to delay. However, and despite the danger of reinforcing the credibility of flawed methodology, I tried it. An AMD K6-2/266 on a Win95a system reports a speed of 267Mz. An AMD K6-3/400 running Win98SE reports a speed of 401Mz. Both tests were run for the suggested 10 seconds. Repeated runs also returned varying results--"within a few ppm." A third test, of an IBM ThinkPad with a Pentium 100 (and running Win95a), resulted in a solid lockup of the system. I have no intention of wasting time by trying to figure out why the P100 system reacted as it did. I could have tested 20 systems and found nothing wrong, but those results would not change the facts, as unpleasant as those facts might be. The approach taken in the posted code is flawed.
Tweet
Comment