Itanium2 CPU(Madison) calculation problem

[Jeong Jin-wook]

My customer complain about Itanium CPU(Madison) compared to SD PA-RISC(1.1GHz).
Here is CPU info below.
Model : SD
CPU info:
Number of CPUs = 16
Clock speed = 1600 MHz
Bus speed = 400 MT/s

Customer ran simple C program (+,-,*,/).
Here is Result.

-------------------------------
plus : 18.9sec
minus : 18.9sec
multiply : 18.9sec
divide : 47.0sec
-------------------------------


--------------------------------

plus : 23.1sec
minus : 23.1sec
multiply : 23.1sec
divide : 23.1sec
--------------------------------
Customer ask me why divide is so slow on Itanium. Is there any way to reduce time?

Here is source code and complie option.
#include
#include
#include
#include
#include
#include
double start_time,end_time,t_runtime;
double i,j;
double gettime();
main(argc, argv)
int argc;
char *argv[];
{
char command[80];
if(argc != 1 ) {
printf(" Usage : bmt1-4 \n");
exit(0);
}

j=1;
start_time = gettime();
for(i = 1; i < 5000000000; i++ ) {
j = j/i;
}

end_time = gettime();
t_runtime = end_time-start_time;
printf("Running Count [%f] Time:[%f]\n",i, t_runtime);
exit(0);
}

double gettime()
{
struct timeval tv;
(void) gettimeofday (&tv, (struct timezone *) 0);
return ((double) tv.tv_sec + (1.0e-6 * (double) tv.tv_usec));
}

cc -DD64 +O3 -o div "cpu_cal_divi.c"

complier version 6.13

Any one can help me?

P.S. This thread has been moved from HP 9000 to HP-UX > languages. -HP Forum Moderator

[Duncan Edmonstone]

Two things to try:

1. You might get more joy posting this on the Itanium-dev mailing list here:

http://h21007.www2.hp.com/dspp/ml/ml_MailingLists_IDX/1,1275,,00.html#24

2. HP Provide a free tool for diagnosing perf issues on Itanium - Caliper - maybe have your customer run this over the issue:

http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1174,00.html


HTH

Duncan

[Stan Sieler]

As your PA-RISC compilation should have noted, 5000000000 is too large an integer
value for i. Mine said (on PA):
cc: "div.c", line 27: warning 602:
Integer constant exceeds its storage.

i, BTW, is a double (floating point) ...
which is bad (from the name, it should
be an int of some kind).

Did you really want i to be a 64-bit integer?
(If so, add "LL" suffix to 5000000000
and make i "long long int", or "int64_t")

If this helps, don't forget points, please :)

[Stan Sieler · Accepted solution]

I forgot to mention that using a 64-bit floating point variable as a "counter" or "control variable" in a for loop is about 20 times slower than using an int64
(on PA, and about 7 times slower on IPF).

[Dennis Handly]

There is no hardware floating point divide on IPF. There is only a reciprocal approximation instruction, frcpa

Your for-loop that only tests the divide, takes 12 bundles with nothing being able to be used in most of the instruction slots, just 12 FP instructions.

In a real application, the other NOP slots would have some useful work being done.

(I moved your i,j variables as locals and made sure the loop wasn't removed.)

>Is there any way to reduce time?

You "reduce" it by measuring a real application, not this toy benchmark.