profiling - gprof messing up -
i trying 2 profile cpp code. compiled -pg flags , after profiled output got weird function names. make file using:
# makefile parallel simulated annealer prefix=${parsecdir}/pkgs/kernels/canneal/inst/${parsecplat} target=canneal libs:=$(libs) -lm cxxflags+=-pg ifdef version ifeq "$(version)" "pthreads" cxxflags+=-denable_threads -pthread endif endif all: $(cxx) $(cxxflags) annealer_thread.cpp -c -o annealer_thread.o $(cxx) $(cxxflags) rng.cpp -c -o rng.o $(cxx) $(cxxflags) netlist.cpp -c -o netlist.o $(cxx) $(cxxflags) main.cpp -c -o main.o $(cxx) $(cxxflags) netlist_elem.cpp -c -o netlist_elem.o $(cxx) $(cxxflags) $(ldflags) *.o $(libs) -o $(target) clean: rm -f *.o $(target) install: mkdir -p $(prefix)/bin cp -f $(target) $(prefix)/bin/$(target)
this sample of gprof output:
flat profile: each sample counts 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 11.21 0.73 0.73 2800002 0.00 0.00 std::_rb_tree<std::string, std::pair<std::string const, netlist_elem*>, std::_select1st<std::pair<std::string const, netlist_elem*> >, std::less<std::string>, std::allocator<std::pair<std::string const, netlist_elem*> > >::_m_lower_bound(std::_rb_tree_node<std::pair<std::string const, netlist_elem*> >*, std::_rb_tree_node<std::pair<std::string const, netlist_elem*> >*, std::string const&) 10.45 1.41 0.68 5856992 0.00 0.00 atomic_load_acq_int(unsigned int volatile*) 8.76 1.98 0.57 400001 0.00 0.00 netlist_elem::routing_cost_given_loc(location_t)
and these true function names in file:
void annealer_thread::run()
any flags im forgetting? , why profiling showing parameters of functions? because classes? because cpp? familiar gprof , c first encounter cpp
any welcome:) cheers=)
in c++, function names include class belong to, return type, , argument types. that's done "mangling" names. functions can overloaded different argument types. gprof
aware of , can un-mangle them.
what you're seeing in flat profile pc captured in class library routines. that's helpful if gives clue call paths in code end in routines. call graph (instrumentation) there.
and of course it's blind i/o you'd rather not doing. program spending 99% of time doing i/o deep in library, don't know it's happening , neither gprof
.
take @ zoom.
Comments
Post a Comment