Ignore:
Timestamp:
Aug 20, 2011, 10:49:39 AM (8 years ago)
Author:
lindanl
Message:

section 9

File:
1 edited

Legend:

Unmodified
Added
Removed
  • docs/HPCA2012/09-pipeline.tex

    r1326 r1329  
    11\section{Multi-threaded Parabix}
     2The general problem of addressing performance through multicore parallelism
     3is the increasing energy cost. As discussed in previous sections,
     4Parabix, which applies SIMD-based techniques can not only achieves better performance but consumes less energy.
     5Moreover, using mulitiple cores, we can further improve the performance of Parabix while keeping the energy consumption at the same level.
     6
     7A typical approach to parallelizing software, data parallelism, requires nearly independent data,
     8However, the nature of XML files makes them hard to partition nicely for data parallelism.
     9Several approaches have been used to address this problem.
     10A preparsing phase has been proposed to help partition the XML document \cite{dataparallel}.
     11The goal of this preparsing is to determine the tree structure of the XML document
     12so that it can be used to guide the full parsing in the next phase.
     13Another data parallel algorithm is called ParDOM \cite{Shah:2009}.
     14It first builds partial DOM node tree structures for each data segments and then link them
     15using preorder numbers that has been assigned to each start element to determine the ordering among siblings
     16and a stack to manage the parent-child relationship between elements.
     17
     18Data parallelism approaches introduce a lot of overheads to solve the data dependencies between segments.
     19Therefore, instead of partitioning the data into segments and assigning different data segments to different cores,
     20we propose a pipeline parallelism strategy that partitions the process into several stages and let each core work with one single stage.
     21
     22The interface between stages is implemented using a circular array,
     23where each entry consists of all ten data structures for one segment as listed in Table \ref{pass_structure}.
     24Each thread keeps an index of the array ($I_N$),
     25which is compared with the index ($I_{N-1}$) kept by its previous thread before processing the segment.
     26If $I_N$ is smaller than $I_{N-1}$, thread N can start processing segment $I_N$,
     27otherwise the thread keeps reading $I_{N-1}$ until $I_{N-1}$ is larger than $I_N$.
     28The time consumed by continuously loading the value of $I_{N-1}$ and
     29comparing it with $I_N$ will be later referred as stall time.
     30When a thread finishes processing the segment, it increases the index by one.
    231
    332\begin{table*}[t]
     
    534\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|c|}
    635\hline
    7 Stage Name & \multicolumn{10}{|c|}{Data Structures}\\ \hline
    8                 & srcbuf & basis\_bits & u8   & lex   & scope & ctCDPI & ref    & tag    & xml\_names & check\_streams\\ \hline
    9 fill\_buffer    & write  &             &      &       &       &        &        &        &            &               \\ \hline
    10 s2p             & read   & write       &      &       &       &        &        &        &            &               \\ \hline
    11 classify\_bytes &        & read        &      & write &       &        &        &        &            &               \\ \hline
    12 validate\_u8    &        & read        & write&       &       &        &        &        &            &               \\ \hline
    13 gen\_scope      &        &             &      & read  & write &        &        &        &            &               \\ \hline
    14 parse\_CtCDPI   &        &             &      & read  & read  & write  &        &        &            & write         \\ \hline
    15 parse\_ref      &        &             &      & read  & read  & read   & write  &        &            &               \\ \hline
    16 parse\_tag      &        &             &      & read  & read  & read   &        & write  &            &               \\ \hline
    17 validate\_name  &        &             & read & read  &       & read   & read   & read   & write      & write         \\ \hline
    18 gen\_check      &        &             & read & read  & read  & read   &        & read   & read       & write         \\ \hline
    19 postprocessing  & read   &             &      & read  &       & read   & read   &        &            & read          \\ \hline
     36       & & \multicolumn{10}{|c|}{Data Structures}\\ \hline
     37       &                & srcbuf & basis\_bits & u8   & lex   & scope & ctCDPI & ref    & tag    & xml\_names & check\_streams\\ \hline
     38Stage1 &fill\_buffer    & write  &             &      &       &       &        &        &        &            &               \\
     39       &s2p             & read   & write       &      &       &       &        &        &        &            &               \\
     40       &classify\_bytes &        & read        &      & write &       &        &        &        &            &               \\ \hline
     41Stage2 &validate\_u8    &        & read        & write&       &       &        &        &        &            &               \\
     42       &gen\_scope      &        &             &      & read  & write &        &        &        &            &               \\
     43       &parse\_CtCDPI   &        &             &      & read  & read  & write  &        &        &            & write         \\
     44       &parse\_ref      &        &             &      & read  & read  & read   & write  &        &            &               \\ \hline
     45Stage3 &parse\_tag      &        &             &      & read  & read  & read   &        & write  &            &               \\
     46       &validate\_name  &        &             & read & read  &       & read   & read   & read   & write      & write         \\
     47       &gen\_check      &        &             & read & read  & read  & read   &        & read   & read       & write         \\ \hline
     48Stage4 &postprocessing  & read   &             &      & read  &       & read   & read   &        &            & read          \\ \hline
    2049\end{tabular}
    2150\end{center}
     
    2453\end{table*}
    2554
     55Figure \ref{multithread_perf} demonstrates the XML well-formedness checking performance of
     56the multi-threaded Parabix in comparison with the single-threaded version.
     57The multi-threaded Parabix is more than two times faster and runs at 2.7 cycles per input byte on the \SB{} machine.
    2658
    2759\begin{figure}
     
    3062\end{center}
    3163\caption{Processing Time (y axis: CPU cycles per byte)}
    32 \label{perf}
     64\label{multithread_perf}
    3365\end{figure}
     66
     67Figure \ref{power} shows the average power consumed by the multi-threaded Parabix in comparison with the single-threaded version.
     68By running four threads and using all the cores at the same time, the power consumption of the multi-threaded Parabix is much higher
     69than the single-threaded version. However, the energy consumption is about the same, because the multi-threaded Parabix needs less processing time.
     70In fact, as shown in Figure \ref{energy}, parsing soap.xml using multi-threaded Parabix consumes less energy than using single-threaded Parabix.
    3471
    3572\begin{figure}
    3673\begin{center}
    37 \includegraphics[width=0.5\textwidth]{plots/perf_energy.pdf}
     74\includegraphics[width=0.5\textwidth]{plots/power.pdf}
    3875\end{center}
    39 \caption{Energy vs. Performance (x axis: bytes per cycle, y axis: nJ per byte)}
    40 \label{perf_energy}
     76\caption{Average Power (watts)}
     77\label{power}
     78\end{figure}
     79\begin{figure}
     80\begin{center}
     81\includegraphics[width=0.5\textwidth]{plots/energy.pdf}
     82\end{center}
     83\caption{Energy Consumption (nJ per byte)}
     84\label{energy}
    4185\end{figure}
    4286
Note: See TracChangeset for help on using the changeset viewer.