Joel, I'm CC'ing you as you apparently have set up profiling build
type in CMake.
I'm trying to profile MOSES using gprof, via setting build type =
Profile. That build type deactivates optimization, but wouldn't it
better to profile a code that is optimized? Because some piece of code
might appear to be a bottleneck but wouldn't be so anymore once
optimized by the compiler, right? I've seen so much variance in the
way -O2 can optimize code that I don't think we can assume the field
is leveled, therefore my point.
Any reason to profile without or with optimization?
Perhaps one must do both?
I've never used a profiling tool before, so any advice is welcome...
Thanks,
Nil
Looks like people do both...
Nil
Unfortunately I can't remember the specific use-case I was using the
profiling build-type for.
You're right of course that the performance of the optimized code is
more important in practice, but I also think that trying to understand
the profiling of a optimized program and how it maps to the actual
code can be quite tricky at times... especially at the higher levels
of optimization.
I also tried using programs like callgrind, and in the case of
optimization, where things might be inlined, the exact call counts
wouldn't necessarily truly reflect the hotspots of the code.
In short, feel free to use whatever works for you. :-)
Joel
optimization changes the match-up between line numbers in the C file,
and the corresponding assembly code. This drives some people crazy,
because they can't figure out how the C source turned into the
optimized assembly. Inline functions are particularly hard to
understand... But if you can deal with this, then optimize. But also
be aware that the resulting profile may be misleading, unintuitive,
might seem broken or insane. Once you realize that some strange
number might be due to optimization, and can proceed onwards, then all
is well. Otherwise, your profile data might be hard to understand.
--linas