Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where to place progress points #103

Closed
adarshyoga opened this issue Mar 20, 2019 · 1 comment
Closed

Where to place progress points #103

adarshyoga opened this issue Mar 20, 2019 · 1 comment

Comments

@adarshyoga
Copy link

What is a good strategy to identify where in a program to place progress points?
From the documentation I understand that for obtaining a useful profile one has to place progress points in code regions that can be sped-up. I have noticed that in my experiments too; the profiles generated after placing progress points are more useful than profiles with "end-to-end" option.

For instance, we profiled an Intel TBB program with Coz. We ran it initially with the "end-to-end" option. After about 50 runs, the profile highlighted a single line which would, at best, speedup the program by 6.4%. But since this was a program which we had sped-up earlier, we placed a progress point in the region we had optimized. After placing the progress point, the profiles began to highlight a line in the region that we optimized.

For this program, I knew what part of the program to optimize to speedup the program. But, given an arbitrary program where I have no idea of what code regions I can speedup, I have so far not been able to understand how to place progress points. Should we use a profiler like gprof to identify the frequently executed code and place progress points in those regions?

Any advice on this would be very helpful.

@ccurtsinger
Copy link
Member

You should place a progress point at a position in the code where a program has completed a unit of work. That may be the entire program's run, though as you point out that is quite inefficient. The benchmarks from the Coz paper all have progress points inserted after iterations, at the ends of transactions, or in the final stage of a pipeline. Placing a progress point in frequently-executed code would not be helpful, as the progress point is meant to be a proxy for whole-program performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants