DOCSLIB.ORG

Comparison of Threading Programming Models

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

2017 IEEE International Parallel and Distributed Processing Symposium Workshops Comparison of Threading Programming Models Solmaz Salehian, Jiawen Liu and Yonghong Yan Department of Computer Science and Engineering, Oakland University, Rochester, MI USA {ssalehian,jliu,yan}@oakland.edu Abstract—In this paper, we provide comparison of language performance comparisons of OpenMP, Cilkplus and C++11 features and runtime systems of commonly used threading for data and task parallelism on CPU, showing the impacts parallel programming models for high performance computing, of runtime systems on the performance. The paper makes including OpenMP, Intel Cilk Plus, Intel TBB, OpenACC, Nvidia CUDA, OpenCL, C++11 and PThreads. We then report our the following contributions: 1) a list of features for threading performance comparison of OpenMP, Cilk Plus and C++11 for programming APIs to support existing and emerging computer data and task parallelism on CPU using benchmarks. The results architectures; 2) comparison of threading models in terms of show that the performance varies with respect to factors such as feature support and runtime scheduling strategies; 3) perfor- runtime scheduling strategies, overhead of enabling parallelism mance comparisons of OpenMP, Cilk Plus and C++11 for data and synchronization, load balancing and uniformity of task workload among threads in applications. Our study summarizes and task parallelism on CPU using benchmark kernels and and categorizes the latest development of threading programming Rodinia [7]. APIs for supporting existing and emerging computer architec- The rest of the paper is organized as follows. In section tures, and provides tables that compare all features of different II, a list of API features of parallel APIs are summarized. APIs. It could be used as a guide for users to choose the APIs In section III, comparisons of interfaces and runtime systems for their applications according to their features, interface and performance reported. are presented. Section IV presents performance comparisons. Section V provides related work study and Section VI contains Keywords -threading; parallel programming; data parallelism; our conclusion. task parallelism; memory abstraction; synchronization; mutual exclusion II. FEATURES FOR THREADING PROGRAMMING APIS I. INTRODUCTION The evolvement of programming models has been mostly The High Performance Computing (HPC) community has driven by advances of computer system architectures and new developed a rich variety of parallel programming models to application requirements. Computing nodes of existing and facilitate the expression of the required levels of concurrency emerging computer systems might be comprised of many to exploit hardware capabilities. Programming APIs for node- identical computing cores in multiple coherency domains, or level parallelism, such as OpenMP, Cilk Plus, C++11, POSIX they may be heterogeneous, and contain specialized cores that threads (PThreads), Intel Threading Building Blocks (TBB), perform a restricted set of operations with high efficiency. OpenCL, Microsoft Parallel Patterns Library (PPL), to name Deeper memory hierarchies and more challenging NUMA a few, each has its unique set of capabilities and advantages. effects for performance optimization have been seen in the They also share certain functionalities realized in different emerging computer systems. Further, explicit data movement interfaces, e.g., most of them support both data parallelism is necessary for nodes that present distinct memory address and task parallelism patterns for CPU. They are all evolving spaces to different computing elements, as demonstrated in to become more complex and comprehensive to support new today’s accelerator architectures. computer architectures and emerging applications. It becomes To facilitate programming a diversified range of computer harder for users to choose from those APIs for their appli- systems, an ideal API must be expressive for the required cations with regards to the features and interfaces of these levels of concurrency and many other unique features of models. hardware, while permitting an efficient implementation by The same parallelism pattern could be realized using differ- system software. In this section, we categorized different ent interfaces and implemented using different runtime sys- features of threading model APIs. The detailed comparison tems. The runtime systems that support those features vary in of threading programming APIs based on these categories are terms of scheduling algorithms and implementation strategies, discussed in next section. which may cause dramatically different performance for the Parallelism: A programming model provides API for spec- same applications created using different programming APIs. ifying different kinds of parallelism that either map to parallel Thus, performance-wise selection of the right API requires architectures or facilitate expression of parallel algorithms. We efforts for studying and benchmarking for users’ application. consider four commonly used parallelism patterns in HPC: 1) In this paper, we provide an extensive comparison of data parallelism, which maps well to manycore accelerator language features and runtime systems of commonly used and vector architecture depending on the granularity of data threading parallel programming models for HPC, including parallel unit; 2) asynchronous task parallelism, which can OpenMP, Intel Cilk Plus, Intel TBB, OpenACC, Nvidia be used to effectively expresses certain parallel algorithms, CUDA, OpenCL, C++11 and PThreads. We then report our e.g., irregular and recursive parallelism; 3) data/event-driven 978-0-7695-6149-3/17978-1-5386-3408-0/17 $31.00 © 2017 IEEE 766 DOI 10.1109/IPDPSW.2017.141 computation, which captures computations characterized as manycore accelerators. Intel TBB and Cilk Plus are task based data flow; and 4) offloading parallelism between host and parallel programming models used on multi-core and shared device, which is used for accelerator-based systems. memory systems. OpenMP is a more comprehensive standard Abstraction of memory hierarchy and programming for that supports a wide variety of features we listed. data locality: Portable optimization of parallel applications on shared memory NUMA machines has been known to be A. Language Features and Interfaces challenging. Recent architectures that exhibit deeper memory The full comparisons of language features and interfaces hierarchies and possible distinct memory/address spaces make are summarized in Table I, II and III. For parallelism support portable memory optimization even harder. A programming listed in Table I, asynchronous tasking or threading can model helps in this aspect by providing: 1) API abstraction of be viewed as the foundational parallel mechanism that is memory hierarchy and core architecture, e.g., an explicit no- supported by all the models. Overall, OpenMP provides the tion of NUMA memory regions or high bandwidth memory; 2) most comprehensive set of features to support all the four language construct to support binding of computation and data parallelism patterns. For accelerators (NVIDIA GPUs and Intel to influence runtime execution under the principle of locality; Xeon Phis), both OpenACC and OpenMP provide high-level 3) means to specify explicit data mapping and movement for offloading constructs and implementation though OpenACC sharing data between different memory and address spaces; supports mainly offloading. Only OpenMP and Cilk Plus and 4) interfaces for specifying memory consistency model. provide constructs for vectorization support (OpenMP’s simd Synchronizations: A programming model often provides directives and Cilk Plus’ array notations and elemental func- constructs for supporting coordination between parallel work tions). For data/event driven parallelism, C++’s std::future, units. Commonly used constructs include barrier, reduction OpenMP’s depend clause, and OpenACC’s wait are all for and join operations for synchronizing a group of threads or user to specify asynchronous task dependency to achieve tasks, point-to-point signal/wait operations to create pipeline such kind of parallelism. Other approaches, including CUDA’s or workflow executions of parallel tasks, and phase-based stream, OpenCL pipe, and TBB’s pipeline, provide pipelining synchronization for streaming computations. mechanisms for asynchronous executions with dependencies Mutual exclusion: Interfaces such as locks are still widely between CPU tasks. used for protecting data access. A model provides lan- For supporting abstraction of memory systems and data guage constructs for creating exclusive data access mecha- locality programming, the comparison is listed in Table II. nism needed for parallel programming, and may also define Only OpenMP provides constructs for programmers to specify appropriate semantics for mutual exclusion to reduce the memory hierarchy (as places) and the binding of compu- opportunities of introducing deadlocks. tation with data (proc bind clause). Programming models Error handling, tools support, and language binding: that support manycore architectures provide interfaces for Error handling provides support for dealing with faults from organizing a large number threads (x1000) into a two-level user programs or the system to improve system and applica- thread hierarchy, e.g., OpenMP’s teams of threads, Ope- tion resilience. Support for tools, e.g., performance profiling nACC’s gang/worker/vector clause, CUDA’s blocks/threads
Recommended publications
  • Other Apis What’S Wrong with Openmp?

    Other Apis What’S Wrong with Openmp?

    Threaded Programming Other APIs What’s wrong with OpenMP? • OpenMP is designed for programs where you want a fixed number of threads, and you always want the threads to be consuming CPU cycles. – cannot arbitrarily start/stop threads – cannot put threads to sleep and wake them up later • OpenMP is good for programs where each thread is doing (more-or-less) the same thing. • Although OpenMP supports C++, it’s not especially OO friendly – though it is gradually getting better. • OpenMP doesn’t support other popular base languages – e.g. Java, Python What’s wrong with OpenMP? (cont.) Can do this Can do this Can’t do this Threaded programming APIs • Essential features – a way to create threads – a way to wait for a thread to finish its work – a mechanism to support thread private data – some basic synchronisation methods – at least a mutex lock, or atomic operations • Optional features – support for tasks – more synchronisation methods – e.g. condition variables, barriers,... – higher levels of abstraction – e.g. parallel loops, reductions What are the alternatives? • POSIX threads • C++ threads • Intel TBB • Cilk • OpenCL • Java (not an exhaustive list!) POSIX threads • POSIX threads (or Pthreads) is a standard library for shared memory programming without directives. – Part of the ANSI/IEEE 1003.1 standard (1996) • Interface is a C library – no standard Fortran interface – can be used with C++, but not OO friendly • Widely available – even for Windows – typically installed as part of OS – code is pretty portable • Lots of low-level control over behaviour of threads • Lacks a proper memory consistency model Thread forking #include <pthread.h> int pthread_create( pthread_t *thread, const pthread_attr_t *attr, void*(*start_routine, void*), void *arg) • Creates a new thread: – first argument returns a pointer to a thread descriptor.
  • Introduction to Openacc 2018 HPC Workshop: Parallel Programming

    Introduction to Openacc 2018 HPC Workshop: Parallel Programming

    Introduction to OpenACC 2018 HPC Workshop: Parallel Programming Alexander B. Pacheco Research Computing July 17 - 18, 2018 CPU vs GPU CPU : consists of a few cores optimized for sequential serial processing GPU : has a massively parallel architecture consisting of thousands of smaller, more efficient cores designed for handling multiple tasks simultaneously GPU enabled applications 2 / 45 CPU vs GPU CPU : consists of a few cores optimized for sequential serial processing GPU : has a massively parallel architecture consisting of thousands of smaller, more efficient cores designed for handling multiple tasks simultaneously GPU enabled applications 2 / 45 CPU vs GPU CPU : consists of a few cores optimized for sequential serial processing GPU : has a massively parallel architecture consisting of thousands of smaller, more efficient cores designed for handling multiple tasks simultaneously GPU enabled applications 2 / 45 CPU vs GPU CPU : consists of a few cores optimized for sequential serial processing GPU : has a massively parallel architecture consisting of thousands of smaller, more efficient cores designed for handling multiple tasks simultaneously GPU enabled applications 2 / 45 3 / 45 Accelerate Application for GPU 4 / 45 GPU Accelerated Libraries 5 / 45 GPU Programming Languages 6 / 45 What is OpenACC? I OpenACC Application Program Interface describes a collection of compiler directive to specify loops and regions of code in standard C, C++ and Fortran to be offloaded from a host CPU to an attached accelerator. I provides portability across operating systems, host CPUs and accelerators History I OpenACC was developed by The Portland Group (PGI), Cray, CAPS and NVIDIA. I PGI, Cray, and CAPs have spent over 2 years developing and shipping commercial compilers that use directives to enable GPU acceleration as core technology.
  • Heterogeneous Task Scheduling for Accelerated Openmp

    Heterogeneous Task Scheduling for Accelerated Openmp

    Heterogeneous Task Scheduling for Accelerated OpenMP ? ? Thomas R. W. Scogland Barry Rountree† Wu-chun Feng Bronis R. de Supinski† ? Department of Computer Science, Virginia Tech, Blacksburg, VA 24060 USA † Center for Applied Scientific Computing, Lawrence Livermore National Laboratory, Livermore, CA 94551 USA [email protected] [email protected] [email protected] [email protected] Abstract—Heterogeneous systems with CPUs and computa- currently requires a programmer either to program in at tional accelerators such as GPUs, FPGAs or the upcoming least two different parallel programming models, or to use Intel MIC are becoming mainstream. In these systems, peak one of the two that support both GPUs and CPUs. Multiple performance includes the performance of not just the CPUs but also all available accelerators. In spite of this fact, the models however require code replication, and maintaining majority of programming models for heterogeneous computing two completely distinct implementations of a computational focus on only one of these. With the development of Accelerated kernel is a difficult and error-prone proposition. That leaves OpenMP for GPUs, both from PGI and Cray, we have a clear us with using either OpenCL or accelerated OpenMP to path to extend traditional OpenMP applications incrementally complete the task. to use GPUs. The extensions are geared toward switching from CPU parallelism to GPU parallelism. However they OpenCL’s greatest strength lies in its broad hardware do not preserve the former while adding the latter. Thus support. In a way, though, that is also its greatest weak- computational potential is wasted since either the CPU cores ness. To enable one to program this disparate hardware or the GPU cores are left idle.
  • Cimple: Instruction and Memory Level Parallelism a DSL for Uncovering ILP and MLP

    Cimple: Instruction and Memory Level Parallelism a DSL for Uncovering ILP and MLP

    Cimple: Instruction and Memory Level Parallelism A DSL for Uncovering ILP and MLP Vladimir Kiriansky, Haoran Xu, Martin Rinard, Saman Amarasinghe MIT CSAIL {vlk,haoranxu510,rinard,saman}@csail.mit.edu Abstract Processors have grown their capacity to exploit instruction Modern out-of-order processors have increased capacity to level parallelism (ILP) with wide scalar and vector pipelines, exploit instruction level parallelism (ILP) and memory level e.g., cores have 4-way superscalar pipelines, and vector units parallelism (MLP), e.g., by using wide superscalar pipelines can execute 32 arithmetic operations per cycle. Memory and vector execution units, as well as deep buffers for in- level parallelism (MLP) is also pervasive with deep buffering flight memory requests. These resources, however, often ex- between caches and DRAM that allows 10+ in-flight memory hibit poor utilization rates on workloads with large working requests per core. Yet, modern CPUs still struggle to extract sets, e.g., in-memory databases, key-value stores, and graph matching ILP and MLP from the program stream. analytics, as compilers and hardware struggle to expose ILP Critical infrastructure applications, e.g., in-memory databases, and MLP from the instruction stream automatically. key-value stores, and graph analytics, characterized by large In this paper, we introduce the IMLP (Instruction and working sets with multi-level address indirection and pointer Memory Level Parallelism) task programming model. IMLP traversals push hardware to its limits: large multi-level caches tasks execute as coroutines that yield execution at annotated and branch predictors fail to keep processor stalls low. The long-latency operations, e.g., memory accesses, divisions, out-of-order windows of hundreds of instructions are also or unpredictable branches.
  • Introduction to Multi-Threading and Vectorization Matti Kortelainen Larsoft Workshop 2019 25 June 2019 Outline

    Introduction to Multi-Threading and Vectorization Matti Kortelainen Larsoft Workshop 2019 25 June 2019 Outline

    Introduction to multi-threading and vectorization Matti Kortelainen LArSoft Workshop 2019 25 June 2019 Outline Broad introductory overview: • Why multithread? • What is a thread? • Some threading models – std::thread – OpenMP (fork-join) – Intel Threading Building Blocks (TBB) (tasks) • Race condition, critical region, mutual exclusion, deadlock • Vectorization (SIMD) 2 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization Motivations for multithreading Image courtesy of K. Rupp 3 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization Motivations for multithreading • One process on a node: speedups from parallelizing parts of the programs – Any problem can get speedup if the threads can cooperate on • same core (sharing L1 cache) • L2 cache (may be shared among small number of cores) • Fully loaded node: save memory and other resources – Threads can share objects -> N threads can use significantly less memory than N processes • If smallest chunk of data is so big that only one fits in memory at a time, is there any other option? 4 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization What is a (software) thread? (in POSIX/Linux) • “Smallest sequence of programmed instructions that can be managed independently by a scheduler” [Wikipedia] • A thread has its own – Program counter – Registers – Stack – Thread-local memory (better to avoid in general) • Threads of a process share everything else, e.g. – Program code, constants – Heap memory – Network connections – File handles
  • Scheduling Task Parallelism on Multi-Socket Multicore Systems

    Scheduling Task Parallelism on Multi-Socket Multicore Systems

    Scheduling Task Parallelism" on Multi-Socket Multicore Systems" Stephen Olivier, UNC Chapel Hill Allan Porterfield, RENCI Kyle Wheeler, Sandia National Labs Jan Prins, UNC Chapel Hill The University of North Carolina at Chapel Hill Outline" Introduction and Motivation Scheduling Strategies Evaluation Closing Remarks The University of North Carolina at Chapel Hill ! Outline" Introduction and Motivation Scheduling Strategies Evaluation Closing Remarks The University of North Carolina at Chapel Hill ! Task Parallel Programming in a Nutshell! • A task consists of executable code and associated data context, with some bookkeeping metadata for scheduling and synchronization. • Tasks are significantly more lightweight than threads. • Dynamically generated and terminated at run time • Scheduled onto threads for execution • Used in Cilk, TBB, X10, Chapel, and other languages • Our work is on the recent tasking constructs in OpenMP 3.0. The University of North Carolina at Chapel Hill ! 4 Simple Task Parallel OpenMP Program: Fibonacci! int fib(int n)! {! fib(10)! int x, y;! if (n < 2) return n;! #pragma omp task! fib(9)! fib(8)! x = fib(n - 1);! #pragma omp task! y = fib(n - 2);! #pragma omp taskwait! fib(8)! fib(7)! return x + y;! }! The University of North Carolina at Chapel Hill ! 5 Useful Applications! • Recursive algorithms cilksort cilksort cilksort cilksort cilksort • E.g. Mergesort • List and tree traversal cilkmerge cilkmerge cilkmerge cilkmerge cilkmerge cilkmerge • Irregular computations cilkmerge • E.g., Adaptive Fast Multipole cilkmerge cilkmerge
  • Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++

    Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++

    Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++ Christopher S. Zakian, Timothy A. K. Zakian Abhishek Kulkarni, Buddhika Chamith, and Ryan R. Newton Indiana University - Bloomington, fczakian, tzakian, adkulkar, budkahaw, [email protected] Abstract. Library and language support for scheduling non-blocking tasks has greatly improved, as have lightweight (user) threading packages. How- ever, there is a significant gap between the two developments. In previous work|and in today's software packages|lightweight thread creation incurs much larger overheads than tasking libraries, even on tasks that end up never blocking. This limitation can be removed. To that end, we describe an extension to the Intel Cilk Plus runtime system, Concurrent Cilk, where tasks are lazily promoted to threads. Concurrent Cilk removes the overhead of thread creation on threads which end up calling no blocking operations, and is the first system to do so for C/C++ with legacy support (standard calling conventions and stack representations). We demonstrate that Concurrent Cilk adds negligible overhead to existing Cilk programs, while its promoted threads remain more efficient than OS threads in terms of context-switch overhead and blocking communication. Further, it enables development of blocking data structures that create non-fork-join dependence graphs|which can expose more parallelism, and better supports data-driven computations waiting on results from remote devices. 1 Introduction Both task-parallelism [1, 11, 13, 15] and lightweight threading [20] libraries have become popular for different kinds of applications. The key difference between a task and a thread is that threads may block|for example when performing IO|and then resume again.
  • Parallel Programming

    Parallel Programming

    Parallel Programming Libraries and implementations Outline • MPI – distributed memory de-facto standard • Using MPI • OpenMP – shared memory de-facto standard • Using OpenMP • CUDA – GPGPU de-facto standard • Using CUDA • Others • Hybrid programming • Xeon Phi Programming • SHMEM • PGAS MPI Library Distributed, message-passing programming Message-passing concepts Explicit Parallelism • In message-passing all the parallelism is explicit • The program includes specific instructions for each communication • What to send or receive • When to send or receive • Synchronisation • It is up to the developer to design the parallel decomposition and implement it • How will you divide up the problem? • When will you need to communicate between processes? Message Passing Interface (MPI) • MPI is a portable library used for writing parallel programs using the message passing model • You can expect MPI to be available on any HPC platform you use • Based on a number of processes running independently in parallel • HPC resource provides a command to launch multiple processes simultaneously (e.g. mpiexec, aprun) • There are a number of different implementations but all should support the MPI 2 standard • As with different compilers, there will be variations between implementations but all the features specified in the standard should work. • Examples: MPICH2, OpenMPI Point-to-point communications • A message sent by one process and received by another • Both processes are actively involved in the communication – not necessarily at the same time • Wide variety of semantics provided: • Blocking vs. non-blocking • Ready vs. synchronous vs. buffered • Tags, communicators, wild-cards • Built-in and custom data-types • Can be used to implement any communication pattern • Collective operations, if applicable, can be more efficient Collective communications • A communication that involves all processes • “all” within a communicator, i.e.
  • Openmp API 5.1 Specification

    Openmp API 5.1 Specification

    OpenMP Application Programming Interface Version 5.1 November 2020 Copyright c 1997-2020 OpenMP Architecture Review Board. Permission to copy without fee all or part of this material is granted, provided the OpenMP Architecture Review Board copyright notice and the title of this document appear. Notice is given that copying is by permission of the OpenMP Architecture Review Board. This page intentionally left blank in published version. Contents 1 Overview of the OpenMP API1 1.1 Scope . .1 1.2 Glossary . .2 1.2.1 Threading Concepts . .2 1.2.2 OpenMP Language Terminology . .2 1.2.3 Loop Terminology . .9 1.2.4 Synchronization Terminology . 10 1.2.5 Tasking Terminology . 12 1.2.6 Data Terminology . 14 1.2.7 Implementation Terminology . 18 1.2.8 Tool Terminology . 19 1.3 Execution Model . 22 1.4 Memory Model . 25 1.4.1 Structure of the OpenMP Memory Model . 25 1.4.2 Device Data Environments . 26 1.4.3 Memory Management . 27 1.4.4 The Flush Operation . 27 1.4.5 Flush Synchronization and Happens Before .................. 29 1.4.6 OpenMP Memory Consistency . 30 1.5 Tool Interfaces . 31 1.5.1 OMPT . 32 1.5.2 OMPD . 32 1.6 OpenMP Compliance . 33 1.7 Normative References . 33 1.8 Organization of this Document . 35 i 2 Directives 37 2.1 Directive Format . 38 2.1.1 Fixed Source Form Directives . 43 2.1.2 Free Source Form Directives . 44 2.1.3 Stand-Alone Directives . 45 2.1.4 Array Shaping . 45 2.1.5 Array Sections .
  • Openmp Made Easy with INTEL® ADVISOR

    Openmp Made Easy with INTEL® ADVISOR

    OpenMP made easy with INTEL® ADVISOR Zakhar Matveev, PhD, Intel CVCG, November 2018, SC’18 OpenMP booth Why do we care? Ai Bi Ai Bi Ai Bi Ai Bi Vector + Processing Ci Ci Ci Ci VL Motivation (instead of Agenda) • Starting from 4.x, OpenMP introduces support for both levels of parallelism: • Multi-Core (think of “pragma/directive omp parallel for”) • SIMD (think of “pragma/directive omp simd”) • 2 pillars of OpenMP SIMD programming model • Hardware with Intel ® AVX-512 support gives you theoretically 8x speed- up over SSE baseline (less or even more in practice) • Intel® Advisor is here to assist you in: • Enabling SIMD parallelism with OpenMP (if not yet) • Improving performance of already vectorized OpenMP SIMD code • And will also help to optimize for Memory Sub-system (Advisor Roofline) 3 Don’t use a single Vector lane! Un-vectorized and un-threaded software will under perform 4 Permission to Design for All Lanes Threading and Vectorization needed to fully utilize modern hardware 5 A Vector parallelism in x86 AVX-512VL AVX-512BW B AVX-512DQ AVX-512CD AVX-512F C AVX2 AVX2 AVX AVX AVX SSE SSE SSE SSE Intel® microarchitecture code name … NHM SNB HSW SKL 6 (theoretically) 8x more SIMD FLOP/S compared to your (–O2) optimized baseline x - Significant leap to 512-bit SIMD support for processors - Intel® Compilers and Intel® Math Kernel Library include AVX-512 support x - Strong compatibility with AVX - Added EVEX prefix enables additional x functionality Don’t leave it on the table! 7 Two level parallelism decomposition with OpenMP: image processing example B #pragma omp parallel for for (int y = 0; y < ImageHeight; ++y){ #pragma omp simd C for (int x = 0; x < ImageWidth; ++x){ count[y][x] = mandel(in_vals[y][x]); } } 8 Two level parallelism decomposition with OpenMP: fluid dynamics processing example B #pragma omp parallel for for (int i = 0; i < X_Dim; ++i){ #pragma omp simd C for (int m = 0; x < n_velocities; ++m){ next_i = f(i, velocities(m)); X[i] = next_i; } } 9 Key components of Intel® Advisor What’s new in “2019” release Step 1.
  • GPU Computing with Openacc Directives

    GPU Computing with Openacc Directives

    Introduction to OpenACC Directives Duncan Poole, NVIDIA Thomas Bradley, NVIDIA GPUs Reaching Broader Set of Developers 1,000,000’s CAE CFD Finance Rendering Universities Data Analytics Supercomputing Centers Life Sciences 100,000’s Oil & Gas Defense Weather Research Climate Early Adopters Plasma Physics 2004 Present Time 3 Ways to Accelerate Applications Applications OpenACC Programming Libraries Directives Languages “Drop-in” Easily Accelerate Maximum Acceleration Applications Flexibility 3 Ways to Accelerate Applications Applications OpenACC Programming Libraries Directives Languages CUDA Libraries are interoperable with OpenACC “Drop-in” Easily Accelerate Maximum Acceleration Applications Flexibility 3 Ways to Accelerate Applications Applications OpenACC Programming Libraries Directives Languages CUDA Languages are interoperable with OpenACC, “Drop-in” Easily Accelerate too! Maximum Acceleration Applications Flexibility NVIDIA cuBLAS NVIDIA cuRAND NVIDIA cuSPARSE NVIDIA NPP Vector Signal GPU Accelerated Matrix Algebra on Image Processing Linear Algebra GPU and Multicore NVIDIA cuFFT Building-block Sparse Linear C++ STL Features IMSL Library Algorithms for CUDA Algebra for CUDA GPU Accelerated Libraries “Drop-in” Acceleration for Your Applications OpenACC Directives CPU GPU Simple Compiler hints Program myscience Compiler Parallelizes code ... serial code ... !$acc kernels do k = 1,n1 do i = 1,n2 OpenACC ... parallel code ... Compiler Works on many-core GPUs & enddo enddo Hint !$acc end kernels multicore CPUs ... End Program myscience
  • Parallelism in Cilk Plus

    Parallelism in Cilk Plus

    Cilk Plus: Language Support for Thread and Vector Parallelism Arch D. Robison Intel Sr. Principal Engineer Outline Motivation for Intel® Cilk Plus SIMD notations Fork-Join notations Karatsuba multiplication example GCC branch Copyright© 2012, Intel Corporation. All rights reserved. 2 *Other brands and names are the property of their respective owners. Multi-Threading and Vectorization are Essential to Performance Latest Intel® Xeon® chip: 8 cores 2 independent threads per core 8-lane (single prec.) vector unit per thread = 128-fold potential for single socket Intel® Many Integrated Core Architecture >50 cores (KNC) ? independent threads per core 16-lane (single prec.) vector unit per thread = parallel heaven Copyright© 2012, Intel Corporation. All rights reserved. 3 *Other brands and names are the property of their respective owners. Importance of Abstraction Software outlives hardware. Recompiling is easier than rewriting. Coding too closely to hardware du jour makes moving to new hardware expensive. C++ philosophy: abstraction with minimal penalty Do not expect compiler to be clever. But let it do tedious bookkeeping. Copyright© 2012, Intel Corporation. All rights reserved. 4 *Other brands and names are the property of their respective owners. “Three Layer Cake” Abstraction Message Passing exploit multiple nodes Fork-Join exploit multiple cores exploit parallelism at multiple algorithmic levels SIMD exploit vector hardware Copyright© 2012, Intel Corporation. All rights reserved. 5 *Other brands and names are the property of their respective owners. Composition Message Driven compose via send/receive Fork-Join compose via call/return SIMD compose sequentially Copyright© 2012, Intel Corporation. All rights reserved. 6 *Other brands and names are the property of their respective owners.