forums.silverfrost.com

mecej4 · Joined: 31 Oct 2006 Posts: 1917

Curiouser and curiouser! Create a single file with the two subroutines in reverse order compared to your first version, and with SALFENVAR=MASK_UNDERFLOW set, no crash occurs.

DanRRight · Posted: Sat Feb 21, 2015 12:15 am Post subject:

Thanks, Mecej4, great, one more pretty subtle bug will be diagnozed by the compiler

mecej4 · Joined: 31 Oct 2006 Posts: 1917

Here is a short program, instrumented to measure the response time of the FTN95/SALFLLIBC.DLL underflow exception handler.

PaulLaidler · Posted: Sun Mar 01, 2015 10:03 am Post subject:

Try taking out the WRITE statements that are within the loop to see what effect this has on the underflow count.
It is possible that underflows are also occurring within the standard output.

mecej4 · Joined: 31 Oct 2006 Posts: 1917

Paul, I followed your suggestion, and did not see any change in the underflow counts reported by underflow_count@() with the WRITE statements commented out.

Let me also point out that the two statements that cause underflow are individually bracketed by calls to rdtsc(), so the RDTSC counts printed by the program do not cover any statements other than the two instances of dx = y - x .

By accident, I discovered something else that may help you with tracking down the speed issue: if the test program is compiled with /opt and run, the underflow count remains the same, but the cycle counts used up in underflow processing drop down from about 50000 (without /opt) to about 500 (with /opt) per underflow!

Earlier, when running John Campbell's much larger test code, I had always used /opt, and yet the underflow processing had consumed tens of of thousands of cycles per underflow. These conflicting findings cause me to wonder if, in compiling the larger and more complex code, there were instances of failure to optimize.

I will peek into the machine code generated with and without /opt to obtain some insight on what is happening, but I thought that I should let you know this strange fact without delay.

SDBG does not seem to support assembly level debugging, and the Registers display it can show is limited to CPU registers. On the other hand, debuggers such as WinDBG and the VS debugger do not understand the debug information provided by FTN95. Do you have any suggestions for resolving this?

PaulLaidler · Posted: Sun Mar 01, 2015 4:13 pm Post subject:

Thanks for the information.

SDBG did support assembly level debugging (F11) not long ago. I will log this as a regression and pass it on for investigation.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2623 Location: Sydney

For those who do not have access to the assembler compiler, the following provides a FTN95 interface to rdtsc.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2623 Location: Sydney

More twists in this FPE problem !
I changed the test to:

jalih · Joined: 30 Jul 2012 Posts: 196

PaulLaidler · Posted: Mon Mar 02, 2015 8:01 am Post subject:

For FTN95, the standard intrinsic SYSTEM_CLOCK is based on QueryPerformanceCounter() and QueryPerformanceFrequency().

mecej4

SDBG and function key F11 gives assembly level debugging on my machine but only when

a) running SDBG from a command line and
b) running SDBG from Plato but with the option "Integrate with SDBG" selected.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2623 Location: Sydney

Jalih,

I don't agree with your comment on RDTSC.
My understanding is that this gives a value of the system clock, which is based on a CPU clock rate. No other timer gives this precision.
While there can be all the problems of multi-threading and multiple cores, this is still a high precision time estimate.
Apart from QueryPerformanceCounter, most other windows timers are accurate to 1/64 second, which is much worse than any error that rdtsc may provide.
The big advantage of rdtsc is that it gives an estimate of cpu cycles.
On my pc, QueryPerformanceCounter is accurate to 2,728,242 ticks per second, which is about 1,000 CPU cycles. given it's problems, rdtsc is typically much better than this.

It would be good if there was an Integer*8 variant of CPU_CLOCK@, say CPU_CLOCK_TICK@, so that real*10 conversion was not required and minimise the call overhead.
My estimate is that cpu_clock@ has about a 50 cpu cycle overhead, while QueryPerformanceCounter is about 200 cpu cycles. ( Gettickcount has a lower overhead, but the answer is to 1/64 seconds. )

John

jalih · Joined: 30 Jul 2012 Posts: 196

JohnCampbell · Joined: 16 Feb 2006 Posts: 2623 Location: Sydney

Jalih,

Yes, it is not that easy. Depending on what problems you are prepared to ignore, you may need a different clock. Unfortunately most of the other timers have very poor precision. I have always found the lack of precision of most alternatives to be the biggest problem. There is a lot of activity that can occur in .015 seconds.

John

mecej4 · Joined: 31 Oct 2006 Posts: 1917

As far as the small test program is concerned, I do not think that we really care to time it accurately. It is enough to use some measure of the CPU cycles that get consumed when two numbers are loaded from memory into the X87 registers, the difference taken, and the result saved back to memory. Secondly, we are interested in how this measure, however approximate it may be or related to a non-constant rate clock, comes out for two event sequences : (i) load, subtract, store, measure dt when no underflow occurs, (ii) the same, when an FPU underflow exception handler is invoked.

The assembler code segment is as follows, where I have added numbers to indicate the instruction latency for a Haswell CPU:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2623 Location: Sydney

mecej4,

Try the adaptation I provided in the post above on Mon Mar 02, 2015 12:11 am.
Using the .bat file, I get different FPE cycle delay estimates, depending on the compile options.