Causality - Revision history

Tcarlson at 09:05, 21 July 2020

2020-07-21T09:05:18Z

Tcarlson at 16:14, 17 December 2012

2012-12-17T16:14:31Z

Wheirman at 10:39, 23 November 2012

2012-11-23T10:39:44Z

Wheirman at 10:32, 23 November 2012

2012-11-23T10:32:23Z

Wheirman: Created page with "In Sniper (as in [http://groups.csail.mit.edu/carbon/?page_id=111/ Graphite] from which Sniper is derived), each memory access is simulated to completion in a single function ca..."

2012-11-23T10:25:36Z

Created page with "In Sniper (as in [http://groups.csail.mit.edu/carbon/?page_id=111/ Graphite] from which Sniper is derived), each memory access is simulated to completion in a single function ca..."

New page

In Sniper (as in [http://groups.csail.mit.edu/carbon/?page_id=111/ Graphite]
from which Sniper is derived), each memory access is simulated to completion in a
single function call. This means that in the memory subsystem, time
advances during the simulation of one memory access; then time is
potentially set backwards to start the simulation of the next memory
access. This makes that time inside the memory subsystem isn't always
advancing monotonically (known affectionately as the "fluffy time"
problem).

Because of this, the contention queue-model can only be an
approximation as it doesn't consider request arriving out-of-order
(the only state in this model is the last time the resource became
available). The history-list queue model improves on this by keeping a
list of previous times when the resource was in use. Then, when a
request arrives for an earlier time stamp, this time stamp can be
looked up in the history list, and the model can determine wether the
resource was free at that time, and if not, when the earliest time is
when the resource is free which determines the queueing delay.

Of course, even the history list queue model cannot handle actual
causality errors, which occur when requests earlier in simulated time
affect later requests -- but the former are simulated later in
wallclock time (because they were generated by a core that was lagging
behind). This is why the Graphite people have moved to their
cycle-level mode, but we found that the fluffy-time system works well
enough for memory subsystem trade-off studies -- while yielding
significantly faster simulation speeds.

@@ Line 23: / Line 23: @@
 the different models. In contrast, Sniper allows each simulated core to make
 independent progress for a considerable length of time, but periodically
-inserts global barriers (by default, every 100 simulated nanoseconds)
+inserts global barriers (by default, every 1000 simulated nanoseconds)
 to ensure an upper bound on the timing differences (skew) between
 the different cores. This design choice greatly improves parallelism

@@ Line 11: / Line 11: @@
 Additionally, different core models execute relatively independently.
 Each core can, at the same instant in real time, be making a memory access
-at a slightly different simulated time, but accessing the same resource
+at a slightly different simulated timestamp, but be accessing the same resource
 (e.g. a shared cache or an on-chip network link).
 Here again, this shared resource will see
@@ Line 25: / Line 25: @@
 inserts global barriers (by default, every 100 simulated nanoseconds)
 to ensure an upper bound on the timing differences (skew) between
-the different cores.
+the different cores. This design choice greatly improves parallelism
-Because of this, the contention queue-model can only be an
-approximation as it doesn't consider request arriving out-of-order
+== Bandwidth modeling and queuing delays ==
-(the only state in this model is the last time the resource became
-available). The history-list queue model improves on this by keeping a
+Because of this problem, the care must be taken when implementing queuing models
 list of previous times when the resource was in use. Then, when a
 request arrives for an earlier time stamp, this time stamp can be
-looked up in the history list, and the model can determine wether the
+looked up in the history list, and the model can determine whether the
 resource was free at that time, and if not, when the earliest time is
-when the resource is free which determines the queueing delay.
+when the resource is free which determines the queuing delay.
 Of course, even the history list queue model cannot handle actual
 causality errors, which occur when requests earlier in simulated time
 affect later requests -- but the former are simulated later in
-wallclock time (because they were generated by a core that was lagging
+wall clock time (because they were generated by a core that was lagging
-behind). This is why the Graphite people have moved to their
+behind). Still, we found that this system works well
 enough for memory subsystem trade-off studies -- while yielding
 significantly faster simulation speeds.

@@ Line 1: / Line 1: @@
-In Sniper (as in [http://groups.csail.mit.edu/carbon/?page_id=111/ Graphite]
+In Sniper (as in [https://github.com/mit-carbon/Graphite Graphite]
 from which Sniper is derived), each memory access is simulated to completion in a
 single function call. This means that in the memory subsystem, time

@@ Line 4: / Line 4: @@
 advances during the simulation of one memory access; then time is
 potentially set backwards to start the simulation of the next memory
-access. This makes that time inside the memory subsystem isn't always
+access. This makes that time inside the memory subsystem (including
 advancing monotonically (known affectionately as the "fluffy time"
 problem).
 Because of this, the contention queue-model can only be an