物件導向軟體之架構(Object-Oriented Software Construction)探討

Author(s): Asanovic, K; Bodik, R; Catanzaro, B; Gebis, J; Husbands, P; Keutzer, K; Patterson, D; Plishker, W; Shalf, J; Williams, SW | Abstract: The recent switch to parallel microprocessors is a milestone in the history of computing. Industry has laid out a roadmap for multicore designs that preserves the programming paradigm of the past via binary compatibility and cache coherence. Conventional wisdom is now to double the number of cores on a chip with each silicon generation. A multidisciplinary group of Berkeley researchers met nearly two years to discuss this change. Our view is that this evolutionary approach to parallel hardware and software may work from 2 or 8 processor systems, but is likely to face diminishing returns as 16 and 32 processor systems are realized, just as returns fell with greater instruction-level parallelism. We believe that much can be learned by examining the success of parallelism at the extremes of the computing spectrum, namely embedded computing and high performance computing. This led us to frame the parallel landscape with seven questions, and to recommend the following: • The overarching goal should be to make it easy to write programs that execute efficiently on highly parallel computing systems • The target should be 1000s of cores per chip, as these chips are built from processing elements that are the most efficient in MIPS (Million Instructions per Second) per watt, MIPS per area of silicon, and MIPS per development dollar. • Instead of traditional benchmarks, use 13 “Dwarfs” to design and evaluate parallel programming models and architectures. (A dwarf is an algorithmic method that captures a pattern of computation and communication.) • “Autotuners” should play a larger role than conventional compilers in translating parallel programs. • To maximize programmer productivity, future programming models must be more human-centric than the conventional focus on hardware or applications. • To be successful, programming models should be independent of the number of processors. • To maximize application efficiency, programming models should support a wide range of data types and successful models of parallelism: task-level parallelism, word-level parallelism, and bit-level parallelism. 1 The Landscape of Parallel Computing Research: A View From Berkeley • Architects should not include features that significantly affect performance or energy if programmers cannot accurately measure their impact via performance counters and energy counters. • Traditional operating systems will be deconstructed and operating system functionality will be orchestrated using libraries and virtual machines. • To explore the design space rapidly, use system emulators based on Field Programmable Gate Arrays (FPGAs) that are highly scalable and low cost. Since real world applications are naturally parallel and hardware is naturally parallel, what we need is a programming model, system software, and a supporting architecture that are naturally parallel. Researchers have the rare opportunity to re-invent these cornerstones of computing, provided they simplify the efficient programming of highly parallel systems.

/pdf/the-landscape-of-parallel-computing-research-a-view-from-1i5pswggnf.pdf

The Landscape of Parallel Computing Research: A View from Berkeley

Computer architecture is about to undergo, if not another revolution, then a vigorous shaking-up. The major chip manufacturers have, for the time being, simply given up trying to make processors run faster. Instead, they have recently started shipping "multicore" architectures, in which multiple processors (cores) communicate directly through shared hardware caches, providing increased concurrency instead of increased clock speed.As a result, system designers and software engineers can no longer rely on increasing clock speed to hide software bloat. Instead, they must somehow learn to make effective use of increasing parallelism. This adaptation will not be easy. Conventional synchronization techniques based on locks and conditions are unlikely to be effective in such a demanding environment. Coarse-grained locks, which protect relatively large amounts of data, do not scale, and fine-grained locks introduce substantial software engineering problem.Transactional memory is a computational model in which threads synchronize by optimistic, lock-free transactions. This synchronization model promises to alleviate many (not all) of the problems associated with locking, and there is a growing community of researchers working on both software and hardware support for this approach. This talk will survey the area, with a focus on open research problems.

The Art of Multiprocessor Programming

This paper evaluates the suitability of the MapReduce model for multi-core and multi-processor systems. MapReduce was created by Google for application development on data-centers with thousands of servers. It allows programmers to write functional-style code that is automatically parallelized and scheduled in a distributed system. We describe Phoenix, an implementation of MapReduce for shared-memory systems that includes a programming API and an efficient runtime system. The Phoenix runtime automatically manages thread creation, dynamic task scheduling, data partitioning, and fault tolerance across processor nodes. We study Phoenix with multi-core and symmetric multiprocessor systems and evaluate its performance potential and error recovery features. We also compare MapReduce code to code written in lower-level APIs such as P-threads. Overall, we establish that, given a careful implementation, MapReduce is a promising model for scalable performance on shared-memory systems with simple parallel code

/pdf/evaluating-mapreduce-for-multi-core-and-multiprocessor-1xfheav61u.pdf

Evaluating MapReduce for Multi-core and Multiprocessor Systems

Transactional Memory (TM) is emerging as a promising technology to simplify parallel programming. While several TM systems have been proposed in the research literature, we are still missing the tools and workloads necessary to analyze and compare the proposals. Most TM systems have been evaluated using microbenchmarks, which may not be representative of any real-world behavior, or individual applications, which do not stress a wide range of execution scenarios. We introduce the Stanford Transactional Application for Multi-Processing (STAMP), a comprehensive benchmark suite for evaluating TM systems. STAMP includes eight applications and thirty variants of input parameters and data sets in order to represent several application domains and cover a wide range of transactional execution cases (frequent or rare use of transactions, large or small transactions, high or low contention, etc.). Moreover, STAMP is portable across many types of TM systems, including hardware, software, and hybrid systems. In this paper, we provide descriptions and a detailed characterization of the applications in STAMP. We also use the suite to evaluate six different TM systems, identify their shortcomings, and motivate further research on their performance characteristics.

/pdf/stamp-stanford-transactional-applications-for-multi-5ascbp3x5h.pdf

STAMP: Stanford Transactional Applications for Multi-Processing

Transactional memory (TM) promises to substantially reduce the difficulty of writing correct, efficient, and scalable concurrent programs But "bounded" and "best-effort" hardware TM proposals impose unreasonable constraints on programmers, while more flexible software TM implementations are considered too slow Proposals for supporting "unbounded" transactions in hardware entail significantly higher complexity and risk than best-effort designsWe introduce Hybrid Transactional Memory (HyTM), an approach to implementing TMin software so that it can use best effort hardware TM (HTM) to boost performance but does not depend on HTM Thus programmers can develop and test transactional programs in existing systems today, and can enjoy the performance benefits of HTM support when it becomes availableWe describe our prototype HyTM system, comprising a compiler and a library The compiler allows a transaction to be attempted using best-effort HTM, and retried using the software library if it fails We have used our prototype to "transactify" part of the Berkeley DB system, as well as several benchmarks By disabling the optional use of HTM, we can run all of these tests on existing systems Furthermore, by using a simulated multiprocessor with HTM support, we demonstrate the viability of the HyTM approach: it can provide performance and scalability approaching that of an unbounded HTM implementation, without the need to support all transactions with complicated HTM support

/pdf/hybrid-transactional-memory-2ryzzt38xy.pdf

Hybrid transactional memory

We report on our experience with the hardware transactional memory (HTM) feature of two pre-production revisions of a new commercial multicore processor. Our experience includes a number of promising results using HTM to improve performance in a variety of contexts, and also identifies some ways in which the feature could be improved to make it even better. We give detailed accounts of our experiences, sharing techniques we used to achieve the results we have, as well as describing challenges we faced in doing so.

/pdf/early-experience-with-a-commercial-hardware-transactional-1bqxih3ubo.pdf

Early experience with a commercial hardware transactional memory implementation

The non-blocking work-stealing algorithm of Arora, Blumofe, and Plaxton (henceforth ABP work-stealing) is on its way to becoming the multiprocessor load balancing technology of choice in both industry and academia. This highly efficient scheme is based on a collection of array-based double-ended queues (deques) with low cost synchronization among local and stealing processes. Unfortunately, the algorithm's synchronization protocol is strongly based on the use of fixed size arrays, which are prone to overflows, especially in the multiprogrammed environments for which they are designed. We present a work-stealing deque that does not have the overflow problem.The only ABP-style work-stealing algorithm that eliminates the overflow problem is the list-based one presented by Hendler, Lev and Shavit. Their algorithm indeed deals with the overflow problem, but it is complicated, and introduces a trade-off between the space and time complexity, due to the extra work required to maintain the list.Our new algorithm presents a simple lock-free work-stealing deque, which stores the elements in a cyclic array that can grow when it overflows. The algorithm has no limit other than integer overflow (and the system's memory size) on the number of elements that may be on the deque, and the total memory required is linear in the number of elements in the deque.

Dynamic circular work-stealing deque

fill(f : I → E) : ReadableArrayJE, IK abstract fill(v :E) : ReadableArrayJE, IK abstract copy() : ReadableArrayJE, IK Create a fresh array structurally identical to the present one, but holding elements of type U . abstract replicaJUK() : ReadableArrayJU, IK opr =(self, other : HasRank): Boolean end trait ImmutableArrayJE, IK extends {ReadableArrayJE, IK } excludes {ArrayJE, IK } abstract opr [r : RangeJIK] : ImmutableArrayJE, IK abstract opr [ : OpenRangeJAnyK] : ImmutableArrayJE, IK abstract ivmapJRK(f : (I, E)→ R): ImmutableArrayJR, IK abstract mapJRK(f :E → R): ImmutableArrayJR, IK abstract shift(newOrigin : I) : ImmutableArrayJE, IK abstract init(i : I, v :E): () abstract fill(f : I → E) : ImmutableArrayJE, IK abstract fill(v :E) : ImmutableArrayJE, IK abstract copy() : ImmutableArrayJE, IK abstract replicaJUK() : ImmutableArrayJU, IK Thaw array (return mutable copy). abstract thaw() : ArrayJE, IK end trait ArrayJE, IK extends {ReadableArrayJE, IK,MutableIndexedJE, IK } abstract opr [r : RangeJIK] : ArrayJE, IK abstract opr [ : OpenRangeJAnyK] : ArrayJE, IK abstract ivmapJRK(f : (I, E)→ R): ArrayJR, IK abstract mapJRK(f :E → R): ArrayJR, IK abstract shift(newOrigin : I) : ArrayJE, IK abstract init(i : I, v :E): () abstract fill(f : I → E) : ArrayJE, IK abstract fill(v :E) : ArrayJE, IK abstract assign(f : I → E) : ArrayJE, IK abstract copy() : ArrayJE, IK abstract replicaJUK() : ArrayJU, IK Freeze array (return mutable copy). abstract freeze(): ImmutableArrayJE, IK end Factory for arrays that returns an empty 0-indexed array of a given run-time-determined size. arrayJEK(x :Z32) : ArrayJE,Z32K arrayJEK(x :Z32, y :Z32) :ArrayJE, (Z32,Z32)K arrayJEK(x :Z32, y :Z32, z :Z32) : ArrayJE, (Z32,Z32,Z32)K Factory for immutable arrays that returns an empty 0-indexed array of a given run-time-determined size.

The Fortress Language Specification

Transactional memory (TM) is a promising synchronization mechanism for the next generation of multicore processors. Best-effort Hardware Transactional Memory (HTM) designs, such as Sun's prototype Rock processor and AMD's proposed Advanced Synchronization Facility (ASF), can efficiently execute many transactions, but abort in some cases due to various limitations. Hybrid TM systems can use a compatible software TM (STM) in such cases.We introduce a family of hybrid TMs built using the recent NOrec STM algorithm that, unlike existing hybrid approaches, provide both low overhead on hardware transactions and concurrent execution of hardware and software transactions. We evaluate implementations for Rock and ASF, exploring how the differing HTM designs affect optimization choices. Our investigation yields valuable input for designers of future best-effort HTMs.

/pdf/hybrid-norec-a-case-study-in-the-effectiveness-of-best-43x9t7vgki.pdf

Yossi Lev

Papers

Hybrid transactional memory

Early experience with a commercial hardware transactional memory implementation

Dynamic circular work-stealing deque

The Fortress Language Specification

Hybrid NOrec: a case study in the effectiveness of best effort hardware transactional memory