1 / 29

Computer Architecture Dataflow Machines

Computer Architecture Dataflow Machines. Sunset over Lifou, New Caledonia. Data Flow. Conventional programming models are control driven Instruction sequence is precisely specified Sequence specifies control which instruction the CPU will execute next Execution rule:

calida
Download Presentation

Computer Architecture Dataflow Machines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer Architecture Dataflow Machines Sunset over Lifou, New Caledonia

  2. Data Flow • Conventional programming models are control driven • Instruction sequence is precisely specified • Sequence specifies control • which instruction the CPU will execute next • Execution rule: • Execute an instruction when its predecessor has completed • s1: r = a*b;s2: s = c*d;s3: y = r + s; s2 executes when s1 is complete s3 executes when s2 is complete

  3. c d x Data Flow • Consider the calculation • y = a*b + c*d • Represent it bya graph • Nodes representcomputations • Data flows alongarcs • Execution rule: • Execute an instruction when its data is available • Data driven rule a b x + y

  4. c d x Data Flow • Dataflow firing rule • An instruction fires (executes)when its data is available • Exposes all possible parallelism • Either multiplication canfire as soon as data arrives • Addition must wait • Data dependence analysis! • Instruction issue units: • Fire (issue) each instructionwhen its operands (registers) have been written a b x + y

  5. Data Flow - Realisations • Several Experimental Machines built • Manchester Gurd & Watson • Tagged Token Arvind, MIT • Sigma ETL, Tsukuba • EMC-4 ETL, Tsukuba • Monsoon Arvind, MIT • EMX ETL, Tsukuba • RAPID Osaka/Sharp/Mitsubishi(Asynchronous!) • Naiad Tasmania • and some others

  6. Data Flow - Realisations • Manchester

  7. Data Flow - Program • Program word • Matching Store Entry • When both Presence Flags are Y,this packet is despatched to a PE (any PE!) Destination Left or Right Operation +, -, *, / etc Destination Address Left, Right Operands Presence Flags

  8. Data Flow - Matching Store • Special purpose memory • Limited processing capability • Detects full slots • Despatches operation packets to any idle PE Destination Left or Right Operation +, -, *, / etc Destination Address Left, Right Operands Presence Flags

  9. Data Flow - Processing Elements • Receive operation packets • Generate result • Form result packet • Despatch to matching store

  10. Data Flow - EM4 • Architects • Yamaguchi,Sakai, Kodama,Sato et al • ElectroTechnicalLaboratory,Tsukuba,Japan • PE (EM-Y) • CMOS Gate Array • 80k gates / 1.0m • f = 20MHz • ~1992

  11. Data Flow - Monsoon • Architects • Papadopoulos, Culleret al • MIT, Cambridge • PE • f = 10MHz • ~1990 • I-StructureProcessor

  12. Data Flow - I-Structures • Memory with a presence bit • Tag each memory location with a bitindicating its validity • Valid bit set -> normal read (no wait) • Data not yet written (valid bit not set) • Wait • Read requests queued • Data driven execution • Operations proceed when data is available valid data valid data valid data

  13. Data Flow - Monsoon Pipeline • 8 stage pipeline • “Presence bits”checks operandavailability • Frame (coarse grain)basis

  14. Data Flow - Summary • Fine-Grain Dataflow • Suffered from comms network overload! • Coarse-Grain Dataflow • Monsoon ... • Overtaken by commercial technology!! • A sad “fact-of-life” • It’s almost impossible to generate the fundsfor non-”mainstream” computer architecture research • $n x 108 required L • Non-mainstream = interesting!

  15. Data Flow - Summary • As a software model … • Functional languages • Dataflow in a different guise! • Theoretically • important • Practically? • Inefficient ( = slow!!) • ….. Ask your CS colleagues! • Cilk - based on C • Used on CIIPS Myrmidons • Uses a dataflow model • Threads become ready for execution when their data is generated • Message passing efficiency • Without explicit data transfer & synchronisation!

  16. Networks • Network Topology (or shape) • Vital to efficient parallel algorithms • Communication is the limiting factor! • Ideal • Cross-bar • Any-to-any • Non-blocking • Except two sources to same receiver • Realisable • But only for limited order (number of ports)

  17. Networks • Cross-bars • Achilles • 8 x 8 • Full duplex • Simultaneous Input and Outputat each port • 32 bit data-path • Target : 1Gbyte / second total throughput • but we needed the 3-D arrangement to achieve • bandwidth • high order

  18. Networks • Cross-bars • Achilles • Hardwarealmost trivial! • Single FPGAon each level • Programmable • VHDL Models • Several topologies • Just by changing thesoftware!

  19. Networks - More than 8 PEs • Simple • Use 2 8x8 routers! but…. This link gets a lot of traffic!

  20. Networks - Fat tree • Problem: • High-traffic links between PEs can become a bottleneck • Solution: Fat-tree • Links higher up the tree are “fatter” • Sustainable bandwidth between all PEs is the same

  21. Networks - Performance Metrics • Metrics for comparing network topologies • Diameter • Maximum distance between any pair of nodes • Determines latency • Bisection Bandwidth • Aggregate bandwidth over any “cut”which divides the network in half • Determines throughput • Crossbar • Diameter: 1 • Every PE is directly connected to routerso a single “hop” suffices • Bisection Bandwidth: b bytes/sec • b is the bandwidth of a single link

  22. Networks - Performance Metrics • Metrics for comparing network topologies • To connect n PEs with mxm crossbars • Single link bandwidth b bytes/s • Simple: n = 14 (2 switches) • Diameter 3 • Bisection Bandwidth b 1 2 3

  23. Networks - Performance Metrics • Fat-tree • Diameter: 2 logmn • Height is logmn • Worst case distance - up and down • Bisection Bandwidth: b n/2 bytes/sec • Links are fatter higher up the tree logmn

  24. Networks - Performance Metrics • Mesh • Diameter: 2Ön-2 • Bisection Bandwidth: b Ön bytes/sec • Order: 4

  25. Networks - Performance Metrics • Hypercube • Hypercube of order m • Link 2 order m-1 hypercubes with 2m-1 links • Number of PEs: n = 2m • Order: log2n = m Order 2 Hypercube Order 2 Hypercube Order 3 Hypercube

  26. Networks - Hypercubes • Embedding property • In an n PE hypercube,we have hypercubes of size n/2, n/4, … • Number PEs with binary numbers • 000, 001, 010, 011, 100, … • Joining two hypercubes • add one binary digitto the numbering • Each PE is connectedto every PE whoseindex differs in only one bit

  27. Networks - Hypercubes • Embedding property • Partitioning tasks • Allocate to sub-cubes • Sub-tasks allocated tosub-cubes of that cube,etc

  28. VLIW - Very Long Instruction Word • Instruction word: multiple operations • n RISC-style instructions • Architecture: fixed set of functional units Each FU matched to a “slot” in the instruction

  29. VLIW - Very Long Instruction Word • Compiler responsible for allocating instructions to words • Burden squarely on compiler • Needs to produce near optimal schedule • Inevitable: large number of empty slots! • Lower code density • Similar to superscalar • but instruction issue flexibility missing • VLIW simpler Ü faster? • Re-compilation needed • Each new generation will have different functional unit mix

More Related