This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
2007/5/16, Joe Buck <Joe.Buck@synopsys.com> wrote:
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote:
> 2007/5/15, Joe Buck <Joe.Buck@synopsys.com> wrote:
> [ explanation of why gprof is as it is ]
> It's not well reasoned.
If you don't like my explanation, feel free to rewrite the software;
it is free software after all. This list usually responds even to
good ideas with "patches welcome", meaning that it is up to the
proposer to do the work.
I'm not going to engage you in further discussion.
With my comments, i can help them to attempt to improve the things.
Before beginning, this will be an affair between 3 entities:
gprof, gcc and linux kernel.
The tricks are to use instructions of timing of CPU like RDTSC in addition to
timers clocks (ticks: 1 Hz or 50, 60, 100, 120, 250, 1000 Hz) and
kernel patches.
The kernel will have to inform (if it was requested by the user process through
a system call) to the user process the corresponding needed information being
written it to a memory's cell previously requested.
Any type of flaw does not have to happen.
This information must contain minimumly the number (long64) of the
subcontext sequence uniquely identified as a result of the context's switches,
system calls, interruptions, signals, etc.
The kernel or a daemon must give a detailed list of the timings of
subcontexts that
were available for only the requested process of user (user time of program's
running only) without counting the lost times by I/O, interruptions,
signals, etc.
The list of the lost times can be requested too.
With this numerous information, the profiler can collect this data and
calculate the
timings shown as presentation in a horizontal bar (or vertical bar) to
be applicable
the Amhdal's Law.
For instance, this tuple stored in the memory's cell of the user
process gives an idea
* number of quantum's subcontext: long64
* moment of time that the subcontext started: long64 (CPU cycles, from RDTSC)
* (optional) moment .... subcontext started: uint32 (Unix's seconds from 1970)
* etc.
(a context is formed by several subcontexts)
Initially, it's known that the duration of one ideal RDTSC's cycle is calculated
(double64) or that how many cycles of RDTSC are one second (long64).
Then, profiler's functions can use this tuple to compare if the differences
between RDTSC's values are inside of the time quantum or not.
There are many other alternatives as don't store it in the memory's cell of the
user process. It's like to store the tuples in the list of the kernel, of the
daemon or of another place.
This is only the end point of an iceberg.
Sincerely yours, J.C.