Overhead insight

Overhead insight

As if an FAQ, we see significanttiming differences between ArBB's verbose report of execution time (presumably actual work being done) versus an external timingwith scoped_timer (presumably including all data copying overheads, but what else?). In detail, what all accounts for the greater "external" time?

Trivial example:

const closure &, dense &)> clo = capture(do_it);
clo(vbar, vfoo); // once, to process any set-ups
const scoped_timer timer(ptime, scoped_timer::unit_us);
clo(vbar, vfoo); // time this execution

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The ARBB_VERBOSE environment setting was designed for the Intel ArBB engineering team to use during product development. The information generated by verbose mode really only makes sense in the context of development of the dynamic runtime. It is not designed to be a precise way to measure performance of Intel ArBB code kernels. Consequently, this environment setting will be removed in an upcoming release.

The recommended way to measure performance is implemented in the Intel ArBB code samples. From your code snippet, you are using the correct method for measuring actual work versus compilation + actual work.



Understood, and we can appreciate some development mode characteristics will be removed from the final product. However, there is a certain amount of help we need to more effectively use the product. In the case that prompted the question (above), we were experimenting with a trade-off of using multiple data streams into a stencil calculation versus using map() with neighbor(). The former way involves marshalling duplicate data, whereas the latter way has the constraints imposed by map(). What we are learning is that shuttling data has a cost (data is your enemy) and wed like to quantify that cost. Is there some thought for providing a breakout of time spent copying data, in and out, from the useful work? Guessing whats going on is undesirable.

Thank you,
- paul

Yes there is - in the long term (post 1.0), we are considering adding some type of verbose mode which would be helpful to developers. This feedback helps - thanks!If you or anyone else has other ideas about how a new verbose mode should work - feel free to let us know. I've submitted this to our development DB for tracking and I can add new ideas/suggestions to it at any time.--Amanda

We just need insight to know "which bits to love."
- paul

Leave a Comment

Please sign in to add a comment. Not a member? Join today