Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Kim P. Gostelow

dblp:40/5364 · DBLP profile ↗
← Back
3ranked-venue papers
1as first author
0since 2021 · last 1990
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 2 · 1 first-authorSoftware engineering, systems software and programming languages · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
1 paper
Processor architecture and microarchitecture · 61% Parallel and multicore computing · 30% Performance modeling and evaluation · 9%
Software engineering, system software, and programming languages
1 paper
Operating systems · 62% Programming languages and type systems · 38%

Topics — the 8 heaviest of 8, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Processor architecture and microarchitecture
dataflow architecture
0.011980
Performance of a Simulated Dataflow Computer · IEEE Trans. Computers 1980
Parallel and multicore computing
dataflow computing
0.011980
Performance of a Simulated Dataflow Computer · IEEE Trans. Computers 1980
Processor architecture and microarchitecture › dataflow architecture
dataflow machine
0.011980
Performance of a Simulated Dataflow Computer · IEEE Trans. Computers 1980
Programming languages and type systems › programming paradigms
dataflow language
0.011977
Indeterminancy, Monitors, and Dataflow · SOSP 1977
Operating systems
interprocess communication
0.011977
Indeterminancy, Monitors, and Dataflow · SOSP 1977
Performance modeling and evaluation
simulation
0.011980
Performance of a Simulated Dataflow Computer · IEEE Trans. Computers 1980
Operating systems
resource management
0.011977
Indeterminancy, Monitors, and Dataflow · SOSP 1977
Operating systems › resource management
resource scheduling
0.011977
Indeterminancy, Monitors, and Dataflow · SOSP 1977

Methods — techniques the papers use, named apart from their topics

flow analysis · 0.0dataflow programming language · 0.0complexity analysis · 0.0
YearPublicationVenuePosition
1990 Concepts, Methods, and Languages for Building Timely Intelligent Systems
Jay S. Lark, Lee D. Erman, Stephanie Forrest, Kim P. Gostelow
Real Time Syst.4
1980 Performance of a Simulated Dataflow Computer
abstract
Our goal is to devise a computer comprising large numbers of cooperating processors (LSI). In doing so we reject the sequential and memory cell semantics of the von Neumann model, and instead adopt the asynchronous and functional semantics of dataflow. We briefly describe the high-level dataflow programming language Id, as well as an initial design for a dataflow machine and the results of detailed deterministic simulation experiments on a part of that machine. For example, we show that a dataflow machine can automatically unfold the nested loops of n X n matrix multiply to reduce its time complexity from 0(n3) to 0(n) so long as sufficient processors and communication capacity is available. Similarly, quicksort executes with average 0(n) time demanding 0(n) processors. Also discussed are the use of processor and communication time complexity analysis and "flow analysis," as aids in understanding the behavior of the machine.
Kim P. Gostelow, Robert E. Thomas
IEEE Trans. Computers1
1977 Indeterminancy, Monitors, and Dataflow
abstract
The work described in this paper began with a desire to include some linguistic concept of a resource manager within a dataflow language we have been designing [AGP76]. In doing so, we discovered that dataflow monitors (resource managers) provide a natural way of thinking about resources and especially their scheduling. Dataflow semantics are based upon a program composed of asynchronous operators interconnected by lines along which data tokens (messages) flow, such that when all of the input tokens for a given operator have arrived then that operator may fire (execute) by absorbing the input tokens, computing, and producing an output token as its result. These operations closely match one's intuitive model of resource managers (operators) passing signals (tokens) to one another for the purpose of synchronizing and scheduling resource usage. Previously though, dataflow languages [D73, K73, W75] have dealt only with the expression of highly asynchronous yet determinate computations; however, resource management characteristically involves indeterminate computation. The introduction here of dataflow monitors and an explicit nondeterministic merge operator for dataflow streams makes dataflow very well suited for expressing interprocess communication and operations on resources.
Arvind 0001, Kim P. Gostelow, Wil Plouffe
SOSP2