[pypy-svn] r59435 - pypy/build/doc

[xoraxax at codespeak.net]

Author: xoraxax
Date: Mon Oct 27 01:25:01 2008
New Revision: 59435

Modified:
   pypy/build/doc/benchmark_memory.txt
Log:
Some thoughts about memory benchmarking.

Modified: pypy/build/doc/benchmark_memory.txt
==============================================================================
--- pypy/build/doc/benchmark_memory.txt	(original)
+++ pypy/build/doc/benchmark_memory.txt	Mon Oct 27 01:25:01 2008
@@ -16,7 +16,7 @@
   running the GC benchmarks - either launched
   independently, or forked from a single process
 
-* measure the "percieved pauses" for interactive apps
+* measure the "perceived pauses" for interactive apps
   when running on GCs with stop-the-world collection
   (i.e. all our framework GCs so far).
 
@@ -55,8 +55,23 @@
 * Aim for reproducible results, e.g. by combining some of
   these techniques:
   - checkpoints (perform measures at known execution points);
+    Then we would simply dump allocation information
+    on every n'th malloc and a few times in every garbage 
+    collection run.
+    We could either do this by dumping internal information
+    from the garbage collector (not accounting for rawmalloc
+    properties) or by blocking the process
+    in the malloc and gc code and advising the checkpointing
+    process to checkpoint. Note that this does not reflect
+    all properties of the virtual memory system because
+    the page tables will likely also change in between these
+    synchronization points.
   - high-res sampling (either in the real system or in
     emulators, e.g. look at valgrind tools).
+    - valgrind provides a heap profiler called "massif",
+      but valgrind only runs on x86 or similar. We can
+      assume that the heap allocation profile is very
+      similar on different platforms, right?
 
 * The "perceived pause" is probably best approximated by
   the time it takes to perform a single collection.  For
@@ -64,6 +79,10 @@
   collections of various levels; for example, nursery-only
   collections are very fast, probably too fast to be
   noticeable in interactive apps.
+  
+  In order to gather this information, the framework GCs
+  need to be able to dump the collection statistics in a
+  reusable manner.
 
 * real APPS: 
   * some sympy computation/test?