Re: [Valgrind-users] Measuring "cache temperature" of structure fields

[Josef W. <Jos...@gm...>]

Hi,

I would like to integrate events related to data structures in my
calltree skin. I recently had no time for this, but it is definitely on
my TODO.

Perhaps we can work together to make this a reality?

The big win with cache simulation is that we have all the data addresses
of memory references. With oprofile, I don't think this is available (Correct
me if I'm wrong). Still, P4 and Itanium would provide this (in a statistical 
way) via "tagged events".

Things in mind for the skin:
* Reading type info, static vars from debug info to get from address to 
symbolic information. Jeremy already has written something like this for
helgrind for STABS format.
* Have a table for address -> data structure mapping. This has to be updated
on mallocs/frees, and stack frame enter/leave.
* Perhaps storing events even per data type offset is too much for arrays.
I would relate them to address differences of successive references into the 
same array. This even includes some timing information, and the user should 
already be happy with information like e.g. "all L2 misses happen when going 
through the array with stride 100".
* Enhance the cachegrind.out format for this kind of information. I like to
have both code & data related info in the same file.
* Write a command line tool to output the information. This always should be
done even if we have a GUI visualisation tool, as not everybody wants GUIs.
(I recently made ct_annotate in the calltree package working again).
* Make some graphical visualization. IMHO, this would perfectly fit into my
KCachegrind tool (With a list of data structures side by side to the list of 
functions).

Regarding implementation: As we need to enhance the debug info reader
in the skin, we have to extend the skin API for this/put code into VG core. 
I would prefer an even more modular approach than now in VG (to be) 2.0: Put 
the debug info reader (currently in VG core) into its own shared lib which 
can be replaced by skins.
In the end, we would have plugins which provide additional functionality which 
can be used by other plugins or by skins (some kind of hierarchical 
layering). The startup script would have to check for plugin versions to 
decide which libs to put into LD_PRELOAD for a skin to be runnable.

Josef

On Thursday 30 October 2003 23:53, Bill Rugolsky Jr. wrote:
> Hi,
>
> I am trying to optimize cache usage in several large applications
> (that I didn't write), and I'd like to measure the "cache temperature"
> of various fields in the principal data structures so that I can
>
>    1. Group together fields that are "hot".
>    2. Perhaps move the bulk of "cold" data into separately allocated
>       structures.
>    3. Compact some fields into Fortran-style arrays and use indexing.
>
> I am curious as to whether there is any work-in-progress on a skin that
> might aid this type of analysis, or whether anyone has any particular
> design advice.  Both valgrind and oprofile are good at identifying
> particular bits of code that cause cache misses (from which one can
> identify which field is being accessed, etc.), but the analysis becomes
> more difficult when cache misses are spread more uniformly throughout
> the code.
>
> Thanks,
>
> 	Bill Rugolsky
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users