1 / 10

Aurora/PetaQCD/QPACE Metting Regensburg University , April 14-15, 2010

Aurora/PetaQCD/QPACE Metting Regensburg University , April 14-15, 2010. Key Computation Issues. Large volume of data ( disk / memory / network ). Significant number of solvers iterations due to numerical intractability. Redundant memory accesses coming from interleaving data dependencies.

nico
Télécharger la présentation

Aurora/PetaQCD/QPACE Metting Regensburg University , April 14-15, 2010

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. Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  2. Key Computation Issues Large volume of data ( disk / memory / network ) Significant number of solvers iterations due to numerical intractability Redundant memory accesses coming from interleaving data dependencies Use of double precision because of accuracy need (hardware penalty) Misaligned data (inherent to specific data structures) Exacerbates cache misses (depending on cache size) Becomes a serious problem when consider accelarators Leads to « false sharing » with Shared-Memory paradigm (Posix, OpenMP) Padding is one solution but would dramatically increase memory requirement Memory/Computation compromise in data organization (e.g. gauge replication) Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  3. Why the CELL Processor ? Highest computing power in a single « computing node » Fast memory access Asynchronysm between data transfers and computation Issues with the CELL Processor ? Data alignment (both for calculations and transfers) Heavy use of list DMA Small size of the Local Store (SPU local memory) Ressources sharing with Dual Cell Based Blade Integration into an existing standard framework Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  4. Whatwe have done Implementation of each critical kernel on the CELL processor SIMD version of basic operators Appropriate DMA mechanism (efficient list DMA and double buffering) Merging of consecutive operations into a unique operator (latency & memory reuse) Aggregation of all these implementations into a single and standalone library A single SPU thread holds the whole set of routines SPU thread remains « permanently » active during a working session Effective integration into the tmLQCD package Data re-alignment Routine calls replacement (invoke CELL versions in place of native ones) This should be the way to commit this back to tmLQCD (external library and « IsCELL » switch) Successful tests (QS20 and QS22) Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  5. Global Organization Task partitioning, distribution, and synchorization are done by the PPU Each SPE operates on its data portion by a typical loop of the form (DMA get + SIMD Computation + DMA put) The SPE, always active, switches to the appropriate operation on each request Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  6. Optimal list DMA organization for the Wilson-Dirac Operator The computation of Wilson-Dirac action for a set of K contigousspinors required to get 8K spinors (Example below with 32x163 lattice and even-odd ) A direct list DMA to get this « spinors matrix » involves 8x4 DMA items A list DMA to get the « transpose » involves 7 + 1 + 1 = 9 DMA items Generally, our list DMA is of size 8 + ck instead of 8K ( bin packing ) No impact on SPU performance because of the uniform access to the LS Significant improvment in global performance and scalability Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  7. Performance results We consider a 32x163 lattice and CELL-accerated version of tmLQCD Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  8. Comments We observed a factor 2 between QS20 and QS22 We observed a factor 4 between QS22 and Intel i7 quadcore 2.83 Ghz Good scalability on QS20 Scalability on QS22 is alterated beyond 4 SPEs (probably a binding issue on the Dual Cell Based Blade, which should be easy to fix) Fixing this scalability issue on QS22 will double actual performances Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  9. Ways for improvment Implement the « non GAUGE COPY » version (significant memory reduction / packing) Explore the SU(3) reconstruct approach at SPE level (memory andbandwith savings) Having the PPU participate in the calculations (makes sens in double precision) Try to scale up to the 16 SPEs on the QS22 Dual Cell Based Blade Experiment with a cluster of CELL processors Outstanding performance expected Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

  10. END Aurora/PetaQCD/QPACE Metting Regensburg University, April 14-15, 2010

More Related