ccurtsinger
commented
5 years ago 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.
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.