Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....scheduler is very similar to the schedulers in some of these other systems, though Cilk s algorithm uses randomness and is provably efficient. Many multithreaded programming languages and runtime systems are based on heuristic scheduling techniques. Though systems such as Charm [91] COOL [27, 28], Id [3, 37, 80] Olden [22] and others [29, 31, 38, 44, 54, 55, 63, 88, 98] are based on sound heuristics that seem to perform well in practice and generally have wider applicability than Cilk, none are able to provide any sort of performance guarantee or accurate machine independent performance ....

....in the Benev 1.3. Contributions of this thesis 9 olent Bandit Laboratory (BBL) 40] a PC based system. The BBL system architecture is closely related to Cilk NOW s. The Prospero resource manager [78] also employs a similar system architecture. Runtime systems for the programming language COOL [28] running on symmetric multiprocessors [101, 102] and cache coherent, distributed, shared memory machines [26, 69] use process control to support adaptive parallelism. These systems rely on special purpose operating system and hardware support. In contrast, Cilk NOW supports adaptive parallelism ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.

....level implementations as described in Table 8.1 on page 102. 8.1.1 Language level DSM Many shared address space languages provide a global namespace in terms of objects. The roster of parallel object oriented languages includes Amber [24] Emerald [55] Orca [6] Prelude [100] COOL [23], ABCL f [91] Concert [57] CST [48] Jade [80] Mentat [39] and Concurrent Aggregates [25] Although all of these projects are interesting, only some of those relevant to computation migration are discussed in this section. Only one other project, Olden, has investigated computation migration; ....

R. Chandra, A. Gupta, and J.L. Hennessy. "COOL: An Object-Based Language for Parallel Programming". IEEE Computer, 27(8):13--26, August 1994.

....of ffl as small as e GammaT 1 , the space complexity of our algorithm is at most S1 O(PT1 log(PT1 ) with probability at least 1 Gamma e GammaT 1 . These bounds include all time and space costs for both the computation and the scheduler. 1 Introduction Many parallel programming languages [3, 7, 11, 12, 14, 18, 20, 22, 28] support dynamic threads. The multithreaded model of parallel computation is a general approach to model This work was done while the author was affiliated with the MaxPlanck Institute fur Informatik, Saarbrucken, Germany and was partially supported by the IST Programme of the European Union under ....

....read by any number of other threads. This class of computations, introduced in [6] is much more general than the nested parallel or fully strict computations, where threads synchronize only with their parents. These last classes of computations do not include e.g. parallel programs using futures [11, 20, 22], lenient or speculative evaluation [2] or general user specified synchronization constraints [28] which can be implemented using write once synchronization variables [6] Our algorithm is randomized and employs the work stealing paradigm, combined with the depth first technique. The algorithm ....

R. Chandra, A. Gupta, and J. L. Hennessy. Cool: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.

....[1] the MANIFOLD language and PREMO standard proposal [7] 8] 25] 26] related to DYMO. Another programming language can be mentioned such as COOL (Concurrent Object Oriented Language) which was designed to exploit coarse grained parallelism at the level in shared memory multiprocessors [2]. COOL was developed at the Stanford University. The project MADE (Multimedia Application Development Environment) is trying to define and implement a portable object oriented development environment for multimedia applications. The model emphasizes on two cardinal concepts: active objects and ....

Chandra, R., Gupta, A., Hennessy, J.L.: 'COOL: An Object-Based Language for Parallel Programming', Computer, Vol. 27, No. 8, pp. 14-26, August, 1994.

....the allocation directives as imperative commands and does not consider the current system state. In addition, allocation constructs are dispersed within the algorithmic code of applications, violating the separation of concerns principle. Trellis DOWL adopts a similar approach [Ach93] COOL [Cha94] provides a simple set of allocation directives to specify the allocation of application components. As in PO, the COOL directives influence the behaviour of an automatic load balancing strategy embedded in the run time support. Differently from PO, the support is forced to respect the specified ....

R. Chandra, A. Gupta, J. L. Hennessy, "COOL: an Object-based Language for Parallel Programming", IEEE Computer, Vol. 27, No. 8, pp. 13-26, Aug. 1994.

....None. Availability: COOL is available for the following architectures: Stanford Dash, silicon Graphics 4D 380, and Encore Multimax. Sources and Documentation can be found on anonymous ftp: cool.stanford.edu Email address: Rohit Chandra Gamma rohit cool.stanford.edu References: 55] 56] [57] 2.34 Coral Developer: IBM Palo Alto Scientific Center Description: oo. Multiple inheritance. memory model. parallelism. Asynchronous message passing. scheduling. mapping. Nothing is published about object thread placement, alignment etc. synchronization. The author states the existence ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.

.... group Gamma info chorus.com COOL (NTT) ACOOL [167] Phi Phi Delta Delta H H A A Phi Phi Delta Delta H H A A hijklm y t i v i t c a y r a d n u o b ftp: ftp.ntt.jp pub lang Katsumi Maruyama Gamma maruyama nttmfs.ntt.jp COOL (Stanford) [64, 65, 66] Phi Phi Delta Delta H H A A Phi Phi Delta Delta H H A A hijklm y t i v i t c a y r a d n u o b ftp: cool.stanford.edu Rohit Chandra Gamma rohit cool.stanford.edu Coral [69] Phi Phi Delta Delta H H A A Phi Phi Delta Delta H H A A y t i ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13-- 26, August 1994.

....should also support locality optimizations. Often, the available performance optimizations are determined by the underlying hardware. For example, the DASH multiprocessor [Lenoski et al. 1992] has influenced the support for locality optimizations in the Concurrent Object Oriented Language (COOL) [Chandra et al. 1994] . Other programming environments exist for DASH (e.g. the ANL parallel macros [Boyle et al. 1987] and Jade [Rinard et al. 1993] and other cache coherent sharedmemory multiprocessors have also been built (e.g. Alewife [Agarwal et al. 1995] and NUMAchine [Abdelrahman et al. 1994] but we ....

R. Chandra, A. Gupta, and J.L. Hennessy. COOL: An Object-Based Language for Parallel Programming. IEEE Computer, 27(8):14--26, August 1994.

....is restricted to method invocation. Furthermore, in languages with suitable multithreading support, such as Java, distributed execution is transparent: no new API is introduced for distributed sharing. This transparency distinguishes this work from many earlier distributed object sharing systems [2, 7, 14, 12]. The key insight in this paper is that the ability to distinguish pointers from data at run time enables more ecient ne grained sharing than is possible with conventional distributed shared memory (DSM) implementations that do not use type information (e.g. 1, 13] Conventional VM based DSM ....

....and the read write memory region are backed by di erent physical memory regions. This decision has the unfortunate side e ect of forcing modi cations made in the read write region to be copied to the read region, every time protection changes from read write to read. Orca [2] Jade [12] COOL [7], and SAM [14] are parallel or distributed objectoriented languages. All of these systems di er from ours in that they present a new language or API to the programmer to express distributed sharing, while DOSA does not. DOSA aims to provide transparent object sharing for existing typed languages, ....

R. Chandra, A. Gupta, and J. Hennessy. Cool: An object-based language for parallel programming. IEEE Computer, 27(8):14-26, Aug. 1994.

....standard, which demonstrates that page migration can tackle what is considered to be the major drawback of OpenMP i.e. the negligence of memory locality. The integration of runtime support for improving data locality on cache coherent NUMA multiprocessors has been explored in the COOL language [7]. COOL included affinity hints for associating threads with data and dynamically migrating data close to the threads for which they have affinity. COOL was primarily relying on programmer s knowledge for distributing tasks and data in a manner that exploits efficiently the memory hierarchy. Our ....

R. Chandra, A. Gupta, and J. Hennessy. COOL: An Object-Based Language for Parallel Programming. IEEE Computer, 27(8):13--26, 1994.

.... include data parallel languages like High Performance Fortran [31] and NESL [5] data ow languages like ID [21] control parallel languages with fork join constructs like CILK [8, 27] CC [19] and Proteus [40] languages with synchronization primitives like Multilisp [30] Mul T [35] COOL [20], SISAL [25] Jade [49] and various other user level thread libraries [3, 46, 53] For the execution of a multithreaded computation on a parallel computer, one should specify which processor executes which threads and when each thread should be executed. Clearly, this is not a desirable task to ....

....for distributed memory machines) In these models there is no restriction on the pattern of synchronization that occurs during the execution of the computation. The model of parallelism with simple synchronization primitives has been employed by several parallel programming languages, like [2, 20, 25, 30, 35, 49]. Finally, there exist computations that use more complex synchronization techniques such as mutexes, semaphores, or condition variables. Although there exist a number of general purpose thread libraries [3, 46, 53] that provide such arbitrary primitives, it is usually dicult to model them through ....

[Article contains additional citation context not shown here]

R. Chandra, A. Gupta and J. L. Hennessy, \COOL: An object-based language for parallel programming, " IEEE Computer, 27(8):13-26, August 1994.

....computations are nowadays quite common for parallel computers. Multithreaded models of parallel computation have typically been proposed as a general approach to model dynamic, unstructured parallelism (see e.g. 17, 19, 26] and have been employed by several parallel programming languages [12, 13, 14, 22]. To specify parallelism, a thread can spawn child threads. Additionally, a thread may synchronize with some or all of its (direct or indirect) descendants by suspending its execution until a descendant reaches a specific point of computation. A multithreaded computation is identified with a ....

R. Chandra, A. Gupta and J. L. Hennessy, "COOL: An object-based language for parallel programming, " IEEE Computer, Vol. 27, No. 8, pp. 13--26, August 1994.

.... 598] Affinity scheduling, where threads are scheduled back onto previously used PEs so as to benefit from data that may still reside in their caches, tries to counter this effect [598, 157, 38, 544, 576, 106] It has even been proposed that affinity hints be included in the programming language [107]. Note that the adverse effects caused by the operating system are related in both cases to the preemption of running threads. Thus memory usage considerations lead to a preference for non preemptive scheduling, leaving partitioning as the only means for sharing the machine. However, partitioning ....

R. Chandra, A. Gupta, and J. L. Hennessy, "COOL: an object-based language for parallel programming ". Computer 27(8), pp. 13--26, Aug 1994.

....is restricted to method invocation. Furthermore, in languages with suitable multithreading support, such as Java, distributed execution is transparent: no new API is introduced for distributed sharing. This transparency distinguishes this work from many earlier distributed object sharing systems [2, 7, 14, 12]. The key insight in this paper is that the ability to distinguish pointers from data at run time enables more efficient fine grained sharing than is possible with conventional distributed shared memory (DSM) implementations that do not use type information (e.g. 1, 13] Conventional VM based ....

....and the read write memory region are backed by different physical memory regions. This decision has the unfortunate side effect of forcing modifications made in the read write region to be copied to the read region, every time protection changes from read write to read. Orca [2] Jade [12] COOL [7], and SAM [14] are parallel or distributed object oriented langages. All of these systems differ from ours in that they present a new language or API to the programmer to express distributed sharing, while DOSA does not. DOSA aims to provide transparent object sharing for existing typed languages, ....

R. Chandra, A. Gupta, and J. Hennessy. Cool: An object-based language for parallel programming. IEEE Computer, 27(8):14-- 26, Aug. 1994.

....technology motivates implementing a COOP language by extending an existing sequential object oriented language, such as C or Smalltalk, with a notion of process or thread. In particular, given the popularity and portability of C ,a number of COOP languages based on C have proliferated [23, 69, 47, 73, 27, 87, 86, 95]. We describe a few examples below. Compositional C (CC ) 69] extends C with a number of abstractions for process creation and synchronization. Synchronization is done via special shared variables. COOL [27] is targeted for shared memory multiprocessors. Invocation of a parallel function ....

....number of COOP languages based on C have proliferated [23, 69, 47, 73, 27, 87, 86, 95] We describe a few examples below. Compositional C (CC ) 69] extends C with a number of abstractions for process creation and synchronization. Synchronization is done via special shared variables. COOL [27] is targeted for shared memory multiprocessors. Invocation of a parallel function creates a thread which executes asynchronously. Threads communicate through shared data and synchronize using monitors and condition variables. Mentat [47] and Charm [73] are similar in that both distinguish ....

R. Chandra, A. Gupta, and J. L. Hennessy. COOL: An Object-Based Language for Parallel Programming. IEEE Computer, 27(8):13--26, August 1994.

....provide a data parallel model, using only a preprocessor and library, but its syntax is a little complicated for beginners. Other data parallel options like Presto [Kil92] and Compositional C [CK92] are also rather complex for beginners. Others, like Mentat [Gri93] CHARM [KK93] and COOL [CGH94] are more task parallel than dataparallel. Finding no suitable existing language, we decided to design and implement our own language as a set of macros and classes that extended C . The result is DAPPLE, a DAta Parallel Programming Library for Education. DAPPLE gains its strength from its ....

Rohit Chandra, Anoop Gupta, and John L. Hennessey. COOL: an object-based language for parallel programming. IEEE Computer, 27(8):14--26, August 1994.

....parallelizing compiler that automatically extracts parts of the specification which can be executed in parallel. This has been a research topic in multiprocessing since a long time [ 210] 158] 90] 77] 113] But good performance is only achieved if the designer controls the parallelization [ 29] [ 110] Thus extending the automatic partitioning approaches to complex, high performance applications seems at least very difficult. A performance analysis based on the pixie tool is used for the software part in [ 148] In [ 60] a code generation for VLIW processors is used to estimate the ....

R. Chandra, A. Gupta, and J.L. Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.

....system just before sending and after receiving a message, respectively. Thus, only messages that are actually sent to other processors are packed. 2.2.2. 2 Related work in concurrent objects Dynamic object creation is provided in ICC [17] Mentat [18] C [19] C [17] ABCL [20] and COOL [21], among others. Mentat supports coarse grained objects, while ICC and languages such as Cantor [22] HAL [23] and CA [24] support fine grained objects. Compilers for fine grained languages typically coalesce multiple objects and operations into coarser ones in order to achieve acceptable ....

R. Chandra, A. Gupta, and J.L. Hennessy. COOL: An Object-Based Language for Parallel Programming. IEEE Computer, 27(8):14--26, August 1994.

....that can be used for different types of data. As in other DSM systems, Munin restricts its attention to the migration of data, and does not allow for the migration of computation. Munin does provide support for migratory data in the form of RPC. Several systems, such as Mercury [8] and COOL [6], use cache conscious scheduling, which is a scheduling policy designed to increase cache reuse. The use of computation migration can increase global cache effectiveness, because by avoiding replication it reduces pressure on the cache. Nonetheless, this effect is second order in comparison to the ....

R. Chandra, A. Gupta, and J.L. Hennessy. COOL: An Object-Based Language for Parallel Programming. IEEE Computer, 27(8):13--26, August 1994.

.... 29, 18] Our work relies on software technologies without any special hardware support; it is more closely related to the software based implementations [29, 18] Our implementation supports fine grain object level concurrency and thus differs from research in coarse grained COOP languages such as [7, 11, 13, 16]. However, the techniques we use in the implementation of a name server and remote object creation P 2 4 8 16 M 256 1.06 0.31 0.12 0.05 512 8.40 2.37 0.69 0.23 1024 72.78 12.51 4.94 1.46 Table 5: Execution times of systolic matrix multiplication (unit: seconds) All results were obtained by ....

R. Chandra, A. Gupta, and J. L. Hennessy. COOL: An Object-Based Language for Parallel Programming. IEEE Computer, 27(8):13--26, August 1994.

....If the scheduling is done at runtime, then the performance of the high level code relies heavily on the scheduling algorithm, which should have low scheduling overheads and good load balancing. Several systems providing dynamic parallelism have been implemented with efficient runtime schedulers [7, 11, 13, 18, 19, 22, 23, 29, 30, 31], resulting in good parallel performance. However, in addition to good time performance, the memory requirements of the parallel computation must be taken into consideration. In an attempt to expose a sufficient degree of parallelism to keep all processors busy, schedulers often create many more ....

Rohit Chandra, Anoop Gupta, and John Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.

....overheads and good load balancing. This paper appears in the Proceedings of the Sixth ACM SIGPLAN Symposiumon Principles and Practice of Parallel Programming (PPoPP) June 18 21, 1997, Las Vegas. Several systems providing dynamic parallelism have been implemented with efficient runtime schedulers [7, 11, 13, 18, 19, 22, 23, 33, 34, 35], resulting in good parallel performance. However, in addition to good time performance, the memory requirements of the parallel computation must be taken into consideration. In an attempt to expose a sufficient degree of parallelism to keep all processors busy, schedulers often create many more ....

R. Chandra, A. Gupta, and J. Hennessy. COOL: An object-based language for parallel programming. IEEE Computer, 27(8):13--26, August 1994.

....languages. In Mentat[11] developed by Grimshaw and his research group, the user can specify the granularity and partitioning decisions using extended C while the compiler and run time system manage communication, synchronization, and scheduling. There are many other systems and projects[18,19,20] that are similar in some respects to Mentat, since an easy way to provide concurrent object oriented programming systems might be to augment C with communication and synchronization libraries that must be explicitly used by programmers. However, this approach does not offer the computational ....

....through abstraction. It is also possible that other research[21] for alleviating limitation of functional languages on multithreaded architecture can be experimented through the advantages which our programming model provides. Improving data locality is another our future research topic. The COOL[18] has been implemented on several shared memory multiprocessors and a variety of application programs have been written in the language. We have experimented to evaluate several approach to exploiting data locality with programs written in OOId on DAVRID. The inheritance mechanism in most ....

Chandra, A. Gupta, and J.L. Hennessy, "COOL: An Object-Based Language for Parallel Programming," IEEE Computer, Vol. 27, No. 8, Aug., 1994, pp13-26

....is the limited expressive power that high level directives induce. However, to our opinion, this lack of expressiveness is somehow supplied by the automated decisions of the integrated load balancing policy. An approach very similar to the Parallel Objects one is found in the COOL environment [Cha94] As in PO, the COOL hints influence the behaviour of an automated load balancing strategy integrated in the run time support, by forcing it to take its load balancing decisions in the respect of the specified allocation hints. Moreover, even if the separation of concern is not stressed, there is ....

R. Chandra, A. Gupta, J. L. Hennessy, "COOL: an Object-based Language for Parallel Programming", IEEE Computer, Vol. 27, No. 8, pp. 13-26, Aug. 1994.

No context found.

R. Chandra, A. Gupta, and J.L. Hennessy. COOL: An ObjectBased Language for Parallel Programming. IEEE Computer, 27(8):1426, August 1994.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC