Talk:Pipeline (computing)

Duplications and inconsistencies

There is a lot of duplication and insconsistency among pages related to filters and pipelines:

• Pipeline
• Pipeline (Unix)
• Filter (Unix)
• Pipes and filters
• pipe (computing)
• pipeline (Unix)
• ... more

I will try to condense these pages into a sensible set, if no one does it first.
Jorge Stolfi 16:45, 3 Dec 2004 (UTC)

It looks like there was a good effort to resolve this problem by creating the Pipeline (software) article. Sadly, the article associated with this talk page has devolved over the last 20 years to it's former data focused content, which now resembles the Pipeline (software) article. I recommend these two articles be consolidated, or merged, with one focusing on data pipelines and the other on the more general pipeline concepts, covering both data and process pipelines as well as any others, if they exist. Perhaps merge these two articles into this article, tombstoning the Pipeline (software) article, then creating two new articles for added detail, Pipeline (data) and Pipeline (process). Thoughts? .digamma (talk) 13:56, 28 June 2024 (UTC)

Assembly line analogy

I would prop suggest removing the assembly line analogy and replace it with a more detailed description of a pipeline in a computing context. 11:08, 5 October 2006 (UTC)

• The point of giving that real-life analogy is to explain the concept to readers who do not know it already. It is a valid analogy because the math and logic relevant to assembly lines and to computer pipelines are generally the same. The same queuing theory is fundamental to both. --Jorge Stolfi (talk) 06:39, 14 May 2018 (UTC)

Assembly code missing

• As of 14:10, 12 December 2016 (UTC), there are 2 references left to an assembly-line example which is not included in the page! These paragraphs can't be understood anymore...
  • The "assembly" in the example refers to a car assembly line, not assembly language.

Software pipelines

Changed the description of software pipelines. It originally stated that these used the output stream of one process to feed the next process, and linked to the [process (computing)] article. The term 'operation' is a better description as a process is not necessarily what is being called, even if you can invoke an operation that requires a new process. In Unix it is often just a simple operation that completes within the current shell process that is having its output redirected to the input of the next operation. Other software implementations might not even use 'processes', so the term operation provides a more generic/abstract idea with which to describe this. :) Theshowmecanuck (talk) 02:21, 28 January 2010 (UTC)

• For a true pipeline, each element must indeed be a "process" in the general computing sense of the term: and abstract entity that specifies a sequence of operations to some "processor", largely independent of other processes. Those processes must be executed "in parallel", either simulatnously in separate processors, or by a single processor in a time-slice or coroutine fashion. That because the term "pipeline" (derived from the oil industry, or earlier) implies that each stage begins to process the output of the previous stage while the previous stage is still receiving additional inputs.
  If each stage of the "pipeline" is completely executed before the next one is started (as in old DOS "pipes"), then one does not have a true pipeline, just serial execution.
  For the same reason, the word stream is essential when talking about inputs and outputs of the elements.
  --Jorge Stolfi (talk) 06:39, 14 May 2018 (UTC)

"Design considerations" is gooblygook

The "Design considerations" explanation doesn't make any sense. It seems to have tried to simplify pipelining to the point of either making unclear assumptions, or it doesn't understand how it works. Please fix. — Preceding unsigned comment added by 75.72.74.25 (talk) 22:48, 23 December 2016 (UTC)

Removed "Graphical tools" section

I removed the following material because it was not clearly explained, seemed to be relevant only for some very specific pipelines, and had no supporting cictations. Indeed it seems to be "original research".

4.1 Graphical tools
To observe the scheduling of a pipeline (be it static or dynamic), reservation tables are used.

4.1.1 Reservation table
A reservation table for a linear or a static pipeline can be generated easily because data flow follows a linear stream as static pipeline performs a specific operation. But in case of dynamic pipeline or non-linear pipeline a non-linear pattern is followed so multiple reservation tables can be generated for different functions.

The reservation table mainly displays the time space flow of data through the pipeline for a function. Different functions in a reservation table follow different paths.

--Jorge Stolfi (talk) 06:20, 14 May 2018 (UTC)

Classical 5-stage Pipeline Graphics

As the authors of QtMips and QtRVSim educational simulators with pipeline and cache simulators we offer illustration graphics for the article under any license selected proposed by Wikipedia community. The template SVG

[1]

The simulator allows to visualize real conditions and export it to vector PDF which can be transformed to SVG so some interesting situation documenting for example forwarding and stall after LW isntruction can be provided. See the situations on slide 34 or our B35APO Pipeling lecture. Online simulator version [2]. Ppisa (talk) 09:33, 16 April 2022 (UTC)