#1620: TimerReport doesn't scale very well. ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Resolution: | Keywords: ----------------------+-----------------------------------------------------
Comment (by bmundim):
The overhead in TimerReport surprises me. TimerReport needs to collect
information from all processes and sort it, which requires a reduction operation and string operations. Maybe one of the algorithms used isn't scalable -- we should investigate further.
That surprised me too. As we start using a larger number of cores for our simulations, it might be good to take a look at this.
The difference in timings comes likely from overhead between the
respective measurement intervals. The timing prefixed "[0176]" comes from the Cactus scheduler, which calls into Carpet, which then has to perform certain operations before calling the actual function, which is then measured by the other timer (".../thorns/..."). One of these operations is synchronization, but there are also others.
Thanks a lot for this clarification.
Cheers, Bruno.