|Basic-Block Profiling Isn't Always Accurate firstname.lastname@example.org (1993-03-08)|
|Re: Basic-Block Profiling Isn't Always Accurate email@example.com (1993-03-09)|
|Re: Basic-Block Profiling Isn't Always Accurate firstname.lastname@example.org (1993-03-11)|
|Re: Basic-Block Profiling Isn't Always Accurate email@example.com (1993-03-12)|
|Re: Basic-Block Profiling Isn't Always Accurate firstname.lastname@example.org (1993-03-14)|
|From:||email@example.com (Pohua Chang)|
|Summary:||No, Andy is just trying to make me post|
|Keywords:||performance, architecture, bibliography|
|Organization:||Software Technology, Intel Corp, Santa Clara, CA|
|Date:||Fri, 12 Mar 1993 02:10:19 GMT|
firstname.lastname@example.org (Andy Glew) writes:
>In private conversation, Pohua (P.P. Chang) has indicated that he rarely
>finds edge profile information useful in trace selection - i.e. the
>additional information is rarely used to generate better code.
>I must admit that I find this surprising. I (and many others, I'm sure)
>pushed for edge profiling, because I have found edge probability info
>useful in doing hand assembly code -- and I usually expect that something
>I can do by hand should be automatable. It may be that none of the
>optimizations Pohua uses really benefit from edge profiling, but that
>there may be others that do.
>Pohua - if you are out there, care to comment? Have I blatantly
>misrepresented you? Do you now find edge profiling really useful feedback
>for a compiler?
Not true!!! I can make very good uses of edge profile information. I
think that Andy Glew was just trying to make me post on the net.
In addition to node and edge profiling, people are also beginning to look
at profiling data values and where cache misses are likely to occur. If
you are interested in advanced profiling, you can talk to Professor
Santosh Abraham at the University of Michigan, Ann Arbor
(email@example.com). He is trying to find memory instructions that
contribute to a large fraction of all cache misses. Dr. Bob Rau of HP lab
has spoken about the importance of knowing the load latency at compile
time for VLIW machines in his MICRO25 Invited Lecture.
BTW, node and edge profiling have been studied for many years now. If you
care about recent results, you may find the following papers interesting.
I have enjoyed reading all of them.
A. D. Samples,
Ph.D. Dissertation, UC Berkeley,
Report No. UCB.CSD 91/627, April 1991.
"Determining average program execution times and their variance",
in Proc. of the ACM SIGPLAN '89 Conf. on Programming
Language Design and Implementation, 24(7), pg. 298-312,
T. Ball, and J. Larus,
"Optimally profiling and tracing programs",
Tech. Report 1031, Univ. of Wisconsin, 1991.
"Reducing overhead in counter-based execution profiling",
Computer Systems Laboratory, Stanford Univ.,
Tech. Report No. CSL-TR-91-495, Oct. 1991.
T. Ball, and J. Larus,
"Branch prediction for free",
Computer Sciences Department, Univ. of Wisconsin- Madison,
Tech. Report No. 1137, Feb. 1993.
J. A. Fisher, S. M. Freudenberger,
"Predicting conditional branch directions from
previous runs of a program",
HP Laboratories Technical Report No. HPL-92-98,
Aug. 1992. (also see ASPLOS)
Older references may also be interesting to you.
D. E. Knuth, and F. R. Stevenson,
"Optimal measurement points for program frequency counts",
BIT, 13, pg. 313-322, 1973.
R. L. Probert,
"Optimal insertion of software probes in well-delimited programs",
IEEE Transactions on Software Engineering, SE-8(1),
pg. 34-42, Jan. 1982.
P. J. Weinberger,
"Cheap dynamic instruction counting",
Bell System Technical Journal, 63, pg. 1815, 1984.
Since I am posting to the net, I might as well ask those of you who are
currently doing research in the area of profile-guided code optimizations
to let me know how I can find your recent technical reports and papers
that are on this subject. I promise to find spare time to read them and
give you some feedbacks.
Software Engineer, Intel Corporation
2200 Mission College Blvd.
Santa Clara, California 95052-8119
Mail Stop: RN6-18
Return to the
Search the comp.compilers archives again.