Paper Title: A Limits Study of Benefits from Nanostore-Based Future Data-Centric System Architectures

Problem:

  • How to evaluate future cloud/data (in-memory compute) systems? (Setting baselines & comparison points)
  • Explore design space of incorporating NVM in large-scale
  • Throughput of data-intensive apps is power constrained

Users:

  • Warehouse-scale /data-center designers & providers. If problem is how to evaluate the systems, then the people building them are obviously interested. Users may also want to evaluate to compare different datacenter vendors, features etc.
  • Architects in general
  • Cost-sensitive (almost all users are const-sensitive, just w/ different limits on resources)
  • Data intensive processing

The particular study shown is dependent on this. Is the specific evaluation methodology & architecture proposed dependent on this?

Solution:

  • Performance model
InputsOutputs
Simple Phase PlanPerformance (absolute/relative)
Perf/phaseLatency
Power/phaseEnergy
System description 
  • Performance:
  1. Time to complete workload
  2. Progres rate (instructions, tasks, data processed)
  • Latency:
  1. Average
  2. %-tile
  3. Missed deadlines, distribution of them
  • Energy:
  1. Node
  2. System
  3. Other components
  • System description:
  1. B/W
  2. # cores
  3. # nodes
  4. Power for component
  • How are these performance metrics different?
    • Is there a continuous stream of data vs. just final answer, etc.
    • Some workloads make more sense for throughput vs latency related metrics, combination.
  • What do they measure in their model?
    • No specific measure of latency, but just said some didn’t meet latency goals (i.e. avg. %-tile metrics as a constraint.)
    • Not clear how they didn’t meet the goals.. was it max, avg, etc.?
  • They characterized program phases to get a performance metric. Need either to average the performance characteristics, or combine them to get total execution.
    • In the appendix, they use the tail-thread in each phase as the execution time of that phase and then add them up to get total time to complete workload.
  • For energy, they sum the power in each phase that they got from mcpat to get total system energy per workload. Then combine the execution time with this energy to get energy-delay product.
    • Energy-delay product gives you one number that lets you compare both energy & performance.
    • Energy*delay to some power can let you favor energy or performance more.
    • They seem to plot 1/EDP to make graphs look better (higher up moving to the right “appears” better.) Perf/watt doesn’t combine the notion of time like EDP.
  • Benchmarks
  1. Sort
  2. Search
  3. Video encoding
  4. Collaborative filtering
  5. Hash
    • They claim they represent some interesting workloads & are diverse in their requirements.
      • Some read-in lots of data, some requrie more in-resident data, some require more compute.
      • They didn’t quantitatively show how these different benchmarks met this diversity goal.
  • Validation
    • Compared their models against sort, their most challenging case.
      • For this methodology to be a contribution:
      1. Can you reproduce their work on a new benchmark? Not precisely.
      2. Is there anything that they did that was non-obvious?
  • Design-space
    • Advocate nanostore extreme (use it both as memory & storage, only NVM no disk/dram).
    • Advocate 3D-stacking (place chips on top of one another and connecting with thru-silicon vias).
    • Small distance=low-power & can place many vias = high bandwidth.
      • Can you go buy phase-change memory today?
        • Not yet, but soon (Intel crosspoint), probably slower than assumed in paper.
    • They only evaluated nanostore vs. traditional, not incorporating NVM in traditional storage hierarchy.
  • Evaluation
    • For each system (nanostore, flash, hdd) where is the optimal EDP?
    • As #cores change where on the EDP plot is the ideal point for each benchmark?
    • Why was nanostore better?
    1. Assumed no leakage
    2. assumed higher b/w (conservative compared to real 3d-stacking today)
    3. no page swapping (but not in baseline either)
    4. b/w to storage was higher because they had more independent storage units (pcie forflash limited to 10GB/s, not fair comparison because could just add more ssds in same way).
    5. Overhead of parallelism somewhat missing from the evaluation.
  • Convinced?
    • Was the methodology a contribution?
    • Why was paper chosen?
      • Different type of doing research
      • Introduce us to pcm
      • Ties in data-center & j-machine.
      • Useful to see a paper that is exploring a space rather than a new technique.