J. B. Dennis. Data flow supercomputers. Computer, 13(11):48--56,November 1980.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... the parallelism limits imposed by flow dependences [124] Unfortunately, the renamed registers are an extraordinarily constrained resource, making it impossible for superscalars to exploit flow dependences that can be eliminated through control dependence analysis [40] Dataflow architectures [35, 34, 91, 28] do as much (or more) renaming as does queue conversion, but at the cost of insisting that all programs be represented purely functionally. This makes converting to dynamically allocated closures easy (because loops are represented as recursive procedures) but substantially restricts the domain ....

....of the last decade. The dataflow machines of the past, however, had two problems. Fortunately, a system like SUDS can help to address these problems. The first problem was that dataflow machines did not run imperative programs, but only programs written in functional programming languages [35, 34, 91, 85, 28, 18, 17]. Scalar queue conversion can help address this problem because it converts scalar updates into function (closure) calls. The second problem with dataflow machines was that their renaming mechanisms were not fundamentally deadlock free [27] Checkpoint repair mechanisms, like that provided by ....

J. B. Dennis. Dataflow supercomputers. IEEE Computer, 13(11):48--56, November 1980.

....of SDSP PN is live and safe (by Theorem 2.2.1 and 2.2.2) Second, SDSP PN is a marked graph. Figures 2(a) and (b) give the corresponding Petri net representations for L1 and L2. In a dataflow graph a conditional expression is represented by a so called well formed conditional dataflow subgraph [9]. Switch and merge nodes are used in the implementation. These nodes have special firing rules which can present problems when considered in a Petri net model. To overcome these problems, the firing rules of the switch node and the merge node are altered to produce and consume dummy tokens on ....

J. B. Dennis. Data flow for supercomputers. In Proceedings of the 1984.

....are essentially the same (i.e. instructions fire when their inputs are ready) The problem then became how to build a fully decentralized dataflow machine. WaveScalar is the creative extension of this line of reasoning. Dataflow has a long history. The first designs appeared in the early 70 s [6, 19, 20], and there was a significant revival in the 80 s and early 90 s [21, 22, 23, 24, 25, 26, 27] Dataflow machines execute programs according to the dataflow firing rule (DFR) which stipulates that an instruction may execute at any time, as long as its operands are available. When dataflow ....

....traditional memory semantics, including side effects, indirection and aliasing. In our opinion, supporting traditional programming languages is required for instruction sets and new architectures to be successful. The WaveScalar ISA builds upon some of the original program representations used in [19, 27], which was derived from earlier compiler and theory work [33] The intermediate compiler language, Pegasus [63] for NanoFabrics [64] adapts these ideas as well. The Pegasus researchers transform an entire application into a static dataflow graph and map it onto a large spatial fabric of ....

J. B. Dennis, "Dataflow supercomputers," in IEEE Computer, IEEE, November 1980.

....Rhamma. 2. 2 Dataflow Model and Architectures The dataflow model and architecture have been studied for more than two decades and held the promise of an elegant execution paradigm with the ability to exploit inherent parallelism available in applications ( Ang 94] Arvind 80] Culler 90] Dennis 80] Papadopoulos 88, 90, 91] However, actual implementations of the model have failed to deliver the promised performance. Nevertheless, several features of the dataflow computational model have found their place in modern processor architectures and compiler technology (e.g. SSA, register ....

J.B. Dennis. "Dataflow Supercomputers", IEEE Computer, Nov. 1980, pp 48-56.

....departure from von Neumann architectures, where the program execution is guided by microprocessor s control unit. In dataflow approach, a data driven model of computation is proposed e.g. when the data are available the program starts its execution. A survey of dataflow computing is presented in [ 171 ]. f) AERO SIMULATOR [154] where a computer with MIMD architecture based on Pipelined functional units will be used for the Real Time Simulation of Aeronautical Structures. g) Finite Element Machine 2, 52,157] where a computer based on Parallel Architecture (possibly MIMD) will be constructed by ....

DENNIS J. B., "Data Flow Supercomputers", Computer, Vol 13,11, 1980, pp. 48 - 56

....[4] The ring structure of dataflow architectures leads to some other performance issues. The memory unit is shared by all processing elements. Thus memory latency may degrade the system performance. Also the capacity of the communication network is a limiting factor to the performance [5]. That means that the memory unit and the communication network may become a bottleneck. OU in ut I 0 unit :ut resu Its memory unit (activity templates) processing unit executable instructions 1 routing network Figure 1: Pipelined ring structure of dataflow architectures A new ....

Dennis, J.B., "Data Flow Supercomputers", IEEE Computer 1980

....,space in Linda [5] which is another approach for topology independent programming. However, our approach differs from Linda in that we do not use pattern matching to locate a data item, and we provide support for distributed termination. Our overall approach is also similar to that of dataflow [4, 2]. We use nondeterministic dataflow wherein messages sent on a multiplexer channel can flow to any of the processors. We also provide atomic operations for receiving multiple messages from multiplexer channels, giving it the flavour of wait matching in dataflow. For a more detailed understanding of ....

J. B. Dennis. "Data Flow Supercomputers". IEEE Computer, 13(11):48 56, November 1980.

.... (actors) and data (tokens) i.e. impure code) Dynamic architectures use physically separate memories for instructions (i.e. pure code) and data[2] In static dataflow architectures, the dataflow program graph is represented as a multiply linked collection of items called activity templates[3]. Each activity template corresponds to an actor of the dataflow program graph. An activity template is a triple consisting of i) an operation code, ii) a set of operand slots, and iii) a (destination) pointer list. The operand slots correspond to the input arcs of the actor. Each slot is a ....

J. B. Dennis, "Data Flow Supercomputers," Computer, Vol. 13, No. 11, Nov. 1980. pp. 48-56,

....memory, an operation can be sent to the memory with the processing taking place at the chip, and value(s) or acknowledgement being returned. This overlapping of latency with processing is similar to state multiplexing as it takes place in the HEP computer [17] and in circulating data flow machines [6]. Since more work is done on data resident on the SM chips, much less communication need take place over bus or other interconnect topologies between processors and memories. This communication bandwidth savings both increases speed and makes available more of the expensive communication ....

Dennis, J., "Data Flow Supercomputers," Computer, Vol. 13, 11, pp. 48-56, (1980).

....processes with local control. The SCORE model is more stylized, making it amenable to virtualization and use of a strong hardware software interface. SCORE emphasizes a design that preserves deterministic behavior regardless of target hardware size and scheduling. Data flow processing from Dennis [10] and Arvind [3] introduced parallel models and architectures with more flexible scheduling. Later work in Culler s Threaded Abstract Machine (TAM) 8] and Active Messages (AM) 11] was an important attempt to capture the essence of a parallel programming model at the software hardware boundary and ....

Jack B. Dennis. Data flow supercomputers. Computer, 13:48--56, November 1980.

....effects arising from the intermediate results and data being stored in registers and storage units. Although, the data flow model apparently promises higher performance, in reality, it suffers from several limitations. First, general purpose data flow architectures, proposed in the literature [20] [21] are very complex. They require complex mechanisms for labeling tokens, storing data, and for communication between successive instructions. All of these impose high demand for silicon. Because of this, it is unrealistic to implement them on the current FPGAs that feature modest gate counts. ....

....fail to exploit potential fine grain parallelism. In contrast, such restrictions are absent in PRISM II. In addition, unlike in the above architectures, the PRISM II execution model permits direct and fast data communication among the operators. Throughout the literature, data flow architectures [20], 21] have always promised high performance for general purpose computing but have failed to meet the expectations. Their complex mechanisms pose high demand for silicon and significant execution overhead. Main Processor AMD 29050 Final Result S1 S2 S3 Control Signal Data Value ....

J. B. Dennis. Data flow supercomputers. Computer, 13(11):48--56, November 1980.

....representation. The methodology presented here directs the designer in considering the structural impact of issues of perception, action and communication. Communication among the functional units (be they objects or functions) in a software design is another important issue. Both data driven [23] and event based programming [67] have been proposed to model communication between units. Since communication within the agent architecture is of concern to this thesis, these paradigms can be of use. Data driven programming structures a program s units into functional blocks where data flows ....

....ordering of those subtasks. For the most part, creating the decomposition and task flow diagrams is part of the art of agent design and this thesis has little specific to suggest. Software engineering provides a number of methodologies for decomposing tasks into smaller conceptual units, e.g. 11][23][67] 84] Some of the more popular methodologies are discussed in chapter 2. 51 3.3.3 Decomposition Summary In this step the designer is to create a hierarchical decomposition of the agent s overall task. This begins by deciding on the agent s most primitive behaviors. Next the designer ....

Dennis, J.B. 1980. Data Flow Supercomputers. IEEE Computer 13(1): 48-56.

....is a kernel level thread. This overhead sets a lower limit on the plausible granularity of the overlapped computation. Unfortunately, this minimum granularity can conflict with application requirements, underlining the first difficulty we introduced. 2. 2 The Dataflow Model In the dataflow model [4, 3, 10, 8, 6], all operations are activated by data, that is, they are data driven. A consequence of this is that many operations can be made available at once, allowing a high degree of concurrency and asynchrony. Implemented both in hardware and in software, the dataflow model has been traditionally used to ....

J. B. Dennis. Data Flow Supercomputers. Computer, pages 48--56, Nov. 1980.

....work is reminiscent of techniques utilized in schedulers that execute batches of processes on parallel machines. We create task graphs or DAGs that represent execution dependencies and schedule them for execution [4] J. Dennis researched data ow scheduling techniques for Supercomputers[5]; our work presents a similar idea for Grid environments. Ninf [6] is a functional metacomputing environment that shares many similarities with NetSolve. The project implemented a strategy to increase parallelism amongst the computational services. Similar to this work, they group together ....

J. Dennis. Data Flow Supercomputers. IEEE Computer, 13(11):48-56, November 1980.

....a system which consists of multiple computers with dataflow (data driven) architecture. A data flow machine is a parallel execution computer, whose program is represented by a directed graph. Nodes of a graph denote operators (instructions) and arrows of a graph represent flows of operand data [30, 15, 17, 31, 16, 42]. I prepared a population of matrices which represent program graphs and evolved them using GAs. From several experiments using problem datasets, I found that this system did not suffer from evolutionary dead end. The data flow architecture enabled every operator to start execution only by a ....

Dennis, J. B., "Data flow supercomputer", Computer 13 (1980), 48--56.

.... family [Ang et al. 1995] the MIT Monsoon [MIT, 1995] the MIT J Machine [Lethin, 1994] and M Machine [Fillo et al. 1995] the Bristol Data Diffusion Machine [Stallard et al. 1993] the MIT Alewife [Agarwal et al. 1991, 1995] LAU, Mandala, and the Earth Multiprocessor [Hum et al. 1995] Dennis [1980] discusses the principles behind data flow processors and Culler [1993] describes a stateless data flow architecture. A comparative study of these and other data flow architectures is given by Snelling and Egan [1994] 24 While the program control mechanism is distributed, which removes linear ....

Dennis, J. B. [1980]. Data flow supercomputers. IEEE Computer, 13(11), 48--56.

....predict at compile time, namely the variable latency of memory access instructions and the unpredictable behavior of conditional branches. Other architectures have been proposed that utilize dynamic scheduling. Among these are the large class of machines called Dataflow. In traditional Dataflow [5, 22, 13], instructions are arranged in a dataflow graph, and the execution of instructions is triggered by the arrival of tokens which traverse the graph edges, carrying data between instructions. Thus instructions are allowed to execute in any order, and as soon as all operands are available. Pure ....

Jack B. Dennis. Data Flow supercomputers. Computer, 13(11):48--56, November 1980.

....process) level and could appear at any level of algorithm structure where code execution takes place. In practice, process management overhead favors algorithms in which parallelism appears at a high level. The Force computational model retains the concept of instruction streams. The data flow [15] or functional programming models discard instruction streams entirely. The cost of eliminating the idea of instruction streams is that it assumes a completely automatic solution to the problem of scheduling operations. Programs written in a functional language contain no operation scheduling ....

J. B. Dennis, "Data flow supercomputers," IEEE Computer, pp. 48-56 (Nov. 1980).

....in order to achieve performance far beyond what is possible today. Pipelining and multiprocessing do not break significantly with the standard way in which computers are organized. Processors spend a lot of time fetching instructions and data from memory. On the other hand, dataflow computers [4] depart radically from tradition in order to boost speed enormously. They respond instantaneously to the arrival of data by attaching it to the instruction waiting for it. Instead of fetching the same data several times, copies of data are produced and simultaneously sent to the instructions ....

J.Dennis. Data Flow Supercomputers, IEEE Computer 13(11), 48-56, 1980.

....architectures, dramatically reducing the expense of such experimentation, in much the same way s MIT s proposed Multiple Processor Emulation Facility[ADI83] will when completed. We have designed simulators for three applicative architectures: Static data flow[Den74] VIM style dynamic data flow[Den80], and Combinator reduction[Tur79] We have actu0lly implemented the static data flow and combinator reduction simulators. In this paper we describe the design of those simulators for running on the CM, and some lessons we have learned from the design and implementation of these simulators. 1.1 ....

J.B. Dennis. Data flow supercomputers. IEEE Computer, 48-56, November 1980.

No context found.

J. B. Dennis. Data flow supercomputers. Computer, 13(11):48--56,November 1980.

No context found.

J. B. Dennis, "Dataflow supercomputers," in IEEE Computer, vol. 13, 1980.

No context found.

J. B. Dennis, "Data Flow Supercomputers," IEEE Computer, Vol.13, No.11, November 1980, pp.48--56.

No context found.

J. Dennis. Data Flow Supercomputers. IEEE Computer, November 1980.

No context found.

J. B. Dennis. Data flow supercomputers. IEEE Computer, pages 48--56, November 1980.

First 50 documents  Next 50

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