porting gasnet to portals porting gasnet to portals
play

Porting GASNet to Portals: Porting GASNet to Portals: Partitioned - PowerPoint PPT Presentation

Porting GASNet to Portals: Porting GASNet to Portals: Partitioned Global Address Space (PGAS) Partitioned Global Address Space (PGAS) Language Support for the Cray XT Language Support for the Cray XT Dan Bonachea Bonachea Dan Paul Hargrove,


  1. Porting GASNet to Portals: Porting GASNet to Portals: Partitioned Global Address Space (PGAS) Partitioned Global Address Space (PGAS) Language Support for the Cray XT Language Support for the Cray XT Dan Bonachea Bonachea Dan Paul Hargrove, Michael Welcome, Katherine Yelick Yelick Paul Hargrove, Michael Welcome, Katherine Cray User Group (CUG) 2009 Cray User Group (CUG) 2009 http://gasnet.cs.berkeley.edu gasnet.cs.berkeley.edu http:// http://upc.lbl.gov upc.lbl.gov http:// GASNet at UC Berkeley / LBNL

  2. What is GASNet? • GASNet is: - A high-performance, one-sided communication layer - Portable abstraction layer for the network - Runs on most architectures of interest to HPC - Native ports to a wide variety of low-level network APIs - Can run over portable network interfaces (MPI, UDP) - Designed as compilation target for PGAS languages - UPC, Co-array Fortran, Titanium, Chapel,... - Targeted by 7 separate parallel compiler efforts and counting – Berkeley UPC, GCC UPC, Cray XT UPC – Rice CAF, Cray XT CAF, Berkeley Titanium, Cray Chapel – Numerous prototyping efforts GASNet at UC Berkeley / LBNL

  3. PGAS Compiler System Stack PGAS PGAS Code Compiler (UPC, Titanium, CAF, etc) Platform- Compiler-generated code (C, asm) independent Compiler- Network- Language Runtime system independent independent Language- GASNet Communication System independent Network Hardware GASNet at UC Berkeley / LBNL

  4. GASNet Design Overview: System Architecture • Two-Level architecture is mechanism for portability Compiler-generated code Compiler-specific runtime system • GASNet Core API GASNet Extended API - Most basic required primitives, narrow and general - Implemented directly on each network GASNet Core API - Based on Active Messages lightweight RPC paradigm Network Hardware • GASNet Extended API – Wider interface that includes higher-level operations – puts and gets w/ flexible sync, split-phase barriers, collective operations, etc – Have reference implementation of the extended API in terms of the core API – Directly implement selected subset of interface for performance – leverage hardware support for higher-level operations GASNet at UC Berkeley / LBNL

  5. GASNet Design Progression on XT • Pure MPI: mpi-conduit - Fully portable implementation of GASNet over MPI-1 - “Runs everywhere, optimally nowhere” • Portals/MPI Hybrid - Replaced Extended API (put/get) with Portals calls - Zero-copy RDMA transfers using SeaStar support • Pure Portals: portals-conduit - Native Core API (AM) implementation over Portals - Eliminated reliance on MPI • Firehose integration - Reduce memory registration overheads GASNet at UC Berkeley / LBNL

  6. Portals Message Processing NIC Incoming Message Portal Table Optional Match List Memory Event ME Descriptor ME Queue ME Portal Index <0001> <1100> <0110> MD EQ Application Application Memory Region Memory Region - Lowest-level software interface to the XT network is Portals - All data movement via Put/Get btwn pre-registered memory regions - Provides sophisticated recv-side processing of all incoming messages - Designed to allow NIC offload of MPI message matching - Provides (more than) sufficient generality for our purposes GASNet at UC Berkeley / LBNL

  7. GASNet Put in Portals-conduit Node 0 Memory Node 1 Memory Match List GASNet GASNet GASNet GASNet Portal Table segment segment segment segment RAR ME RARSRC RAR MD MD RAR PTE A A B B (No EQ) SAFE EQ SEND_END ACK Local completion Remote completion Node 0’s gasnet_put of A to B becomes: PortalsPut(RARSRC, offset(A), RARME | op_id, offset(B)) Operation identifier smuggled thru ignored match bits GASNet at UC Berkeley / LBNL

  8. GASNet Get in Portals-conduit Node 0 Memory Node 1 Memory Match List GASNet GASNet GASNet GASNet Portal Table segment segment segment segment RAR ME RAR TMPMD MD MD RAR PTE B B (No EQ) SAFE EQ REPLY_END Get C C completion Node 0’s gasnet_get of B to C becomes: PortalsGet(TMPMD, 0, RARME | op_id, offset(B)) Dynamically-created MD for large out-of- segment reference GASNet at UC Berkeley / LBNL

  9. Performance: Small Put Latency 30 25 (down is good) Latency of Blocking Put (µs) 20 15 10 mpi-conduit Put MPI Ping-Ack 5 portals-conduit Put 0 1 2 4 8 16 32 64 128 256 512 1024 Payload Size (bytes) • All performance results taken on 2 nodes of Franklin, quad-core XT4 @ NERSC • Portals-conduit outperforms GASNet-over-MPI by about 2x - Semantically-induced costs of implementing put/get over message passing - Leverages Portals-level acknowledgement for remote completion • Outperforms a raw MPI ping/pong by eliminating software overheads GASNet at UC Berkeley / LBNL

  10. Performance: Large Put Bandwidth 1800 Bandwidth of Non-Blocking Put (MB/s) 1600 1400 (up is good) 1200 1000 800 600 portals-conduit Put 400 OSU MPI BW test 200 mpi-conduit Put 0 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M Payload Size (bytes) • Portals-conduit exposes the full zero-copy RDMA bandwidth of the SeaStar - Meets or exceeds achievable bandwidth of a raw MPI flood test - Mpi-conduit bandwidth suffers due to 2-copy of the payload GASNet at UC Berkeley / LBNL

  11. GASNet AM Request in Portals-conduit Node 0 Memory Node 1 Memory Match List GASNet GASNet GASNet (Triple GASNet Portal Table Req buffered) segment segment segment segment ME ReqRB ReqRB ReqRB ReqSB MD MD MD MD AM PTE AM Request AM Request AM Request AM Request Send Buffers Send Buffers Recv Buffers Buffers Recv AM SAFE EQ EQ AM Request AM Request PUT_END AM Request AM Request AM Request Handler executed Node 0’s gasnet_AMRequestMedium becomes: PortalsPut(ReqSB_MD, offset(sendbuffer), Req_ME | op_id | <AM metadata>, 0) ReqRB has a Locally-managed offset GASNet at UC Berkeley / LBNL

  12. GASNet AM Reply in Portals-conduit Match List Portal Table Node 0 Memory Node 1 Memory Rpl GASNet ME GASNet GASNet GASNet segment segment segment segment AM PTE RplSB ReqSB MD MD AM Reply AM Reply AM Request AM Request Send Buffers Send Buffers Send Buffers Send Buffers SAFE SAFE EQ EQ AM Reply AM Reply AM Reply AM Reply PUT_END AM Reply Handler executed Node 1’s gasnet_AMReplyMedium becomes: PortalsPut(RplSB_MD, offset(sendbuffer), Rpl_ME | op_id | <AM metadata>, request_offset) GASNet at UC Berkeley / LBNL

  13. Portals-conduit Data Structures Match Ops Offset Event MD PTE Bits Allowed Mgt. Queue Description RAR Remote segment: dst of Put, src of Get RAR 0x0 PUT/GET REMOTE NONE RARAM Remote segment: dst of RequestLong payload RAR 0x1 PUT REMOTE AM_EQ RARSRC Remote segment: dst of ReplyLong payload Local segment: src of Put/Long payload, dst of Get RAR 0x2 PUT REMOTE SAFE_EQ ReqRB Dest of AM Request Header (double-buffered) AM 0x3 PUT LOCAL AM_EQ ReqSB Bounce buffers for out-of-segment Put/Long/Get, AM 0x4 PUT REMOTE SAFE_EQ AM Request Header src, AM Reply Header dst RplSB Src of AM Reply Header none none N/A N/A SAFE_EQ TMPMD Large out-of-segment local addressing: none none N/A N/A SAFE_EQ Src of Put/AM Long payload, dest of Get • RAR PTE: covers GASNet segment with 3 MD’s with diff EQs • AM PTE: Active Message buffers - 3 MD’s: Request Send/Reply Recv, Request Recv, and Reply Send - EQ separation for deadlock-free AM • TMPMD’s created dynamically for transfers with out-of-segment local side GASNet at UC Berkeley / LBNL

  14. Portals-conduit Flow Control • Most significant challenge in the AM implementation - Prevent overflowing recv buffers at the target - Prevent overflowing EQ space at either end • Local-side resources managed using send tokens - Request injection acquires EQ and buffer space for send and Reply recv - Still need to prevent overflows at remote (target) end • Initial approach: Statically Partition recv resources between peers - Reserve worst-case space at target for each sender to get full B/W - Initiator-managed, per-target credit system - Requests consume credits (based on payload sz), Replies return them - Downside: Non-scalable buffer memory utilization • Final approach: Dynamic credit redistribution - Reserve space for each receiver to get full B/W - Each peer starts with minimal credits, rest banked at the target - Target loans additional credits to “chatty” peers, and revokes from “quiet” ones GASNet at UC Berkeley / LBNL

  15. Performance: Active Message Latency 30 AM Medium Round-trip Latency (µs) 25 (down is good) 20 15 10 mpi-conduit portals-conduit 5 0 1 2 4 8 16 32 64 128 256 512 1024 Payload Size (bytes) • Shows the benefit of implementing AM natively • Portals-conduit AM’s outperform mpi-conduit - Less per-message metadata, big advantage under 1 packet - Beyond one packet, less software overheads w/o MPI GASNet at UC Berkeley / LBNL

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend