On Tue, Apr 19, 2011 at 1:22 PM, Johan Tibell <[email protected]> wrote:
> * It could be the case that GHC is generating symbols that perf cannot
> interpret somehow. If we can confirm this is the case we can try to
> fix that.
I spent the day making sure this is not the case. All the Haskell
functions now have the correct (fingers crossed) .type and .size ELF
directives:
74.18% bench ./bench [.] 0x000000002ac524
7.19% bench /lib/libc-2.11.1.so [.] memcpy
4.53% bench ./bench [.] s1Ok_info
4.28% bench ./bench [.] s1Ol_info
3.28% bench ./bench [.] allocate
0.74% bench ./bench [.] Main_zdwa_info
0.62% bench ./bench [.] memcpy@plt
0.45% bench ./bench [.] clearNurseries
0.36% bench ./bench [.] evacuate
0.27% bench ./bench [.] stg_newArrayzh
Entries 3-6 and 8-10 are Haskell functions. The top entry is still unknown.
If it matters, the little program I'm running stresses array copying
and I would expect it to spend most of its time in memcpy, but these
numbers suggests that it isn't. Could it be some stripped C libraries
or some code generated by gcc specially for memcpy that's accounting
for the top entry?
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
