<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Guojing,<br>
<br>
Yes, we had a very productive discussion with I-Hsin about the ways to
better use Xprofiler, and, in the discussion, we have seen a very
strange way of handing double FPU instructions.<br>
<br>
Let me first describe the example. <br>
<br>
The programs measure the performance of two implementations for BLAS1
function daxpy, one written naively in C, and second written with the
use of double FPU in ASM. All time measurements are performed by using
time SPRs with the help of inline asm calls.<br>
<br>
The main function is written in C. First of all, it allocates arrays,
measures the function call overhead (repeatedly calling "empty"
function, written in ASM, and then starts the main loop. The main loop
iterates over the size of the arrays, 16 to 512 step 16 in this
example. For each size N2, it calls C-function K times, than ASM
function K times, after which prints average time to stderr. <br>
<br>
Notes:<br>
<br>
1) It is very important to compile C-implementation with -O5 to ensure
double FPU instructions get generated.<br>
2) ASM routine is compiled with C compiler, -g -pg options.<br>
<br>
My observations<br>
<br>
1) gprof and Xprofiler give a little different flat profile. In
Xprofiler, daxpy_ASM_small_N is not recognized, but another function
called __mcount_internal has appeared.<br>
<br>
2) Both gprof and Xprofiler identify a function called EX1, which takes
28% of the time. However,<br>
<br>
2.1) Trying to open the source code for it, Xprofiler says "Cannot open
file "daxpy_C_small_N.c" for reading. Apparently, such file exists,
contains daxpy_C_small_N function, and does not contain EX1 function.<br>
2.2) EX1 function was wrongly misinterpreted from daxpy_ASM_small_N
function, given in daxpy_ASM_small_N.s file. However, EX1 is not a
global label, so it should not be interpreted as an entry point.<br>
2.3) I cannot disassembly EX1 function - Xprofiler gives an empty
window.<br>
<br>
3) Xprofiler correctly finds the source code for daxpy_C_small_N
function. The problem starts when I am trying to disassembly this
function, where, for example, looking at offsets 1001D14 and below, the
double FPU opcodes are interpreted incorrectly. For example, 1001D14
7C87439C opcode should be disassembled as "lfpdx f4,r7,r8", that can be
obtained from <br>
<br>
/bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin/objdump -D
daxpy_C_small_N.o<br>
<br>
So, Xprofiler uses front-end version of objdump, but should use a
back-end version.<br>
<br>
The sources and example run are attached.<br>
<br>
Thank you for you help, and sorry for such a long message.<br>
<br>
Best regards,<br>
<br>
Vitali<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Guojing Cong wrote:
<blockquote
cite="mid:OF6295ADC7.DB59DCC8-ON852574F0.0057DD10-852574F0.00583C5A@us.ibm.com"
type="cite"><br>
<font face="sans-serif" size="2">Hi Vitali,</font>
<br>
<br>
<font face="sans-serif" size="2"> I
heard from I-hsin that you are having problem with showing double
hummer
assembly. Can you give me the binary and the code region you are
interested, so that I can take a look here?</font>
<br>
<br>
<font face="sans-serif" size="2">Regards</font>
<br>
<font face="sans-serif" size="2">Guojing</font>
<br>
</blockquote>
<br>
</body>
</html>