06-15-2010 12:10 AM
So I have written a simple test and compiled it on HP-UX ia64 11.31 with gcc 4.3.1.
This was a command to build the test:
g++ -g -O2 -pthread -mlp64 tz_test.cpp -o tz_test
Then I profiled it with caliper A.4.3.2:
caliper frof tz_test
When I profile tz_test caliper gives me this diagnostic message for the test:
+ Bad or invalid debug information in tz_test
No source attribution possible.
and in the "Function details" there are lines like this:
19.32 [(No source information) tz_test::worker_thread::thread_func(), 0x40000000000211d0]
What could be done in order to fix this problem and to generate with gcc 4.3.1 correct debug information for caliper?
By the way there are some more things that might be relevant to my question:
1) wdb 6.1 correctly finds debug information in the executable built with gcc 4.3.1
2) gcc –O0 gives the same diagnostic message
3) when I compile the same test with aCC A.06.15 and then profile it I don't get this diagnostic message.
Everything is correct.
For aCC this was a command to build the test:
aCC -g0 -mt +W2461 +DD64 +O2 tz_test.cpp -o tz_test
Solved! Go to Solution.
06-15-2010 01:52 AM
And unless you are optimizing with aC++, you are likely wasting your time with caliper and g++.
You could try reporting it on the "Tech support" page off of:
>Then I profiled it with caliper A.4.3.2: caliper frof tz_test
Was that fprof?
The latest Caliper is 5.2.
06-15-2010 03:39 AM
Why? What is wrong with caliper and gcc on HP-UX ia64?
> Was that fprof?
> The latest Caliper is 5.2.
Asked to install and waiting for a response.
06-15-2010 03:52 AM
gcc doesn't begin to give the performance that aC++ can give.
So what do you expect caliper to provide for gcc compiled code?
06-15-2010 04:13 AM
I compile my tests and the main application with aCC A.06.15. I use this command:
aCC -g0 -mt +DD64 +O2 my_source.cpp.
As for this test I don't see that aCC builds code which is faster than gcc does.
As for the main application I have even seen some decrease in performance.
Could you please suggest some other aCC options to use to get better performance?
06-15-2010 01:33 PM
+O3, -ipo, +Oprofile=collect (run instrumentation phase) then +Oprofile=use
Where does caliper say you are spending your time? scgprof
06-18-2010 01:41 AM
Dennis, thanks a lot.
I have got some more question that are related to caliper.
1) How can I be sure that a modification makes an application better or worse?
For example I have changed an algorithm in the function foo() and I want to check if it is now better or worse or there is no change. Let's assume that my modification doesn't result in a huge improvement so if I run a test for 1 minute the result might be 0,1 seconds better or 0,1 worse. Even though the improvement is not significant I simply want to know that there has been some improvement. By the way let's assume that the application is a daemon application.
After reading the caliper "User guide" I think that I should use the ecount measument and it will show me results of even small changes in my code. Of course without telling me where the improvement happened exactly which is OK since let's assume I have done only one modification.
Am I right that I have to use ecount in this situation?
2) And if I am right about ecount there is another question. What values in an ecount report tells me that there has been some improvement?
I run caliper in this way:
caliper ecount -e 60 -o test_result.txt
So first I measure in this way the old release of the application and then the modified release. However I am not sure what figures show me exactly that the modified version is better. Could you help me in this? Should I compare IA64_INST_RETIRED? Or should I compare cycles lost due to stalls? Or Effective CPI ? Or what?
3) How does current global CPU utilization of a HP-UX server affect "caliper ecount" and all other measurements?
My application is CPU bound. For example if I run "caliper ecount -e 60
4) I have read here http://h20338.www2.hp.com/enterprise/downloads/Usi
My application normally allocates a few GBs for its data so I think should follow this advice. The question is that I am not sure what value I should set for the virtual memory page size that must be used for data in this situation? The paper recommends using 1M. However if I normally allocates a few GBs should I set 64M or even a bigger value?
Or is it useful in this situation to use "caliper ecount" just to measure the possible effect? I mean first run "caliper ecount" then run "chatr +pd 64M my_application", then run again "caliper ecount" and compare results? Or should I just follow the advice in the paper and simply set 1M?
06-18-2010 04:22 AM
If a database doesn't have lots of records then after loading the records VSS is around 90 MB.
06-19-2010 12:42 AM
>Am I right that I have to use ecount in this situation?
Typically that's not how you go about improving the whole application. You start with something like scgprof or fprof.
>2) What values in an ecount report tells me that there has been some improvement?
This is where you use Tech support on the caliper page.
> 4) I have read here that "for memory-intensive applications you really want to consider using large pages".
Yes. Do you get lots of DTLB misses?
>The paper recommends using 1M.
I heard that the kernel has problems over 1M.
>I mean first run caliper then run "chatr +pd 64M", then run again caliper and compare results?
If that shows fewer DTLB misses then that's good.
>put them in different mostly small structures and classes
Large pages still can help, provided the data isn't scattered all over too much.
06-22-2010 05:36 AM
As for the question about setting the virtual memory page size that should be used for data I should not use any sizes that greater than 1M.