DISKIO - Dhrystone benchmark calc

[Dariusz Piatkowski]

OK, so DISKIO, the continuing mission to boldly go where I haven't gone before! LOL

Working through what seems like funny results, outcomes that change based on duration of the test, which to me implies an overflow.

In the case of the Dhrystone benchmark for the CPU, here is the pertinent section of the code:

Code: [Select]

...
void run_dhrystone (void)
{
   long lDhryTime = dhry_stone ();

   /* originally, time is measured in ms */
   lDhryTime = (lDhryTime + 5) / 10;
   /* now it is in units of 10 ms */

   if (lDhryTime == 0)
      lDhryTime = 1; /* if less than 10 ms, then assume at least 10 ms */

   /* now calculate runs per second */
   ulDhryStones = Number_Of_Runs * 100 / lDhryTime;
   /* by the time we cross 20 million dhrystones per second with a CPU,
      we will hopefully have only 64-bit machines to run this on ... */

   #ifdef DEBUG
      printf("\n DEBUG => lDhryTime      is: %ld", lDhryTime);
      printf("\n DEBUG => Number_Of_runs is: %lu", Number_Of_Runs);
      printf("\n DEBUG => ulDhryStones   is: %lld", ulDhryStones);

      printf("\n\n DEBUG => ULONG size     is: %d\n", sizeof(ULONG));
      printf(" DEBUG => ULONG bit size is: %d\n", sizeof(ULONG) * CHAR_BIT);

      printf("\n DEBUG => LONG LONG size     is: %d\n", sizeof(long long));
      printf(" DEBUG => LONG LONG bit size is: %d\n", sizeof(long long) * CHAR_BIT);
   #endif /* DEBUG */
   
} // end of run_dhrystone
...

...and what I'm seeing is the following weird situation:

1) t=5 secs

Code: [Select]

Dhrystone benchmark for this CPU:
 DEBUG => lDhryTime      is: 502
 DEBUG => Number_Of_runs is: 31084783
 DEBUG => ulDhryStones   is: 6192187    6192187 runs/sec

 DEBUG => ULONG size     is: 4
 DEBUG => ULONG bit size is: 32

 DEBUG => LONG LONG size     is: 8
 DEBUG => LONG LONG bit size is: 64

2) t=7 secs

Code: [Select]

Dhrystone benchmark for this CPU:
 DEBUG => lDhryTime      is: 1003
 DEBUG => Number_Of_runs is: 65230248
 DEBUG => ulDhryStones   is: 2221393    2221393 runs/sec

 DEBUG => ULONG size     is: 4
 DEBUG => ULONG bit size is: 32

 DEBUG => LONG LONG size     is: 8
 DEBUG => LONG LONG bit size is: 64

Clearly, the result for t=7 secs is wrong.

ulDhryStones is defined as 'long long', was originally 'ULONG' but it looked like it was overflowing so I changed it to 'long long', but that's still not big enough.

So this is the weird part (to me anyways), long long is a substantial –9,223,372,036,854,775,807 to 9,223,372,036,854,775,807, so why am I seeing this? Is my printf use of '%lld' incorrect?

[Andi B.]

Code: [Select]

Is my printf use of '%lld' incorrect?Which compiler? You don't get any warning when compiling with -Wall?

[KO Myung-Hun]

Hi/2.

How about changing

   /* now calculate runs per second */
   ulDhryStones = Number_Of_Runs * 100 / lDhryTime;

to

   /* now calculate runs per second */
   ulDhryStones = (long long)Number_Of_Runs * 100 / lDhryTime;

or

   /* now calculate runs per second */
   ulDhryStones = Number_Of_Runs * 100LL / lDhryTime;

?

KO Myung-Hun

[Dariusz Piatkowski]

Hi Andi,

Code: [Select]

Is my printf use of '%lld' incorrect?Which compiler?

IBM C/CPP v.3.6.5 w/ FP2:

Code: [Select]

[G:\CODE\TOOLS\IBMCPP]icc -v
IBM* C and C++ Compilers for OS/2*, AIX* and for Windows NT**, Version 3.6
(C) Copyright IBM Corp. 1991, 1997   All Rights Reserved.
* registered trademarks of IBM Corp., ** registered trademark of Microsoft Corp.


You don't get any warning when compiling with -Wall?

Oh I get plenty if I run with that, but majority of this is about the #IFDEF & #ENDIF, occasionally I see something in there that's different though, which I suspect is the reason why the default makefile just usese '-Wpro', and that's what I kept in there.

BTW: Is there the option to skip stuff like the #IFDEF & #ENDIF pairs, b/c if I could I would most certainly run with '-Wall'. ICC has various choices for the '/W', the pre-defined groups as they reference them in the User's Guide are a plenty, but I genuniely have no idea what does what.

[Dariusz Piatkowski]

Hello KO,

...How about changing

   /* now calculate runs per second */
   ulDhryStones = Number_Of_Runs * 100 / lDhryTime;

to

   /* now calculate runs per second */
   ulDhryStones = (long long)Number_Of_Runs * 100 / lDhryTime;

or

   /* now calculate runs per second */
   ulDhryStones = Number_Of_Runs * 100LL / lDhryTime;

...

YUP!!! Both of these approaches worked.

So I think I should have caught onto this earlier (lesson learned) b/c the Dhrystone benchmark code defines Number_Of_Runs as 'unsigned long', and I thought in that calculation there would be an implicit cast since I'm going from a lesser range to a larger range (i.e. the MAX value of unsigned long will always 'fit' into long long).

I did not want to redefine the variable in Dhrystone code itself, so I left it alone there.

Anyways...alright, I've got this working now, and that's giving me some ideas regarding other calculations that are still most likely overflowing.

Thank you both gents!!!

[Andi B.]

-Wall - with one project I've '/Wppt- /Wppc- /Wext-'. No clue what it does but at that time I thought I've do disable these.

[Dariusz Piatkowski]

Andi,

-Wall - with one project I've '/Wppt- /Wppc- /Wext-'. No clue what it does but at that time I thought I've do disable these.

Here is what these decode to:

1) ppt - Trace of preprocessor actions is OFF
2) ppc - Possible problems with using the preprocessor is OFF
3) ext - Unused external definitions is OFF

I've attached a quick '/Wgrp Table' print from VACPP3 "User's Guide".

The DEFAULT combo for VACPP3 is documented as: "/Wall-pro+ret+cnd+", so that would be:

1) All warnings are OFF
2) Missing function prototypes are ON
3) Consistency of return statements is ON
4) Possible redundancies or problems in conditional expressions in ON

...and that made me go back to the makefile and tweak what's in there already to just "-Wpro-".