From: fabio AT joplin DOT colorado DOT edu (Fabio Somenzi)
Subject: Libraries and gprof
17 Jan 1997 21:30:41 -0800
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199701171742.KAA23557.cygnus.gnu-win32@joplin.colorado.edu>
References: <009AE7AE DOT 8D3AAE80 DOT 7373 AT ifk20 DOT mach DOT uni-karlsruhe DOT de>
Reply-To: Fabio AT Colorado DOT EDU
Original-To: gnu-win32 AT cygnus DOT com
In-Reply-To: <009AE7AE.8D3AAE80.7373@ifk20.mach.uni-karlsruhe.de>
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Heribert (dahms AT ifk20 DOT mach DOT uni-karlsruhe DOT de) writes:

> : Paging brings up an interesting issue: a well-organized shared library
> : can reduce memory usage and paging by localizing functions on the same
> : page that end to call each other.  I don't know how many people bother
> : to do this, or if there are automated tools (there ought to be).

> For analyzing maybe gprof? But I don't know how to force ld to a specific
> order, if possible at all on the various platforms, or even a portable one.
> Not to mention alignment and cache issues...

I thought gprof was a program-counter-sampling-based profiler.
I'd be delighted to find out I'm wrong, because
basic-block-counting-based profilers are so much better.

Assuming I'm wrong on this count, even a basic-block-counting-based
profiler ignores effects related to memory locality. For those you
need either architectural simulators or programs that have access to
the stats the CPU keeps.

(For the purpose of reordering libraries, however, you don't need that
low-level information, and a linker that can read info from a
basic-block-counting-based profiler is all it takes.)

Fabio

-- 
Fabio Somenzi          | Phone: 303-492-3466
University of Colorado | Fax:   303-492-2758
ECE Dept.              | Email: Fabio AT Colorado DOT EDU
Boulder CO 80309-0425  | WWW:   http://vlsi.colorado.edu/~fabio
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".