Re: Profiler

From: Dan Bonachea (bonachea_at_cs_dot_berkeley_dot_edu)
Date: Sun Dec 04 2005 - 04:39:23 PST

  • Next message: Dan Bonachea: "Re: Questions on Berkeley UPC network support"
    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 
    >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:
    Hope this helps...
    >Plz suggest
    >Sirisha Muppavarapu
    >Graduate Student
    >Department of Computer Science
    >University of NewMexico
    >Albuquerque, NM 87131

  • Next message: Dan Bonachea: "Re: Questions on Berkeley UPC network support"