DOCSLIB.ORG

A Comparison of Task Parallel Frameworks Based on Implicit Dependencies in Multi-Core Environments

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Comparison of Task Parallel Frameworks Based on Implicit Dependencies in Multi-Core Environments Proceedings of the 50th Hawaii International Conference on System Sciences | 2017 A Comparison of Task Parallel Frameworks based on Implicit Dependencies in Multi-core Environments Basilio B. Fraguela Universidade da Coruna,˜ A Coruna,˜ Spain Email: [email protected] Abstract—The larger flexibility that task parallelism offers minimum effort from the developers, while they allow to with respect to data parallelism comes at the cost of a higher build extremely complex task graphs and provide maximum complexity due to the variety of tasks and the arbitrary pat- parallelism thanks to the graph scheduling algorithms they terns of dependences that they can exhibit. These dependencies should be expressed not only correctly, but optimally, i.e. avoid- implement, makes them particularly interesting. ing over-constraints, in order to obtain the maximum perfor- Despite the relevance of this approach, we have not found mance from the underlying hardware. There have been many comparative studies of the existing practical alternatives proposals to facilitate this non-trivial task, particularly within of this kind beyond some performance comparisons [36]. the scope of nowadays ubiquitous multi-core architectures. A very interesting family of solutions because of their large For this reason this paper tackles this issue describing scope of application, ease of use and potential performance and comparing some of the high-level approaches available are those in which the user declares the dependences of each nowadays with a particular focus on their semantics and ease task, and lets the parallel programming framework figure out of use, our main aim being to help identify the best tool which are the concrete dependences that appear at runtime for each problem at hand. Also, while there are proposals and schedule accordingly the parallel tasks. Nevertheless, as far as we know, there are no comparative studies of them that that extend these ideas to clusters and hybrid systems, help users identify their relative advantages. In this paper we this study is restricted to the widely available multi-core describe and evaluate four tools of this class discussing the systems that are ubiquitous nowadays, so that the problems strengths and weaknesses we have found in their use. related to heterogeneity and distributed-memory are not Keywords-programmability; task parallelism; dependencies; considered. This way, we set some basic criteria to choose programming models the programming environments for our comparison: I. INTRODUCTION • Allow users to implicitly declare the task dependen- cies, automatically taking care of the concrete implied Many applications require the exploitation of task paral- synchronizations and scheduling. lelism to benefit from all the parallelism they can expose, • Provide a high-level API (i.e. oriented to final pro- and sometimes, just to be parallelized at all. With the need grammers), and be both publicly available and well to express different parallel tasks comes the requirement documented. to properly schedule and synchronize them according to • Be usable in some programming language among the the arbitrary patterns of dependences that they can exhibit. most widely used in the literature/research on parallel There is also of course the option to resort to speculation applications, mainly in the fields of scientific and engi- under Transactional Memory [20] or Thread Level Specula- neering computing. Besides, for fairness the compari- tion [28]. However, speculation typically has non-negligible son should use the same language for all the tools. This costs and a wide range of applications can be in fact implicitly discards proposals based on new languages, successfully parallelized by properly ordering the execution which besides being more complex to compare fairly, of their tasks so that their dependencies are fulfilled. While tend to have lower rates of adoption than compiler this has been done using low level approaches since the early directives and libraries, as these latter alternatives better days of parallel computing, the growing need to parallelize facilitate the reuse of existing codes. every kind of application together with the large availability • Do not require the usage of concepts or APIs related to of parallel systems, particularly since the appearance of distributed computing, which would distort the purely multi-core processors, led to the proposal of high-level ap- shared-memory based comparison. proaches that facilitate this task. Some of the most advanced programming tools in this category are those in which the Based on these criteria, four tools were chosen. A popular users just declare, as implicitly as possible, the dependencies strategy for the declaration of task dependences is the of their tasks, but without specifying how they must be annotation of the inputs and the outputs of each task together met, letting instead the underlying compiler and/or runtime with a valid order of execution, implicitly given by the automatically manage them. The fact that these tools require sequential execution of the tasks. Since the inclusion of URI: http://hdl.handle.net/10125/41914 ISBN: 978-0-9981331-0-2 CC-BY-NC-ND 6202 dependencies for tasks in OpenMP 4.0 [26] this standard forcing to use other OpenMP functionalities such as atomic is the most widespread option that supports this paradigm, operations or critical sections, or resort to other high level and thus the first we study. A very active and related project, constructs such as section or for. The other issue which in fact pushed for the adoption of dependent tasks in is related to the specification of multi-dimensional array OpenMP [11], is OmpSs, which integrates features from the regions when instead of a static or variable length array StarSS family of programming models [27]. While OpenMP we have a pointer, although this can be solved casting the and OmpSs cover well the space of compiler directives in pointer. our scope of interest, the area of libraries is much more We find much more relevant other limitations. For ex- sparse. Because our focus here is on the semantics and the ample, the standard requires the dependent items to have programming style, we will discuss the two libraries that fit either identical or disjoint storage. This means that if array our criteria and that we find to be more original in their sections appear in the lists of dependences, they must be approach. Both of them are based on C++, which is not either identical or disjunct. Similarly, the standard explicitly surprising given the excellent properties of this language states that a variable that is part of another variable (such to enable high performance coupled with ease of use. In as a field of a structure) but is not an array element or an fact, the first library, DepSpawn [16], heavily relies on the array section cannot appear in a depend clause, which again properties of this language to minimize the effort of the points to the unavailability of tests on partial overlaps of programmer. The second library is Intel R CnC (Concurrent objects. In fact OpenMP does not allow data members in its Collections) [6], [8], whose main interest lies in its very clauses, which restricts the usefulness of this framework in original approach for the specification of the dependences. programs with composite data types other than arrays. The rest of this paper is organized as follows. Section II A problem of OpenMP that is specific to C++ is its treat- describes the main characteristics of the frameworks ana- ment of references. While references are implemented under lyzed. They are then compared in terms of performance the hood by means of pointers, this is never exposed to the and programmability in Section III. This is followed by a programmers, who just see and use them as alias to existing discussion on related work in Section IV, and the last Section data items. OpenMP however considers references as what is devoted to our conclusions. they are actually for the compiler (pointers) and in fact pro- hibits reference types for private, firstprivate and II. FRAMEWORKS threadprivate variables, because the compiler would The frameworks analyzed are now described in turn. In privatize the reference, not the object accessed through it, all the cases we only center on the creation of dependent giving place to a wrong behavior. For the same reasons, tasks, skipping other possible functionalities, even if they are references, which are heavily used in C++ applications both needed to exploit this paradigm. A clear example are explicit for performance and programmability reasons, are not suited synchronizations, which are required even if only to make to express dependences for OpenMP tasks. sure that all the parallel tasks have completed before leaving the program. Also, since the libraries tested are based on B. OmpSs C++, making it the natural language for our comparison, the Dependent tasks are the core of the OmpSs programming specific problems found in the use of the compiler directives model [27], [3]. Task creation follows the OpenMP syntax in this language will be described. with a slight difference in the specification of dependencies. Namely, they are provided using three different clauses A. OpenMP in(list), out(list) and inout(list), which ex- The well-known OpenMP standard extended in [26] the press input, output and both input and output dependences on task construct introduced in version 3.0 [2] with support the memory positions provided in the list, respectively. The for task dependences by means of the depend clause. The dependences are enforced with respect to preceding tasks clause allows to define lists of data items that are only built in the same task or outside any task code, as OmpSs inputs, only outputs, or both input and outputs using the programs assume that their execution begins with a master notation depend(dependence-type : list) where thread that can spawn tasks to other threads at any point.
Load more

Recommended publications
  • 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.
    [Show full text]
  • 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
    [Show full text]
  • 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
    [Show full text]
  • Task Parallelism Bit-Level Parallelism
    Parallel languages as extensions of sequential ones Alexey A. Romanenko [email protected] What this section about? ● Computers. History. Trends. ● What is parallel program? ● What is parallel programming for? ● Features of parallel programs. ● Development environment. ● etc. Agenda 1. Sequential program 2. Applications, required computational power. 3. What does parallel programming for? 4. Parallelism inside ordinary PC. 5. Architecture of modern CPUs. 6. What is parallel program? 7. Types of parallelism. Agenda 8. Types of computational installations. 9. Specificity of parallel programs. 10.Amdahl's law 11.Development environment 12.Approaches to development of parallel programs. Cost of development. 13.Self-test questions History George Boole Claude Elwood Shannon Alan Turing Charles Babbage John von Neumann Norbert Wiener Henry Edward Roberts Sciences ● Computer science is the study of the theoretical foundations of information and computation, and of practical techniques for their implementation and application in computer systems. ● Cybernetics is the interdisciplinary study of the structure of regulatory system Difference machine Arithmometer Altair 8800 Computer with 8-inch floppy disk system Sequential program A program perform calculation of a function F = G(X) for example: a*x2+b*x+c=0, a != 0. x1=(-b-sqrt(b2-4ac))/(2a), x2=(-b+sqrt(b2-4ac))/(2a) Turing machine Plasma modeling N ~ 106 dX ~ F dT2 j j F ~ sum(q, q ) j i i j Complexity ~ O(N*N) more then 1012 * 100...1000 operations Resource consumable calculations ● Nuclear/Gas/Hydrodynamic
    [Show full text]
  • A CPU/GPU Task-Parallel Runtime with Explicit Epoch Synchronization
    TREES: A CPU/GPU Task-Parallel Runtime with Explicit Epoch Synchronization Blake A. Hechtman, Andrew D. Hilton, and Daniel J. Sorin Department of Electrical and Computer Engineering Duke University Abstract —We have developed a task-parallel runtime targeting CPUs are a poor fit for GPUs. To understand system, called TREES, that is designed for high why this mismatch exists, we must first understand the performance on CPU/GPU platforms. On platforms performance of an idealized task-parallel application with multiple CPUs, Cilk’s “work-first” principle (with no runtime) and then how the runtime’s overhead underlies how task-parallel applications can achieve affects it. The performance of a task-parallel application performance, but work-first is a poor fit for GPUs. We is a function of two characteristics: its total amount of build upon work-first to create the “work-together” work to be performed (T1, the time to execute on 1 principle that addresses the specific strengths and processor) and its critical path (T∞, the time to execute weaknesses of GPUs. The work-together principle on an infinite number of processors). Prior work has extends work-first by stating that (a) the overhead on shown that the runtime of a system with P processors, the critical path should be paid by the entire system at TP, is bounded by = ( ) + ( ) due to the once and (b) work overheads should be paid co- greedy o ff line scheduler bound [3][10]. operatively. We have implemented the TREES runtime A task-parallel runtime introduces overheads and, for in OpenCL, and we experimentally evaluate TREES purposes of performance analysis, we distinguish applications on a CPU/GPU platform.
    [Show full text]
  • An Overview of Parallel Ccomputing
    An Overview of Parallel Ccomputing Marc Moreno Maza University of Western Ontario, London, Ontario (Canada) CS2101 Plan 1 Hardware 2 Types of Parallelism 3 Concurrency Platforms: Three Examples Cilk CUDA MPI Hardware Plan 1 Hardware 2 Types of Parallelism 3 Concurrency Platforms: Three Examples Cilk CUDA MPI Hardware von Neumann Architecture In 1945, the Hungarian mathematician John von Neumann proposed the above organization for hardware computers. The Control Unit fetches instructions/data from memory, decodes the instructions and then sequentially coordinates operations to accomplish the programmed task. The Arithmetic Unit performs basic arithmetic operation, while Input/Output is the interface to the human operator. Hardware von Neumann Architecture The Pentium Family. Hardware Parallel computer hardware Most computers today (including tablets, smartphones, etc.) are equipped with several processing units (control+arithmetic units). Various characteristics determine the types of computations: shared memory vs distributed memory, single-core processors vs multicore processors, data-centric parallelism vs task-centric parallelism. Historically, shared memory machines have been classified as UMA and NUMA, based upon memory access times. Hardware Uniform memory access (UMA) Identical processors, equal access and access times to memory. In the presence of cache memories, cache coherency is accomplished at the hardware level: if one processor updates a location in shared memory, then all the other processors know about the update. UMA architectures were first represented by Symmetric Multiprocessor (SMP) machines. Multicore processors follow the same architecture and, in addition, integrate the cores onto a single circuit die. Hardware Non-uniform memory access (NUMA) Often made by physically linking two or more SMPs (or multicore processors).
    [Show full text]
  • HP-CAST 20 Final Agenda V3.0 (Sessions and Chairs Are Subject to Change Without Notice)
    HP Consortium for Advanced Scientific and Technical Computing World-Wide User Group Meeting ISS Hyperscale and HPC Organization The Westin Hotel Leipzig HP-CAST 20 Final Agenda V3.0 (Sessions and chairs are subject to change without notice) Supported by: Thursday, June 13th – Registration & Get-Together 18:00 – 22:00 Registration 18:00 – 22:00 Welcome Reception for All Attendees – Sky Bar FALCO at the Westin Hotel Friday, June 14th – Conference Section 08:00 – 18:00 Registration Board Introduction and HP Executive Updates HP-Liaison Frank Baetke, HP 08:15 – 09:20 HP-CAST President Rudolf Lohner, KIT/SCC HP Executive Updates on HPC Trends Paul Santeler, HP Scott Misage, HP Invited Partner Keynotes and Updates 09:20 – 09:50 High-Performance Computing Trends in the Georg Scheuerer, ANSYS Europe Manufacturing Industry 09:50 – 10:00 Making HPC Simulation Access Easier Benoît Vautrin, OVH (Oxalya) France 10:00 – 10:30 Break Invited Customer Keynotes 10:30 – 11:00 IT Infrastructure for HPC and Challenges of HPC Wolfgang Burke, BMW Germany Collocation at BMW 11:00 – 11:20 Deployment of HP Clusters in Iceland Guõbrandur R. Sigurõsson, Opin Kerfi Iceland 11:20 – 11:30 Q&A Session Short Processor Technology Updates Roberto Dognini, AMD Karl Freund, Calxeda (ARM) 11:30 – 12:30 John Hengeveld, Intel Timothy Lanfear, NVIDIA Sanjay Bhal, TI (ARM/DSP) 12:30 – 13:30 Lunch Friday, June 14th – Conference Section Attention: ATTENDANCE RESTRICTIONS APPLY Platforms and Products – #1 In Detail Roadmaps & Updates for Ed Turkel, HP 13:30 – 14:00 - Next Generation
    [Show full text]
  • Task Level Parallelism
    Task Level Parallelism The topic of this chapter is thread-level parallelism. While, thread-level parallelism falls within the textbook’s classification of ILP and data parallelism. It also falls into a broader topic of parallel and distributed computing. In the next set of slides, I will attempt to place you in the context of this broader computation space that is called task level parallelism. Of course a proper treatment of parallel computing or distributed computing is worthy of an entire semester (or two) course of study. I can only give you a brief exposure to this topic. The text highlighted in green in these slides contain external hyperlinks. 1 / 14 Classification of Parallelism Software Sequential Concurrent Serial Some problem written as a se- Some problem written as a quential program (the MATLAB concurrent program (the O/S example from the textbook). example from the textbook). Execution on a serial platform. Execution on a serial platform. Parallel Some problem written as a se- Some problem written as a quential program (the MATLAB concurrent program (the O/S Hardware example from the textbook). example from the textbook). Execution on a parallel plat- Execution on a parallel plat- form. form. 2 / 14 Flynn’s Classification of Parallelism CU: control unit SM: shared memory DS1 PU MM PU: processor unit IS: instruction stream 1 1 MM: memory unit DS: data stream DS2 PU MM IS 2 2 CU IS SM IS DS CU PU MM DSn PUn MMm (a) SISD computer IS (b) SIMD computer IS1 IS1 IS1 IS1 IS1 DS1 CU PU DS CU PU MM 1 1 1 1 1 SM IS2 IS2 IS2 IS2 DS2 CU PU CU PU MM IS2 2 2 2 2 2 MM MM MM 1 2 m SM ISn ISn ISn ISn ISn DSn IS CUnPU n DS 2 CUnPU n MMm IS1 ISn (c) MISD computer (d) MIMD computer 3 / 14 Task Level Parallelism I Task Level Parallelism: organizing a program or computing solution into a set of processes/tasks/threads for simultaneous execution.
    [Show full text]
  • Unified Parallel C for GPU Clusters: Language Extensions and Compiler Implementation
    Unified Parallel C for GPU Clusters: Language Extensions and Compiler Implementation Li Chen1, Lei Liu1, Shenglin Tang1, Lei Huang2, Zheng Jing1, Shixiong Xu1, Dingfei Zhang1, Baojiang Shou1 1 Key Laboratory of Computer System and Architecture, Institute of Computing Technology, Chinese Academy of Sciences, China {lchen,liulei2007,tangshenglin,jingzheng,xushixiong, zhangdingfei, shoubaojiang}@ict.ac.cn; 2 Department of Computer Science, University of Houston; Houston, TX, USA [email protected] 5 Abstract. Unified Parallel C (UPC), a parallel extension to ANSI C, is designed for high performance computing on large-scale parallel machines. With General-purpose graphics processing units (GPUs) becoming an increasingly important high performance computing platform, we propose new language extensions to UPC to take advantage of GPU clusters. We extend UPC with hierarchical data distribution, revise the execution model of UPC to mix SPMD with fork-join execution model, and modify the semantics of upc_forall to reflect the data-thread affinity on a thread hierarchy. We implement the compiling system, including affinity-aware loop tiling, GPU code generation, and several memory optimizations targeting NVIDIA CUDA. We also put forward unified data management for each UPC thread to optimize data transfer and memory layout for separate memory modules of CPUs and GPUs. The experimental results show that the UPC extension has better programmability than the mixed MPI/CUDA approach. We also demonstrate that the integrated compile-time and runtime optimization is effective to achieve good performance on GPU clusters. 1 Introduction Following closely behind the industry-wide move from uniprocessor to multi-core and many-core systems, HPC computing platforms are undergoing another major change: from homogeneous to heterogeneous platform.
    [Show full text]
  • Presentación De Powerpoint
    CENTRO DE SUPERCOMPUTACIÓN DE GALICIA High Scalability Multipole Method. Solving Half Billion of Unknowns J.C. Mouriño¹, A. Gómez¹, J.M. Taboada², L. Landesa², J.M. Bértolo³, F. Obelleiro³, J.L. Rodríguez³ ¹ Supercomputing Center of Galicia (CESGA), Spain ² University of Extremadura, Spain ³ University of Vigo, Spain International Supercomputing Conference Hamburg, June 23th 2009 Outline • Introduction • FMM-FFT algorithm • Parallel implementation • HEMCUVE. Challenge history • Experimental Results • Conclusions 2 Introduction • Numerical solution of the integro-differential electromagnetic equations -> important in industry • High frequency in large objects -> scalability limits – 0.78 m² at 3 GHz -> 15000 unknowns – real car at 79 GHz -> 400 million unknowns • Great effort reducing computational time of MoM • Fast Multipole Method (FMM) -> O(N³/²) good scalability • Multilevel FMM (MLFMA) -> O(N log N) poor scalability • Modern HPC systems have thousands of cores • FMM-FFT reduces complexity preserving scalability 3 Introduction • FMM – The geometry is partitioned into M groups using an oct-tree decomposition algorithm – Parallelization: • k-space samples are independent from one another • The workload can be partitioned in the k-space • MLFMA – The same algorithm can be recursively applied in a hierarchical multilevel oct-tree decomposition – Computational cost reduced to O(N log N) – Parallelization: • k-space samples are not independent due to interpolation/ anterpolation of fields across levels • Usually workload distributed by
    [Show full text]
  • Exploring the Use of Hyper-Threading Technology for Multimedia Applications with Intel£ Openmp Compiler
    Exploring the Use of Hyper-Threading Technology for Multimedia Applications with Intel£ OpenMP Compiler Xinmin Tian1, Yen-Kuang Chen2,3, Milind Girkar1, Steven Ge3, Rainer Lienhart2, Sanjiv Shah4 1Intel Compiler Labs, Software Solution Group, Intel Corporation 2Microprocessor Research, Intel Labs, Intel Corporation 1,23600 Juliette Lane, Santa Clara, CA 95052, USA 3Intel China Research Center, Intel Corporation 4KAI Software Lab, Intel Corporation, 1906 Fox Drive, Champaign, IL 61820, USA {Xinmin.Tian, Yen-kuang.Chen, Milind.Girkar, Steven.Ge, Rainer.Lienhart, Sanjiv.Shah}@intel.com Abstract single application or two separate applications to execute in Processors with Hyper-Threading technology can improve the parallel, increasing processor utilization and reducing the impact performance of applications by permitting a single processor to of memory latency by overlapping the latency of one thread with process data as if it were two processors by executing instructions the execution of another from different threads in parallel rather than serially. However, Hyper-Threading technology-enabled processors offer significant the potential performance improvement can be only obtained if an performance improvements for applications with a high degree of application is multithreaded by parallelization techniques. This thread-level parallelism without sacrificing compatibility with the paper presents the threaded code generation and optimization existing software or single-threaded performance. These potential techniques in the Intel C++/Fortran compiler. We conduct the performance gains are only obtained, however, if an application is performance study of two multimedia applications parallelized efficiently multithreaded. The Intel C++/Fortran compilers support ∗ with OpenMP pragmas and compiled with the Intel compiler on OpenMP directive- and pragma-guided parallelization, which the Hyper-Threading technology (HT) enabled Intel single- significantly increase the domain of various applications amenable processor and multi-processor systems.
    [Show full text]
  • Prace6ip-D7.1
    E-Infrastructures H2020- INFRAEDI-2018-2020 INFRAEDI-01-2018: Pan-European High Performance Computing infrastructure and services (PRACE) PRACE-6IP PRACE Sixth Implementation Phase Project Grant Agreement Number: INFRAEDI-823767 D7.1 Periodic Report on Results from Projects Supported by Applications Enabling and Porting Services Final Version: 1.0 Author(s): Gabriel Hautreux, CINES; Chris Johnson, EPCC; Sebastian Lührs, JUELICH Date: 16.10.2020 D7.1 Periodic Report on Results from Projects Supported by Applications Enabling and Porting Services Project and Deliverable Information Sheet PRACE Project Project Ref. №: INFRAEDI-823767 Project Title: PRACE Sixth Implementation Phase Project Project Web Site: http://www.prace-project.eu Deliverable ID: D7.1 Deliverable Nature: Report Dissemination Level: Contractual Date of Delivery: PU* 30 / October / 2020 Actual Date of Delivery: 30 / October / 2020 EC Project Officer: Leonardo Flores Añover * - The dissemination level are indicated as follows: PU – Public, CO – Confidential, only for members of the consortium (including the Commission Services) CL – Classified, as referred to in Commission Decision 2005/444/EC. Document Control Sheet Title: Periodic Report on Results from Projects Supported by Document Applications Enabling and Porting Services ID: D7.1 Version: <1.0> Status: Final Available at: http://www.prace-project.eu Software Tool: Microsoft Word 2016 File(s): D7.1.docx Written by: Gabriel Hautreux, CINES; Chris Johnson, Authorship EPCC; Sebastian Lührs, JUELICH Contributors: Adam
    [Show full text]