Changes between Version 39 and Version 40 of RTSsummaryEvents

Timestamp:

04/06/12 23:05:45 (14 months ago)

Author:

MikolajKonarski (IP: 95.160.111.162)

Comment:

improve wording and add extra examples

RTSsummaryEvents

@@ -7 +7 @@
 ==== Calculate the total memory allocated on a per-capability basis ====
 
-In addition to the existing global method. For now we just do
+In addition to the existing global method, we calculate the total 
+memory allocated on a per-capability basis. For now we do
 it both ways and assert they give the same grand total. At some
 stage we can simplify the global method to just take the sum of
@@ -14 +15 @@
 ==== Change the presentation of parallel GC work balance in +RTS -s ====
 
-Also rename internal variables to make the names match what they hold.
+We change the presentation of parallel GC work balance in +RTS -s
+and also we rename internal variables to make the names match what they hold.
 The parallel GC work balance is calculated using the total amount of
 memory copied by all GC threads, and the maximum copied by any
@@ -34 +36 @@
 {{{
   Parallel GC work balance: 4.56% (serial 0%, perfect 100%)
+}}}
+
+Some more examples of the new form from nofib/parallel on a 2-core machine with -N2:
+
+{{{
+ray:  Parallel GC work balance: 13.81% (serial 0%, perfect 100%)
+gray:  Parallel GC work balance: 28.25% (serial 0%, perfect 100%)
+prsa:  Parallel GC work balance: 29.16% (serial 0%, perfect 100%)
+coins:  Parallel GC work balance: 62.43% (serial 0%, perfect 100%)
+blackscholes:  Parallel GC work balance: 15.25% (serial 0%, perfect 100%)
+minimax:  Parallel GC work balance: 79.86% (serial 0%, perfect 100%)
+nbody:  Parallel GC work balance: 52.39% (serial 0%, perfect 100%)
+}}}
+
+and a couple examples from other parts of nofib:
+
+{{{
+nofib/gc/circsim:  Parallel GC work balance: 22.35% (serial 0%, perfect 100%)
+nofib/gc/fibheaps:  Parallel GC work balance: 7.07% (serial 0%, perfect 100%)
+nofib/spectral/clausify:  Parallel GC work balance: 3.48% (serial 0%, perfect 100%)
+nofib/real/cacheprof:  Parallel GC work balance: 0.90% (serial 0%, perfect 100%)
 }}}
 
@@ -123 +146 @@
 == The analysis of the semantics of +RTS -s ==
 
-Here is a sample output of +RTS -s, annotated with a discussion of new events required to simulate it in ThreadScope (for a user-selected time interval).
+Here is a sample output of +RTS -s that was used in the early design phases for the corresponding events.
+The output is annotated with a discussion of new events required to simulate it in ThreadScope (for a user-selected time interval).
 A list of the new required events is in the second part of this page.
 Here is a [https://github.com/Mikolaj/ThreadScope/raw/working/SummaryPanelMockup.png screenshot]
@@ -269 +293 @@
 I'd guess the elapsed time should always be higher than the CPU time, shouldn't it?
 
-== The list of considered new events (the implementation closely follows this draft, even though not all details match) ==
+== The list of considered new events (the actual implementation closely follows this draft, even though not all details match) ==
 
 There is a wealth of statistics around heaps and GC. Some of the stats are reasonably common, shared by different implementations while many more are highly specific to a particular implementation. Even if we ignore RTSs other than GHC, we still have an issue of flexibility for future changes in GHC's RTS.