DOCSLIB.ORG

The Cilk System for Parallel Multithreaded Computing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Cilk System for Parallel Multithreaded Computing The Cilk System for Parallel Multithreaded Computing by Christopher F Jo erg Submitted to the Department of Electrical Engineering and Computer Science in partial fulllment of the requirements for the degree of Do ctor of Philosophy at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY January c Massachusetts Institute of Technology All rights reserved Author Department of Electrical Engineering and Computer Science January Certied by Charles E Leiserson Professor Thesis Sup ervisor Accepted by Frederic R Morgenthaler Chairman Departmental Committee on Graduate Students The Cilk System for Parallel Multithreaded Computing by Christopher F Jo erg Submitted to the Department of Electrical Engineering and Computer Science on January in partial fulllment of the requirements for the degree of Do ctor of Philosophy Abstract Although costeective parallel machines are now commercially available the widespread use of parallel pro cessing is still b eing held back due mainly to the troublesome nature of parallel programming In particular it is still dicult to build ecient implementations of parallel applications whose communication patterns are either highly irregular or dep endent up on dynamic information Multithreading has b ecome an increasingly p opular way to implement these dynamic asynchronous concurrent programs Cilk pronounced silk is our Cbased multithreaded computing system that provides provably go o d p erformance guarantees This thesis describ es the evolution of the Cilk language and runtime system and describ es applications which aected the evolution of the system Using Cilk programmers are able to express their applications either by writing mul tithreaded co de written in a continuationpassing style or by writing co de using normal callreturn semantics and sp ecifying which calls can b e p erformed in parallel The Cilk run time system takes complete control of the scheduling loadbalancing and communication needed to execute the program thereby insulating the programmer from these details The programmer can rest assured that his program will b e executed eciently since the Cilk scheduler provably achieves time space and communication b ounds all within a constant factor of optimal For distributed memory environments we have implemented a software sharedmemory system for Cilk We have dened a dagconsistent memory mo del which is a lo ckfree consistency mo del well suited to the needs of a multithreaded program Because dag consistency is a weak consistency mo del we have b een able to implement coherence eciently in software The most complex application written in Cilk is the So crates computer chess program So crates is a large nondeterministic challenging application whose complex control de p endencies make it inexpressible in many other parallel programming systems Running on an no de Paragon So crates nished second in the World Computer Chess Championship Currently versions of Cilk run on the Thinking Machines CM the Intel Paragon various SMPs and on networks of workstations The same Cilk program will run on all of these platforms with little if any mo dication Applications written in Cilk include protein folding graphic rendering backtrack search and computer chess Thesis Sup ervisor Charles E Leiserson Title Professor Acknowledgments I am esp ecially grateful to my thesis sup ervisor Professor Charles Leiserson who has led the Cilk pro ject I still remember the day he came to my oce and recruited me He explained how he realized I had other work to do but he wanted to know if I would like to help out part time on using the PCM system I had worked on to implement a chess program It sounded like a interesting pro ject so I agreed but only after making it clear that I could only work part time b ecause I had my thesis pro ject to work on Well part time b ecame full time and at times full time b ecame much more than that Eventually the chess program was completed and the chess tournament came and went yet I still kept working on the PCM system which was now turning into Cilk Ultimately I realized that I should give up on my other pro ject and make Cilk my thesis instead Charles is a wonderful sup ervisor and under his leadership the Cilk pro ject has achieved more than I ever exp ected Charles inuence can also b e seen in this writeup itself He has help ed me turn this thesis into a relatively coherent do cument and he has also p ointed out some of my more malo dorous grammatical constructions The Cilk pro ject has b een a team eort and I am indebted to all the p eople who have contributed in some way to the Cilk system Bobby Blumofe Feng Ming Dong Matteo Frigo Shail Aditya Gupta Michael Halbherr Charles Leiserson Bradley Kuszmaul Rob Miller Keith Randall Rolf Riesen Andy Shaw Richard Tauriello and Yuli Zhou Their contributions are noted throughout this do cument I thank along with the members of the Cilk team the past and present members of the Computation Structures Group These friends have made MIT b oth a challenging and a fun place to b e In particular I should thank Michael Halbherr He not only b egan the work that lead to the PCM system but he tried many times to convince me to switch my thesis to this system It to ok a while but I nally realized he was right I am also indebted to Don Dailey and Larry Kaufman b oth formerly of Heuristic Soft The research describ ed in this do cument was supp orted in part by the Advanced Research Pro jects Agency of the Department of Defense under grants N and NJ This work was also supp orted by the National Center for Sup ercomputing Applications at the University of Illinois at UrbanaChampagne NCSA who under NCSA Grant TRAN provided us access to their pro cessor CM for the chess tournament and by Sandia National Lab oratories who provided us access to their no de Intel Paragon for the tournament ware They wrote the serial So crates program on which So crates is based In addition Don and I sp ent many long nights debugging testing and improving or at least trying to improve So crates Most of this time we even had fun Professor Arvind Dr Andy Boughton and Dr Greg Papadopoulus also deserve many thanks They provided me the freedom encouragement and supp ort to work on a wide range of exciting pro jects throughout my years at MIT I am also grateful to my parents and my family Their love and supp ort has always b een imp ortant to me Last but not least I thank Constance Jeery Whether we were together apart or o on one of our many trips ranging from Anchorage to Zurich her continuing friendship over the past decade has made these years enjoyable and memorable Contents Introduction Life Before Cilk The Evolution of Cilk The PCM System Introduction The Parallel Continuation Machine Elements of the PCM The Thread Sp ecication Language Executing a PCM Program Tail Calls Passing Vectors in Closures Scheduling PCM Threads on a Multipro cessor Two Case Studies Ray Tracing Protein Folding Conclusions Cilk A Provably Go o d Runtime System Cilk Overview Cilk Programming Environment and Implementation Cilks WorkStealing Scheduler Performance of Cilk Applications Mo deling Performance Theoretical Analysis of the Cilk Scheduler Conclusion The So crates Parallel Chess Program Introduction Parallel Game Tree Search Negamax Search Without Pruning AlphaBeta Pruning Scout Search Jamboree Search Using Cilk for Chess Search Migration Threads Ab orting Computations Priority Threads Steal Ordering Level Waiting Other Chess Mechanisms Transposition Table Rep eated Moves Debugging Performance of Jamboree Search History of So crates Cilk Programming at a Higher Level A Cilk Example Knary The Cilk System Knary Revisited Conclusion Cilk Shared Memory for Cilk Introduction Dag Consistency Maintaining Dag Consistency Implementation An Analysis of Page Faults Conclusion Cilk Supp orting Sp eculative Computations
Load more

Recommended publications
  • 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.
    [Show full text]
  • Distributed & Cloud Computing: Lecture 1
    Distributed & cloud computing: Lecture 1 Chokchai “Box” Leangsuksun SWECO Endowed Professor, Computer Science Louisiana Tech University [email protected] CTO, PB Tech International Inc. [email protected] Class Info ■" Class Hours: noon-1:50 pm T-Th ! ■" Dr. Box’s & Contact Info: ●"www.latech.edu/~box ●"Phone 318-257-3291 ●"Email: [email protected] Class Info ■" Main Text: ! ●" 1) Distributed Systems: Concepts and Design By Coulouris, Dollimore, Kindberg and Blair Edition 5, © Addison-Wesley 2012 ●" 2) related publications & online literatures Class Info ■" Objective: ! ●"the theory, design and implementation of distributed systems ●"Discussion on abstractions, Concepts and current systems/applications ●"Best practice on Research on DS & cloud computing Course Contents ! •" The Characterization of distributed computing and cloud computing. •" System Models. •" Networking and inter-process communication. •" OS supports and Virtualization. •" RAS, Performance & Reliability Modeling. Security. !! Course Contents •" Introduction to Cloud Computing ! •" Various models and applications. •" Deployment models •" Service models (SaaS, PaaS, IaaS, Xaas) •" Public Cloud: Amazon AWS •" Private Cloud: openStack. •" Cost models ( between cloud vs host your own) ! •" ! !!! Course Contents case studies! ! •" Introduction to HPC! •" Multicore & openMP! •" Manycore, GPGPU & CUDA! •" Cloud-based EKG system! •" Distributed Object & Web Services (if time allows)! •" Distributed File system (if time allows)! •" Replication & Disaster Recovery Preparedness! !!!!!! Important Dates ! ■" Apr 10: Mid Term exam ■" Apr 22: term paper & presentation due ■" May 15: Final exam Evaluations ! ■" 20% Lab Exercises/Quizzes ■" 20% Programming Assignments ■" 10% term paper ■" 20% Midterm Exam ■" 30% Final Exam Intro to Distributed Computing •" Distributed System Definitions. •" Distributed Systems Examples: –" The Internet. –" Intranets. –" Mobile Computing –" Cloud Computing •" Resource Sharing. •" The World Wide Web. •" Distributed Systems Challenges. Based on Mostafa’s lecture 10 Distributed Systems 0.
    [Show full text]
  • Distributed Algorithms with Theoretic Scalability Analysis of Radial and Looped Load flows for Power Distribution Systems
    Electric Power Systems Research 65 (2003) 169Á/177 www.elsevier.com/locate/epsr Distributed algorithms with theoretic scalability analysis of radial and looped load flows for power distribution systems Fangxing Li *, Robert P. Broadwater ECE Department Virginia Tech, Blacksburg, VA 24060, USA Received 15 April 2002; received in revised form 14 December 2002; accepted 16 December 2002 Abstract This paper presents distributed algorithms for both radial and looped load flows for unbalanced, multi-phase power distribution systems. The distributed algorithms are developed from tree-based sequential algorithms. Formulas of scalability for the distributed algorithms are presented. It is shown that computation time dominates communication time in the distributed computing model. This provides benefits to real-time load flow calculations, network reconfigurations, and optimization studies that rely on load flow calculations. Also, test results match the predictions of derived formulas. This shows the formulas can be used to predict the computation time when additional processors are involved. # 2003 Elsevier Science B.V. All rights reserved. Keywords: Distributed computing; Scalability analysis; Radial load flow; Looped load flow; Power distribution systems 1. Introduction Also, the method presented in Ref. [10] was tested in radial distribution systems with no more than 528 buses. Parallel and distributed computing has been applied More recent works [11Á/14] presented distributed to many scientific and engineering computations such as implementations for power flows or power flow based weather forecasting and nuclear simulations [1,2]. It also algorithms like optimizations and contingency analysis. has been applied to power system analysis calculations These works also targeted power transmission systems. [3Á/14].
    [Show full text]
  • 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.
    [Show full text]
  • Grid Computing: What Is It, and Why Do I Care?*
    Grid Computing: What Is It, and Why Do I Care?* Ken MacInnis <[email protected]> * Or, “Mi caja es su caja!” (c) Ken MacInnis 2004 1 Outline Introduction and Motivation Examples Architecture, Components, Tools Lessons Learned and The Future Questions? (c) Ken MacInnis 2004 2 What is “grid computing”? Many different definitions: Utility computing Cycles for sale Distributed computing distributed.net RC5, SETI@Home High-performance resource sharing Clusters, storage, visualization, networking “We will probably see the spread of ‘computer utilities’, which, like present electric and telephone utilities, will service individual homes and offices across the country.” Len Kleinrock (1969) The word “grid” doesn’t equal Grid Computing: Sun Grid Engine is a mere scheduler! (c) Ken MacInnis 2004 3 Better definitions: Common protocols allowing large problems to be solved in a distributed multi-resource multi-user environment. “A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities.” Kesselman & Foster (1998) “…coordinated resource sharing and problem solving in dynamic, multi- institutional virtual organizations.” Kesselman, Foster, Tuecke (2000) (c) Ken MacInnis 2004 4 New Challenges for Computing Grid computing evolved out of a need to share resources Flexible, ever-changing “virtual organizations” High-energy physics, astronomy, more Differing site policies with common needs Disparate computing needs
    [Show full text]
  • 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.
    [Show full text]
  • Computing at Massive Scale: Scalability and Dependability Challenges
    This is a repository copy of Computing at massive scale: Scalability and dependability challenges. White Rose Research Online URL for this paper: http://eprints.whiterose.ac.uk/105671/ Version: Accepted Version Proceedings Paper: Yang, R and Xu, J orcid.org/0000-0002-4598-167X (2016) Computing at massive scale: Scalability and dependability challenges. In: Proceedings - 2016 IEEE Symposium on Service-Oriented System Engineering, SOSE 2016. 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE), 29 Mar - 02 Apr 2016, Oxford, United Kingdom. IEEE , pp. 386-397. ISBN 9781509022533 https://doi.org/10.1109/SOSE.2016.73 (c) 2016 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works. Reuse Unless indicated otherwise, fulltext items are protected by copyright with all rights reserved. The copyright exception in section 29 of the Copyright, Designs and Patents Act 1988 allows the making of a single copy solely for the purpose of non-commercial research or private study within the limits of fair dealing. The publisher or other rights-holder may allow further reproduction and re-use of this version - refer to the White Rose Research Online record for this item. Where records identify the publisher as the copyright holder, users can verify any specific terms of use on the publisher’s website. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request.
    [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]
  • Intel Threading Building Blocks
    Praise for Intel Threading Building Blocks “The Age of Serial Computing is over. With the advent of multi-core processors, parallel- computing technology that was once relegated to universities and research labs is now emerging as mainstream. Intel Threading Building Blocks updates and greatly expands the ‘work-stealing’ technology pioneered by the MIT Cilk system of 15 years ago, providing a modern industrial-strength C++ library for concurrent programming. “Not only does this book offer an excellent introduction to the library, it furnishes novices and experts alike with a clear and accessible discussion of the complexities of concurrency.” — Charles E. Leiserson, MIT Computer Science and Artificial Intelligence Laboratory “We used to say make it right, then make it fast. We can’t do that anymore. TBB lets us design for correctness and speed up front for Maya. This book shows you how to extract the most benefit from using TBB in your code.” — Martin Watt, Senior Software Engineer, Autodesk “TBB promises to change how parallel programming is done in C++. This book will be extremely useful to any C++ programmer. With this book, James achieves two important goals: • Presents an excellent introduction to parallel programming, illustrating the most com- mon parallel programming patterns and the forces governing their use. • Documents the Threading Building Blocks C++ library—a library that provides generic algorithms for these patterns. “TBB incorporates many of the best ideas that researchers in object-oriented parallel computing developed in the last two decades.” — Marc Snir, Head of the Computer Science Department, University of Illinois at Urbana-Champaign “This book was my first introduction to Intel Threading Building Blocks.
    [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]
  • Lecture 18: Parallel and Distributed Systems
    Lecture 18: Parallel and What is a distributed system? Distributed Systems n From various textbooks: u “A distributed system is a collection of independent computers n Classification of parallel/distributed that appear to the users of the system as a single computer.” architectures u “A distributed system consists of a collection of autonomous n SMPs computers linked to a computer network and equipped with n Distributed systems distributed system software.” u n Clusters “A distributed system is a collection of processors that do not share memory or a clock.” u “Distributed systems is a term used to define a wide range of computer systems from a weakly-coupled system such as wide area networks, to very strongly coupled systems such as multiprocessor systems.” 1 2 What is a distributed system?(cont.) What is a distributed system?(cont.) n Michael Flynn (1966) P1 P2 P3 u n A distributed system is Network SISD — single instruction, single data u SIMD — single instruction, multiple data a set of physically separate u processors connected by MISD — multiple instruction, single data u MIMD — multiple instruction, multiple data one or more P4 P5 communication links n More recent (Stallings, 1993) n Is every system with >2 computers a distributed system?? u Email, ftp, telnet, world-wide-web u Network printer access, network file access, network file backup u We don’t usually consider these to be distributed systems… 3 4 MIMD Classification parallel and distributed Classification of the OS of MIMD computers Architectures tightly loosely coupled
    [Show full text]
  • Openclunk: a Cilk-Like Framework for the GPGPU
    OpenCLunk: a Cilk-like framework for the GPGPU Lena Olson, Markus Peloquin {lena, markus}@cs December 20, 2010 Abstract models, tools, and languages that exist to exploit parallelism on CPUs. One example is the task-based The potential for GPUs to attain high speedup parallel language Cilk. It uses a simple but powerful over traditional multicore systems has made them extension of C to allow programmers to easily write a popular target for parallel programmers. However, code. they are notoriously difficult to program and debug. We decided to try to combine the elegance of Cilk Meanwhile, there are several programming models in with the acceleration of the GPU. From the start, the multicore domain which are designed to be sim- we knew that this would not be simple. Cilk is de- ple to design and program for, such as Cilk. Open- signed to be a task-parallel language, and GPUs ex- CLunk attempts to combine Cilk’s ease of program- cel at data parallelism. However, we thought that it ming with the good performance of the GPU. We might be advantageous to have a model that was sim- implemented a Cilk-like task-parallel programming ple to program, even if the speedup was more mod- framework for the GPU, and evaluated its perfor- est than the exceptional cases often cited. Therefore, mance. The results indicate that while it is possible we had several goals. The first was to simply imple- to implement such a system, it is not possible to ment a Cilk-like model, where Cilk programs could attain good performance, and therefore a Cilk-like be easily ported and run: something simple enough system is currently not feasible as a programming for a compiler to target.
    [Show full text]