From: Dan Bonachea (bonachea_at_cs_dot_berkeley_dot_edu)
Date: Sun Dec 04 2005 - 04:39:23 PST
At 01:47 PM 12/2/2005, Sirisha Muppavarapu wrote: >Hello Everybody... > >I am trying to profile my UPC code and analyse its performance as the number >of threads increase. I am getting a good scale up. But, When I installed UPC >with --enable-debug option and I compile my code with -pg option and run it, >it says > >"This application was built from a Berkeley UPC installation that > was configured and built with these optional features enabled: > debugging tracing statistics > This usually has a SERIOUS impact on performance, so you should NOT > trust any performance numbers reported in this program run!!! > > To suppress this message, pass '-quiet' to the upcrun command or set > the UPC_NO_WARN or UPC_QUIET environment variables." > > >My question is: Can I rely on the numbers it gives in the profiled >information >obtained by executing "gprof a.out > result.txt" for my analysis? (i.e the >numbers-time,%time given per method). How else can will I know abt the >performance if not for using the profiler? Hi Sirisha- The warning message means exactly what it says - you should never trust performance numbers from an --enable-debug build, because --enable-debug globally disables all compiler optimizations and enables hundreds of additional sanity checks throughout the system to help you find bugs - a transformation which will significantly impact system performance. --enable-debug should be used during development for finding correctness bugs in your code, but never for production runs where you're gathering performance data or tuning performance. For serial profiling (-pg), you should use a UPC runtime build which was configured without --enable-debug. -pg and gprof support is available in both modes, but the results should only be trusted in non-debug mode. Note that in non-debug mode, many of the UPC runtime helper functions (notably including pointer-to-shared arithmetic) will be automatically inlined or compiled away entirely, which helps performance but will also "flatten" the gprof output somewhat - specifically, computation from such functions will be charged against the caller. If you're interested in parallel profiling (ie profiling of communication behavior for distributed memory) you should configure with --enable-stats or --enable-trace and use upc_trace: http://upc.lbl.gov/docs/user/upc_trace.html Hope this helps... Dan >Plz suggest > >Thanks >Sirisha > > >----------------------------------------------------------------------------- >Sirisha Muppavarapu >Graduate Student >Department of Computer Science >University of NewMexico >Albuquerque, NM 87131 >-----------------------------------------------------------------------------