Mar. 7

Tempest & Typhoon

Problem Being Solved

  • Proliferation of supercomputers (i.e. large-scale parallel systems)
  • Cache coherence is not flexible enough
  • Parallel systems with global shared address space
  • Too much divergence in execution models (i.e. portability)
  • How do you architect for the future (not technology) but more clever software/enable exploration of future optimizations
  • Efficient synchronization and communication (i.e. hiding their costs)

Users

Who are the users?

  • Shared memory applications, but message passing is important
  • Default is shared memory, but message passing can be used for optimizations
  • Predicted/asserted that large-scale shared memory will the norm in the future (wrong!)
  • Users should not be able to deadlock one another

Hardware versus software:

  • Programmers are clever — provide software/programmability to exploit it
  • Fixed function is more efficient but restrictive
  • Innovation can be stifled when everything is automatically done in hardware

Limitations of Cache Coherence:

  • Not efficient synchronization (lots of cache-line movement)
  • Hiding the costs of communication/synchronization
  • Replication
  • Cache-only architecture is full of indirection

Their Approach

Replication:

  • Page granularity
  • Princeton SHRIMP: shared memory without (or minimal) hardware support
  • One virtual address space with exceptions
  • Block granularity
  • Network processor is transparently handled by network processor

Network Processor

  • Exception-based (interrupting the CPU is getting more and more expensive)

Other notable machines with integrated networks:

  • Tempest and Typhoon
  • Stanford FLASH
  • MIT Alewife
  • MIT StarT

Hardware-centric machines:

  • MIT Monsoon
  • Stanford DASH
  • Manchester Dataflow Machine

Evaluation

  • Stache for general-purpose coherence
  • Customize protocol by writing user-level handlers:
  • rTLB
  • exception
  • context switching
  • virtual memory
  • I/O TLBss
  • Deadlocks/Deadlock prevention
  • Users should not conflict with one another
  • Didn’t talk about contention, security, fault tolerance

Wisconsin Wind Tunnel:

  • Thinking Machines, messed with ECC bits to emulate network processor on exceptions
  • Emulation: functional effectively functional simulation with adding estimation coefficients

Mar. 9

Tempest & Typhoon (cont)

Today’s agenda

  • Finish Typhoon
  • Why choose this paper
  • Recap all previous papers (actually not covered)

Evaluation

Simulator tools options

  • public & community
  • private

Typhoon uses modified Wisconsin Wind Tunnel simulator

Simulation accuracy options

  • Functional
  • Functional with delay
  • Cycle accurate

Typhoon uses functional simulation with delay

  • Advantage: fast
  • Disadvantage: inaccurate on some aspect, such as memory latency

Typhoon is the only paper which used simulator at that point

Why simulation?

  • Realize an idea to an implementation
  • Make sure nothing critical is missing

Simulation Trap

  • Bias
  • Hard to choose correct parameters, sensitivity on parameters

Was the evaluation in line with user requirement?

The result (data, graph) itself is supportive, however, the wording and phrasing that the author used made them less convincing

The author only showed results form one set of contexts, without a range of results, or, error bar.

Failed to explain exceptional cases (outliers) well.

Use EM3D example to demonstrate flexibility of Typhoon. It will be better if the limitation is also included

Reason of choosing this paper

  1. Follow network processing system serial.
  2. Some ideas such as RDMA(remote DMA) remains today and is still used in today’s database.
  3. An example of “Visionary Paper”: Papers which look at the future and (try to) guide/lead the research in this field.