gprof 搞砸了
我正在尝试 2 个 cpp 代码。我使用 -pg 标志进行编译,在对其进行分析以获取输出后,我得到了一些非常奇怪的函数名称。 这是我正在使用的 make 文件:
# Makefile for 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)
这是 gprof 输出的示例:
Flat profile:
Each sample counts as 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)
这些是文件中的真实函数名称:
void annealer_thread::Run()
我忘记了任何标志吗?为什么分析还显示函数的参数?是因为他们是班级吗?是因为它是cpp吗? 我熟悉 gprof 和 c,但这是我第一次接触 cpp
欢迎任何帮助:) 干杯=)
I am trying 2 profile a cpp code. I compiled with -pg flags and after I profiled it to get the output I got some very weird function names.
this is the make file I am using:
# Makefile for 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 is a sample of the gprof output:
Flat profile:
Each sample counts as 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 are the true function names in the file:
void annealer_thread::Run()
Any flags im forgetting? and why is the profiling also showing the parameters of the functions? is it because they are classes? is it because it is cpp?
I am familiar with gprof and c but this is my first encounter with cpp
Any help is welcome:) cheers=)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在 C++ 中,函数名称包括它们所属的类、返回类型以及所有参数类型。这是通过“修改”名称来完成的。这样函数就可以用不同的参数类型重载。
gprof
知道这一点并且可以对它们进行恢复。您在平面配置文件中看到的是,PC 通常在某些类库例程中捕获。仅当它为您提供了代码中最终在这些例程中的调用路径的线索时,这才有用。调用图(检测)对此有一些帮助。
当然,它对您不想做的任何 I/O 都是盲目的。
该程序可能花费 99% 的时间在库深处执行 I/O,您不知道它正在发生,
gprof
也不知道。看看缩放。
In C++, function names include the class they belong to, their return type, and all their argument types. That's done by "mangling" the names. This is so functions can be overloaded with different argument types.
gprof
is aware of that and can un-mangle them.What you're seeing in the flat profile is that the PC is often captured in some class library routines. That's helpful only if it gives you a clue what the call paths are in your code that end up in those routines. The call graph (instrumentation) is some help there.
And of course it's blind to any I/O you'd rather not be doing.
The program could be spending 99% of its time doing I/O deep in a library, where you don't know it's happening and neither does
gprof
.Take a look at Zoom.