You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
<para>Taskflow provides a <emphasis>task-parallel</emphasis> pipeline programming framework for you to implement a pipeline algorithm. Pipeline parallelism refers to a parallel execution of multiple data tokens through a linear chain of pipes or stages. Each stage processes the data token sent from the previous stage, applies the given callable to that data token, and then sends the result to the next stage. Multiple data tokens can be processed simultaneously across different stages.</para>
<title>Include the Header</title><para>You need to include the header file, <computeroutput>taskflow/algorithm/pipeline.hpp</computeroutput>, for implementing task-parallel pipeline algorithms.</para>
<title>Understand the Pipeline Scheduling Framework</title><para>A <refrefid="classtf_1_1Pipeline"kindref="compound">tf::Pipeline</ref> object is a <emphasis>composable</emphasis> graph to create a <emphasis>pipeline scheduling framework</emphasis> through a module task in a taskflow (see <refrefid="ComposableTasking"kindref="compound">Composable Tasking</ref>). Unlike the conventional pipeline programming frameworks (e.g., Intel TBB Parallel Pipeline), Taskflow's pipeline algorithm does not provide any data abstraction, which often restricts users from optimizing data layouts in their applications, but a flexible framework for users to customize their application data atop an efficient pipeline scheduling framework.</para>
<para>The figure above gives an example of our pipeline scheduling framework. The framework consists of three <emphasis>pipes</emphasis> (serial-parallel-serial stages) and four <emphasis>lines</emphasis> (maximum parallelism), where each line processes at most one data token. A pipeline of three pipes and four lines will propagate each data token through a sequential chain of three pipes and can simultaneously process up to four data tokens at the four lines. Each edge represents a task dependency. For example, the edge from <computeroutput>pipe-0</computeroutput> to <computeroutput>pipe-1</computeroutput> in line <computeroutput>0</computeroutput> represents the task dependency between the first and the second pipes in the first line; the edge from <computeroutput>pipe-0</computeroutput> in line <computeroutput>0</computeroutput> to <computeroutput>pipe-0</computeroutput> in line <computeroutput>1</computeroutput> represents the task dependency between two adjacent lines when processing two data tokens at the same pipe. Each pipe can be either a <emphasis>serial</emphasis> type or a <emphasis>parallel</emphasis> type, where a serial pipe processes data tokens sequentially and a parallel pipe processes different data tokens simultaneously.</para>
<para><simplesectkind="attention"><para>Due to the nature of pipeline, Taskflow requires the first pipe to be a serial type. The pipeline scheduling algorithm operates in a circular fashion with a factor of line count.</para>
<title>Create a Task-parallel Pipeline Module Task</title><para>Taskflow leverages modern C++ and template techniques to strike a balance between the <emphasis>expressiveness</emphasis> and <emphasis>generality</emphasis> in designing the pipeline programming model. In general, there are three steps to create a task-parallel pipeline application:</para>
<para><orderedlist>
<listitem><para>Define the pipeline structure (e.g., pipe type, pipe callable, stopping rule, line count)</para>
</listitem><listitem><para>Define the data storage and layout, if needed for the application</para>
</listitem><listitem><para>Define the pipeline taskflow graph using composition</para>
</listitem></orderedlist>
</para>
<para>The following code creates a pipeline scheduling framework using the example from the previous section. The framework schedules a total of five <emphasis>scheduling tokens</emphasis> labeled from 0 to 4. The first pipe stores the token identifier in a custom data storage, <computeroutput>buffer</computeroutput>, and each of the rest pipes adds one to the input data from the result of the previous pipe and stores the result into the corresponding line entry in the buffer.</para>
<listitem><para>Lines 4-5 define the structure of the pipeline scheduling framework </para>
</listitem>
<listitem><para>Line 8 defines the data storage as an one-dimensional array of <computeroutput>num_lines</computeroutput> integers </para>
</listitem>
<listitem><para>Line 12 defines the number of lines in the pipeline </para>
</listitem>
<listitem><para>Lines 13-23 define the first serial pipe, which will stop the pipeline scheduling at the fifth token </para>
</listitem>
<listitem><para>Lines 25-32 define the second parallel pipe </para>
</listitem>
<listitem><para>Lines 34-41 define the third serial pipe </para>
</listitem>
<listitem><para>Line 45 defines the pipeline taskflow graph using composition </para>
</listitem>
<listitem><para>Line 48 executes the taskflow</para>
</listitem>
</itemizedlist>
Taskflow leverages <refrefid="RuntimeTasking"kindref="compound">Interact with the Runtime</ref> and <refrefid="ComposableTasking"kindref="compound">Composable Tasking</ref> to implement the pipeline scheduling framework. The taskflow graph of this pipeline example is shown as follows, where 1) one condition task is used to decide which runtime task to run and 2) four runtime tasks are used to schedule tokens at four parallel lines, respectively.</para>
<para>In this example, we customize the data storage, <computeroutput>buffer</computeroutput>, as an one-dimensional array of 4 integers, since the pipeline structure defines only four parallel lines. Each entry of <computeroutput>buffer</computeroutput> stores stores the data being processed in the corresponding line. For example, <computeroutput>buffer[1]</computeroutput> stores the processed data at line <computeroutput>1</computeroutput>. The following figure shows the data layout of <computeroutput>buffer</computeroutput>.</para>
<para><simplesectkind="attention"><para>In practice, you may need to add padding to the data type of the buffer or align it with the cacheline size to avoid false sharing. If the data type varies at different pipes, you can use <ulinkurl="https://en.cppreference.com/w/cpp/utility/variant">std::variant</ulink> to store the data types in a uniform storage.</para>
</simplesect>
For each scheduling token, you can use <ref refid="classtf_1_1Pipeflow_1afee054e6a99965d4b3e36ff903227e6c" kindref="member">tf::Pipeflow::line()</ref> to get its line identifier and <ref refid="classtf_1_1Pipeflow_1a4914c1f381a3016e98285b019cf60d6d" kindref="member">tf::Pipeflow::pipe()</ref> to get its pipe identifier. For example, if a scheduling token is at the third pipe of the forth line, <ref refid="classtf_1_1Pipeflow_1afee054e6a99965d4b3e36ff903227e6c" kindref="member">tf::Pipeflow::line()</ref> will return <computeroutput>3</computeroutput> and <ref refid="classtf_1_1Pipeflow_1a4914c1f381a3016e98285b019cf60d6d" kindref="member">tf::Pipeflow::pipe()</ref> will return <computeroutput>2</computeroutput> (index starts from 0). To stop the execution of the pipeline, you need to call <ref refid="classtf_1_1Pipeflow_1a830b7f204cb87fff17e8d424918d9453" kindref="member">tf::Pipeflow::stop()</ref> at the first pipe. Once the stop signal has been triggered, the pipeline will stop scheduling any new tokens after the callable. As we can see from this example, <ref refid="classtf_1_1Pipeline" kindref="compound">tf::Pipeline</ref> gives you the full control to customize your application data on top of a pipeline scheduling framework.</para>
<listitem><para>Calling <refrefid="classtf_1_1Pipeflow_1a830b7f204cb87fff17e8d424918d9453"kindref="member">tf::Pipeflow::stop()</ref> not at the first pipe has no effect on the pipeline scheduling.</para>
</listitem><listitem><para>In most cases, <refrefid="cpp/thread/thread/hardware_concurrency"kindref="compound"external="/Users/twhuang/Code/taskflow/doxygen/cppreference-doxygen-web.tag.xml">std::thread::hardware_concurrency</ref> is a good number for line count.</para>
</listitem></orderedlist>
</para>
</simplesect>
Our pipeline algorithm schedules tokens in a <emphasis>circular</emphasis> manner, with a factor of <computeroutput>num_lines</computeroutput>. That is, token <computeroutput>t</computeroutput> will be processed at line <computeroutput>t % num_lines</computeroutput>. The following snippet shows one of the possible outputs of this pipeline program:</para>
<para>There are a total of five tokens running through three pipes. Each pipes prints its input data value, except the first pipe that prints its token identifier. Since the second pipe is a parallel pipe, the output can interleave.</para>
<title>Connect Pipeline with Other Tasks</title><para>You can connect the pipeline module task with other tasks to create a taskflow application that embeds one or multiple pipeline algorithms. We describe three common examples below:<itemizedlist>
<listitem><para><refrefid="TaskParallelPipeline_1IterateAPipeline"kindref="member">Example 1: Iterate a Pipeline</ref></para>
</listitem><listitem><para><refrefid="TaskParallelPipeline_1ConcatenateTwoPipelines"kindref="member">Example 2: Concatenate Two Pipelines</ref></para>
<title>Example 1: Iterate a Pipeline</title><para>This example emulates a data streaming application that iteratively runs a stream of data through a pipeline using conditional tasking. The taskflow graph consists of one pipeline module task and one condition task. The pipeline module task processes a stream of data. The condition task decides the availability of data and reruns the pipeline when the next stream of data becomes available. <linebreak/>
<listitem><para>Lines 4-5 define the structure of the pipeline scheduling framework </para>
</listitem>
<listitem><para>Line 8 defines the data storage as an one-dimensional array (<computeroutput>num_lines</computeroutput> integers) </para>
</listitem>
<listitem><para>Line 12 defines the number of lines in the pipeline </para>
</listitem>
<listitem><para>Lines 13-23 define the first serial pipe, which will stop the pipeline scheduling when <computeroutput>i</computeroutput> is <computeroutput>5</computeroutput> <linebreak/>
</para>
</listitem>
<listitem><para>Lines 25-32 define the second parallel pipe </para>
</listitem>
<listitem><para>Lines 34-41 define the third serial pipe </para>
</listitem>
<listitem><para>Lines 44-53 define a condition task which returns 0 when <computeroutput>N</computeroutput> is less than <computeroutput>2</computeroutput>, otherwise returns <computeroutput>1</computeroutput> </para>
<para>The pipeline runs twice as controlled by the condition task <computeroutput>conditional</computeroutput>. The starting token in the second run of the pipeline is <computeroutput>5</computeroutput> rather than <computeroutput>0</computeroutput> because the pipeline keeps a stateful number of tokens. The last token is <computeroutput>9</computeroutput>, which means the pipeline processes in total <computeroutput>10</computeroutput> scheduling tokens. The first five tokens (token <computeroutput>0</computeroutput> to <computeroutput>4</computeroutput>) are processed in the first run, and the remaining five tokens (token <computeroutput>5</computeroutput> to <computeroutput>9</computeroutput>) are processed in the second run. In the condition task, we use <computeroutput>N</computeroutput> as a decision-making counter to process the next stream of data.</para>
<title>Example 2: Concatenate Two Pipelines</title><para>This example demonstrates two concatenated pipelines where a sequence of data tokens run synchronously from one pipeline to another pipeline. The first pipeline task precedes the second pipeline task.</para>
<listitem><para>Line 8 defines the data storage (<computeroutput>num_lines</computeroutput> integers) for pipeline <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Line 9 defines the data storage (<computeroutput>num_lines</computeroutput> integers) for pipeline <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 14-24 define the first serial pipe in <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Lines 26-33 define the second parallel pipe in <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Lines 35-42 define the third serial pipe in <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Lines 48-59 define the first serial pipe in <computeroutput>pl_2</computeroutput> that takes the results of <computeroutput>pl_1</computeroutput> as inputs </para>
</listitem>
<listitem><para>Lines 61-68 define the second parallel pipe in <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 70-77 define the third serial pipe in <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 81-82 define the pipeline graphs using composition </para>
</listitem>
<listitem><para>Line 85 defines the task dependency </para>
</listitem>
<listitem><para>Line 88 runs the taskflow</para>
</listitem>
</itemizedlist>
The taskflow graph of this pipeline example is illustrated as follows:</para>
<para>The output of pipelines <computeroutput>pl_1</computeroutput> and <computeroutput>pl_2</computeroutput> can be different from run to run because their second pipes are both parallel types. Due to the task dependency between <computeroutput>pipeline_1</computeroutput> and <computeroutput>pipeline_2</computeroutput>, the output of <computeroutput>pl_1</computeroutput> precedes the output of <computeroutput>pl_2</computeroutput>.</para>
<title>Example 3: Define Multiple Parallel Pipelines</title><para>This example creates two independent pipelines that run in parallel on different data sets.</para>
<listitem><para>Line 8 defines the data storage (<computeroutput>num_lines</computeroutput> integers) for pipeline <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Line 9 defines the data storage (<computeroutput>num_lines</computeroutput> integers) for pipeline <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 14-24 define the first serial pipe in <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Lines 26-33 define the second parallel pipe in <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Lines 35-42 define the third serial pipe in <computeroutput>pl_1</computeroutput> </para>
</listitem>
<listitem><para>Lines 48-58 define the first serial pipe in <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 60-67 define the second parallel pipe in <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 69-76 define the third serial pipe in <computeroutput>pl_2</computeroutput> </para>
</listitem>
<listitem><para>Lines 79-82 define the pipeline graphs using composition </para>
</listitem>
<listitem><para>Lines 83-84 define a static task. </para>
</listitem>
<listitem><para>Line 86 defines the task dependency </para>
</listitem>
<listitem><para>Line 88 runs the taskflow</para>
</listitem>
</itemizedlist>
The taskflow graph of this pipeline example is illustrated as follows:</para>
<para>Because pipeline <computeroutput>pl_1</computeroutput> and pipeline <computeroutput>pl_2</computeroutput> are running in parallel, their outputs may interleave.</para>
</sect2>
</sect1>
<sect1id="TaskParallelPipeline_1ResetPipeline">
<title>Reset a Pipeline</title><para>Our pipeline scheduling framework keeps a <emphasis>stateful</emphasis> number of scheduled tokens at each submitted run. You can reset the pipeline to the initial state using <refrefid="classtf_1_1Pipeline_1a311d874b98de6f0def8a7d869e8d15bd"kindref="member">tf::Pipeline::reset()</ref>, where the number of scheduled tokens will start from zero in the next run. Borrowed from <refrefid="TaskParallelPipeline_1IterateAPipeline"kindref="member">Example 1: Iterate a Pipeline</ref>, the program below resets the pipeline at the second iteration (inside the condition task) so the scheduling token will start from zero in the next run.</para>
<para>The output can be different from run to run, since the second pipe is a parallel type. At the second iteration from the condition task, we reset the pipeline so the token identifier starts from <computeroutput>0</computeroutput> rather than <computeroutput>5</computeroutput>.</para>