227 lines
22 KiB
HTML
Executable File
227 lines
22 KiB
HTML
Executable File
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html><head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
|
|
<title>MPI On Cell (Documentation): include/doxygen_pages.doxygen Source File</title>
|
|
<link href="../../doxygen.css" rel="stylesheet" type="text/css">
|
|
<link href="../../tabs.css" rel="stylesheet" type="text/css">
|
|
</head><body>
|
|
<!-- Generated by Doxygen 1.5.6 -->
|
|
<div class="navigation" id="top">
|
|
<div class="tabs">
|
|
<ul>
|
|
<li><a href="../../main.html"><span>Main Page</span></a></li>
|
|
<li><a href="../../modules.html"><span>Modules</span></a></li>
|
|
<li><a href="../../annotated.html"><span>Data Structures</span></a></li>
|
|
<li class="current"><a href="../../files.html"><span>Files</span></a></li>
|
|
</ul>
|
|
</div>
|
|
<h1>include/doxygen_pages.doxygen</h1><a href="../../da/d63/doxygen__pages_8doxygen.html">Go to the documentation of this file.</a><div class="fragment"><pre class="fragment"><a name="l00001"></a>00001
|
|
<a name="l00002"></a>00002 <span class="comment"></span>
|
|
<a name="l00003"></a>00003 <span class="comment">/**</span>
|
|
<a name="l00004"></a>00004 <span class="comment"> * \page restrictions Restrictions of the Cell-Architecture</span>
|
|
<a name="l00005"></a>00005 <span class="comment"> *</span>
|
|
<a name="l00006"></a>00006 <span class="comment"> * \par</span>
|
|
<a name="l00007"></a>00007 <span class="comment"> * \section res_arch CBE Architecture</span>
|
|
<a name="l00008"></a>00008 <span class="comment"> *</span>
|
|
<a name="l00009"></a>00009 <span class="comment"> * There are some restriction caused by the CBE architecture. Programming a SPU can be</span>
|
|
<a name="l00010"></a>00010 <span class="comment"> * compared to programming a microcontroller:</span>
|
|
<a name="l00011"></a>00011 <span class="comment"> * \li \b Small \b local-store \b of \b SPUs: Only 256 KByte of local-store are available</span>
|
|
<a name="l00012"></a>00012 <span class="comment"> * on a SPU which is moreover shared by data and instructions. Because of this a economic</span>
|
|
<a name="l00013"></a>00013 <span class="comment"> * stewardship of available resources is needed.</span>
|
|
<a name="l00014"></a>00014 <span class="comment"> * \li \b No \b underlying \b OS: The operation system is running on the PPU, but not on</span>
|
|
<a name="l00015"></a>00015 <span class="comment"> * the SPUs. Although the OS also manages the SPUs, there are some things which</span>
|
|
<a name="l00016"></a>00016 <span class="comment"> * are missing or have to be done in a very performance decreasing and complex way.</span>
|
|
<a name="l00017"></a>00017 <span class="comment"> * E.g. there is no support for several threads on one SPU (unless you program it yourself)</span>
|
|
<a name="l00018"></a>00018 <span class="comment"> * and most of the system-calls are delegated to the PPU.</span>
|
|
<a name="l00019"></a>00019 <span class="comment"> * \li \b Limited \b I/O-Capabilities: File-operations are only possible on the PPU. So if you</span>
|
|
<a name="l00020"></a>00020 <span class="comment"> * want to store data of an SPU into a file, you have to send it to the PPU who then stores</span>
|
|
<a name="l00021"></a>00021 <span class="comment"> * the data into a file. Main-memory is managed by the PPU and the SPUs can only read</span>
|
|
<a name="l00022"></a>00022 <span class="comment"> * from or write into the main-memory. Allocation of main-memory has to be done by the PPU.</span>
|
|
<a name="l00023"></a>00023 <span class="comment"> *</span>
|
|
<a name="l00024"></a>00024 <span class="comment"> *</span>
|
|
<a name="l00025"></a>00025 <span class="comment"> * \par</span>
|
|
<a name="l00026"></a>00026 <span class="comment"> * \section res_alignment Memory-Alignment</span>
|
|
<a name="l00027"></a>00027 <span class="comment"> *</span>
|
|
<a name="l00028"></a>00028 <span class="comment"> * All Buffers used in send- or receive-functions have to be aligned at a 16-byte boundary</span>
|
|
<a name="l00029"></a>00029 <span class="comment"> * (for better performance a 128-byte alignment is recommended). This restriction cannot be</span>
|
|
<a name="l00030"></a>00030 <span class="comment"> * circumvented.</span>
|
|
<a name="l00031"></a>00031 <span class="comment"> *</span>
|
|
<a name="l00032"></a>00032 <span class="comment"> *</span>
|
|
<a name="l00033"></a>00033 <span class="comment"> * \par</span>
|
|
<a name="l00034"></a>00034 <span class="comment"> * \section res_size Transfer-Size</span>
|
|
<a name="l00035"></a>00035 <span class="comment"> *</span>
|
|
<a name="l00036"></a>00036 <span class="comment"> * DMA-calls only transfer data in chunks of 16 bytes. Send-receive operations and</span>
|
|
<a name="l00037"></a>00037 <span class="comment"> * DMA-get-operations provided by this library hide this restriction by the use of intermediate</span>
|
|
<a name="l00038"></a>00038 <span class="comment"> * buffers. But you should keep this restriction in mind because to gain maximum performance</span>
|
|
<a name="l00039"></a>00039 <span class="comment"> * the size of data to be transfered should be a multiple of 16 bytes.</span>
|
|
<a name="l00040"></a>00040 <span class="comment"> *</span>
|
|
<a name="l00041"></a>00041 <span class="comment"> *</span>
|
|
<a name="l00042"></a>00042 <span class="comment"> *</span>
|
|
<a name="l00043"></a>00043 <span class="comment"> **/</span>
|
|
<a name="l00044"></a>00044
|
|
<a name="l00045"></a>00045 <span class="comment"></span>
|
|
<a name="l00046"></a>00046 <span class="comment">/**</span>
|
|
<a name="l00047"></a>00047 <span class="comment"> * \page violations Violations of the MPI-Standard</span>
|
|
<a name="l00048"></a>00048 <span class="comment"> *</span>
|
|
<a name="l00049"></a>00049 <span class="comment"> * \par</span>
|
|
<a name="l00050"></a>00050 <span class="comment"> * \section viol_prefix Prefix of functions:</span>
|
|
<a name="l00051"></a>00051 <span class="comment"> *</span>
|
|
<a name="l00052"></a>00052 <span class="comment"> * The prefix of functions and data-structures is not 'MPI_' as stated by the MPI-standard.</span>
|
|
<a name="l00053"></a>00053 <span class="comment"> * Instead it is 'MOC_' to allow the usage of another MPI-Library (e.g. to connect several</span>
|
|
<a name="l00054"></a>00054 <span class="comment"> * playstations) and to stress that this implementation is not fully conform with the</span>
|
|
<a name="l00055"></a>00055 <span class="comment"> * MPI-standard.</span>
|
|
<a name="l00056"></a>00056 <span class="comment"> *</span>
|
|
<a name="l00057"></a>00057 <span class="comment"> *</span>
|
|
<a name="l00058"></a>00058 <span class="comment"> * \par</span>
|
|
<a name="l00059"></a>00059 <span class="comment"> * \section viol_startup Application Startup</span>
|
|
<a name="l00060"></a>00060 <span class="comment"> *</span>
|
|
<a name="l00061"></a>00061 <span class="comment"> * MPI-applications (Version 1.3) are started using mpiexec/mpirun and normally only one</span>
|
|
<a name="l00062"></a>00062 <span class="comment"> * binary is executed on all MPI-nodes. Because PPU- and SPU-instructions aren't compatible</span>
|
|
<a name="l00063"></a>00063 <span class="comment"> * at least two executables (and two compilers) are needed. Also SPU-threads have to be initialized</span>
|
|
<a name="l00064"></a>00064 <span class="comment"> * and started by the PPU. Because of this the SPU-binaries are embedded into the PPU-binary</span>
|
|
<a name="l00065"></a>00065 <span class="comment"> * and started by this PPU-binary during runtime.</span>
|
|
<a name="l00066"></a>00066 <span class="comment"> * In this library this concept is also used. So you have to program at least one PPU- and one</span>
|
|
<a name="l00067"></a>00067 <span class="comment"> * SPU-program, embed the SPU-program into the PPU-executable and add the SPU-program-handle to</span>
|
|
<a name="l00068"></a>00068 <span class="comment"> * the MOC-environment (see \ref MOC_Add_spu_thread) during runtime before calling MOC_Init.</span>
|
|
<a name="l00069"></a>00069 <span class="comment"> *</span>
|
|
<a name="l00070"></a>00070 <span class="comment"> *</span>
|
|
<a name="l00071"></a>00071 <span class="comment"> * \par</span>
|
|
<a name="l00072"></a>00072 <span class="comment"> * \section viol_queue Order of received messages:</span>
|
|
<a name="l00073"></a>00073 <span class="comment"> *</span>
|
|
<a name="l00074"></a>00074 <span class="comment"> * Because of the internal design of this implementation the order of</span>
|
|
<a name="l00075"></a>00075 <span class="comment"> * incoming messages cannot be preserved in all cases. Currently the</span>
|
|
<a name="l00076"></a>00076 <span class="comment"> * correct order is only preserved from messages from the same source,</span>
|
|
<a name="l00077"></a>00077 <span class="comment"> * with the same message-tag and same communicator.</span>
|
|
<a name="l00078"></a>00078 <span class="comment"> *</span>
|
|
<a name="l00079"></a>00079 <span class="comment"> *</span>
|
|
<a name="l00080"></a>00080 <span class="comment"> * \par</span>
|
|
<a name="l00081"></a>00081 <span class="comment"> * \section viol_tag Number of usable message-tag</span>
|
|
<a name="l00082"></a>00082 <span class="comment"> *</span>
|
|
<a name="l00083"></a>00083 <span class="comment"> * According to the MPI-standard there should be at least 32767 tags available. But to save</span>
|
|
<a name="l00084"></a>00084 <span class="comment"> * memory we use only one byte to encode the message-tag. So there are only 256 usable</span>
|
|
<a name="l00085"></a>00085 <span class="comment"> * message-tags. Message-tags greater than 249 are reserved for internal purposes.</span>
|
|
<a name="l00086"></a>00086 <span class="comment"> *</span>
|
|
<a name="l00087"></a>00087 <span class="comment"> *</span>
|
|
<a name="l00088"></a>00088 <span class="comment"> * \par</span>
|
|
<a name="l00089"></a>00089 <span class="comment"> * \section viol_nr_pending Number of simultaneous pending send-receive operations</span>
|
|
<a name="l00090"></a>00090 <span class="comment"> *</span>
|
|
<a name="l00091"></a>00091 <span class="comment"> * According to the MPI-standard there should be hardly any limitations in the number of</span>
|
|
<a name="l00092"></a>00092 <span class="comment"> * possible simultaneous transfers. It is stated that only in pathological cases the maximum</span>
|
|
<a name="l00093"></a>00093 <span class="comment"> * of possible outstanding transfers should be reached. Because the resources of an SPU are</span>
|
|
<a name="l00094"></a>00094 <span class="comment"> * very limited our implementation has a tight limit of possible simultaneous transfers.</span>
|
|
<a name="l00095"></a>00095 <span class="comment"> * Although the upper-limit can be changed using \ref MOC_Set_queue_size, it is limited by</span>
|
|
<a name="l00096"></a>00096 <span class="comment"> * the 256 KByte of local-storage of a SPU.</span>
|
|
<a name="l00097"></a>00097 <span class="comment"> * There is also a limit of the number of simultaneous DMA-calls, because for each DMA-operation</span>
|
|
<a name="l00098"></a>00098 <span class="comment"> * an exclusive DMA-tag is used and there are only 32 DMA-tag (on the PPU only 15) available.</span>
|
|
<a name="l00099"></a>00099 <span class="comment"> *</span>
|
|
<a name="l00100"></a>00100 <span class="comment"> * \par</span>
|
|
<a name="l00101"></a>00101 <span class="comment"> * \section viol_init MPI_Init:</span>
|
|
<a name="l00102"></a>00102 <span class="comment"> *</span>
|
|
<a name="l00103"></a>00103 <span class="comment"> * The parameters of the init-function for the SPU does not match the parameters</span>
|
|
<a name="l00104"></a>00104 <span class="comment"> * defined by the MPI-standard (see \ref moc_init_spu "MOC_Init (SPU)")</span>
|
|
<a name="l00105"></a>00105 <span class="comment"> *</span>
|
|
<a name="l00106"></a>00106 <span class="comment"> *</span>
|
|
<a name="l00107"></a>00107 <span class="comment"> **/</span>
|
|
<a name="l00108"></a>00108
|
|
<a name="l00109"></a>00109 <span class="comment"></span>
|
|
<a name="l00110"></a>00110 <span class="comment">/**</span>
|
|
<a name="l00111"></a>00111 <span class="comment"> * \page performance Performance Measurements</span>
|
|
<a name="l00112"></a>00112 <span class="comment"> *</span>
|
|
<a name="l00113"></a>00113 <span class="comment"> * The measurements were taken on a Playstation 3 running Yellow Dog Linux release 6.0</span>
|
|
<a name="l00114"></a>00114 <span class="comment"> * using Cell SDK 3.1. To measure send-receive operations ping-pongs were used and to</span>
|
|
<a name="l00115"></a>00115 <span class="comment"> * measure DMA-calls the time till the used DMA-tag is marked to have no pending calls</span>
|
|
<a name="l00116"></a>00116 <span class="comment"> * is used. The stated latencies in the pictures above are one-way latencies.</span>
|
|
<a name="l00117"></a>00117 <span class="comment"> *</span>
|
|
<a name="l00118"></a>00118 <span class="comment"> * \section perf_send_recv Send-Receive performance</span>
|
|
<a name="l00119"></a>00119 <span class="comment"> *</span>
|
|
<a name="l00120"></a>00120 <span class="comment"> * The following two figures show latency and bandwidth achieved by our implementation.</span>
|
|
<a name="l00121"></a>00121 <span class="comment"> * The theoretical maximum bandwidth is 25 GByte/s and synchronous send between SPUs is</span>
|
|
<a name="l00122"></a>00122 <span class="comment"> * at a close range to this limit if the data-size is large enough. There is also a big</span>
|
|
<a name="l00123"></a>00123 <span class="comment"> * difference between SPU-SPU and SPU-PPU operations. The reason for this is the fact that</span>
|
|
<a name="l00124"></a>00124 <span class="comment"> * the PPU cannot handle DMA-operations itself but only remote-control the SPU's</span>
|
|
<a name="l00125"></a>00125 <span class="comment"> * Memory Flow Controller. And as you will see later the main-memory performance of the PPU</span>
|
|
<a name="l00126"></a>00126 <span class="comment"> * is much lower than that of the SPUs. Because we use ping-pongs there is no way to</span>
|
|
<a name="l00127"></a>00127 <span class="comment"> * determine differences in sending from or to the PPU, but other measurements indicate</span>
|
|
<a name="l00128"></a>00128 <span class="comment"> * such differences.</span>
|
|
<a name="l00129"></a>00129 <span class="comment"> *</span>
|
|
<a name="l00130"></a>00130 <span class="comment"> * \image html latency-kb.png</span>
|
|
<a name="l00131"></a>00131 <span class="comment"> *</span>
|
|
<a name="l00132"></a>00132 <span class="comment"> * \image html bandwidth-kb.png</span>
|
|
<a name="l00133"></a>00133 <span class="comment"> *</span>
|
|
<a name="l00134"></a>00134 <span class="comment"> * The following figure shows the latency of send-receive operations at a lower scale than</span>
|
|
<a name="l00135"></a>00135 <span class="comment"> * the first figure. If you look at the latency of synchronous send operations then you can</span>
|
|
<a name="l00136"></a>00136 <span class="comment"> * see that there is a big start-up latency and only a very small data-size dependend latency.</span>
|
|
<a name="l00137"></a>00137 <span class="comment"> * So there's only a very small time-difference between sending 10 byte and 1 Kbyte, but there</span>
|
|
<a name="l00138"></a>00138 <span class="comment"> * is naturally a difference in throughput.</span>
|
|
<a name="l00139"></a>00139 <span class="comment"> *</span>
|
|
<a name="l00140"></a>00140 <span class="comment"> * \image html latency-b.png</span>
|
|
<a name="l00141"></a>00141 <span class="comment"> *</span>
|
|
<a name="l00142"></a>00142 <span class="comment"> * \section perf_moc_vs_dma Send-Recv vs. DMA performance</span>
|
|
<a name="l00143"></a>00143 <span class="comment"> *</span>
|
|
<a name="l00144"></a>00144 <span class="comment"> * The following two figures demonstrate the difference in performance of send-recv operations</span>
|
|
<a name="l00145"></a>00145 <span class="comment"> * and DMA-calls. The performance of DMA-calls reaches it's peak much earlier than send-recv</span>
|
|
<a name="l00146"></a>00146 <span class="comment"> * and the peak-value is higher than that of send-recv even though the difference is not much.</span>
|
|
<a name="l00147"></a>00147 <span class="comment"> * So DMA is a lot faster than send-recv especially for small messages, but for big messages</span>
|
|
<a name="l00148"></a>00148 <span class="comment"> * the difference is much lower. It seems that it is always better to use DMA, but keep in mind</span>
|
|
<a name="l00149"></a>00149 <span class="comment"> * that in practical applications calculation time easily exceeds communication time.</span>
|
|
<a name="l00150"></a>00150 <span class="comment"> *</span>
|
|
<a name="l00151"></a>00151 <span class="comment"> * \image html dma-vs-moc-lat.png</span>
|
|
<a name="l00152"></a>00152 <span class="comment"> *</span>
|
|
<a name="l00153"></a>00153 <span class="comment"> * \image html dma-vs-moc-bw.png</span>
|
|
<a name="l00154"></a>00154 <span class="comment"> *</span>
|
|
<a name="l00155"></a>00155 <span class="comment"> * \section perf_spu_vs_ppu SPU- vs PPU-initiated transfer</span>
|
|
<a name="l00156"></a>00156 <span class="comment"> *</span>
|
|
<a name="l00157"></a>00157 <span class="comment"> * The following figure shows the difference between SPU- and PPU-initiated DMA-calls.</span>
|
|
<a name="l00158"></a>00158 <span class="comment"> * As you can see the highest performance can be achieved by using SPU-SPU DMA-calls. There</span>
|
|
<a name="l00159"></a>00159 <span class="comment"> * is also hardly any difference between put and get operations. DMA-operations between SPU and</span>
|
|
<a name="l00160"></a>00160 <span class="comment"> * main-memory achieves lower performance and there is a difference between put and get</span>
|
|
<a name="l00161"></a>00161 <span class="comment"> * operations. PPU to SPU DMA calls have the lowest performance with small transfer sizes, but</span>
|
|
<a name="l00162"></a>00162 <span class="comment"> * if the transfer-size is big enough they are faster than SPU-main-memory transfers.</span>
|
|
<a name="l00163"></a>00163 <span class="comment"> * The lowest performance has a memcopy on the PPU, which also explains the bad performance of</span>
|
|
<a name="l00164"></a>00164 <span class="comment"> * buffered send between SPU and PPU.</span>
|
|
<a name="l00165"></a>00165 <span class="comment"> *</span>
|
|
<a name="l00166"></a>00166 <span class="comment"> * \image html spu-ppu-dma-bw-kb.png</span>
|
|
<a name="l00167"></a>00167 <span class="comment"> *</span>
|
|
<a name="l00168"></a>00168 <span class="comment"> * \section perf_mem DMA vs. memcpy</span>
|
|
<a name="l00169"></a>00169 <span class="comment"> *</span>
|
|
<a name="l00170"></a>00170 <span class="comment"> * The official Cell documentation states that it is also possible to use</span>
|
|
<a name="l00171"></a>00171 <span class="comment"> * memcpy to transfer data from the PPU to a SPU. However one should use</span>
|
|
<a name="l00172"></a>00172 <span class="comment"> * DMA, because it is always faster.</span>
|
|
<a name="l00173"></a>00173 <span class="comment"> * If you look at the following figure, this is not always true. If the</span>
|
|
<a name="l00174"></a>00174 <span class="comment"> * data-size is small enough memcpy is faster.</span>
|
|
<a name="l00175"></a>00175 <span class="comment"> *</span>
|
|
<a name="l00176"></a>00176 <span class="comment"> * \image html ppu-transfer-bw-b.png</span>
|
|
<a name="l00177"></a>00177 <span class="comment"> *</span>
|
|
<a name="l00178"></a>00178 <span class="comment"> **/</span>
|
|
<a name="l00179"></a>00179
|
|
<a name="l00180"></a>00180
|
|
<a name="l00181"></a>00181 <span class="comment"></span>
|
|
<a name="l00182"></a>00182 <span class="comment">/**</span>
|
|
<a name="l00183"></a>00183 <span class="comment"> * \page conclusion Summary & Conclusions</span>
|
|
<a name="l00184"></a>00184 <span class="comment"> *</span>
|
|
<a name="l00185"></a>00185 <span class="comment"> * \details MPI wasn't designed for the Cell Broadband Engine. A common MPI-node has one or more</span>
|
|
<a name="l00186"></a>00186 <span class="comment"> * normal CPUs and several GBytes of RAM. The Cell Broadband Engine features a normal CPU</span>
|
|
<a name="l00187"></a>00187 <span class="comment"> * (the PPU) and several special processing units with only a very limited amount</span>
|
|
<a name="l00188"></a>00188 <span class="comment"> * of memory. The SPUs support only one thread per SPU and a complex handling of system-calls</span>
|
|
<a name="l00189"></a>00189 <span class="comment"> * is needed. Because of this there are several restrictions in implementing MPI on the Cell</span>
|
|
<a name="l00190"></a>00190 <span class="comment"> * Broadband Engine.</span>
|
|
<a name="l00191"></a>00191 <span class="comment"> *</span>
|
|
<a name="l00192"></a>00192 <span class="comment"> * Nevertheless MPI on Cell makes sense. It greatly simlifies programming on the Cell Broadband</span>
|
|
<a name="l00193"></a>00193 <span class="comment"> * Engine, features a public API which is well known and widely used and message passing operations</span>
|
|
<a name="l00194"></a>00194 <span class="comment"> * are generally easier to use than DMA (DMA needs memory-addresses and explicit synchronization,</span>
|
|
<a name="l00195"></a>00195 <span class="comment"> * whereas MPI only needs the ranks of participating processes and features implicit</span>
|
|
<a name="l00196"></a>00196 <span class="comment"> * synchronization).</span>
|
|
<a name="l00197"></a>00197 <span class="comment"> *</span>
|
|
<a name="l00198"></a>00198 <span class="comment"> * But message parsing operations cannot replace DMA. Both methods of communication have their</span>
|
|
<a name="l00199"></a>00199 <span class="comment"> * advantages and disadvantages and they complement one another. So this library additionally</span>
|
|
<a name="l00200"></a>00200 <span class="comment"> * features some easy to use DMA operations, if someone wants to gain maximum performance. Using</span>
|
|
<a name="l00201"></a>00201 <span class="comment"> * DMA alltogether with send-recv especially speeds up application with a lot of communication</span>
|
|
<a name="l00202"></a>00202 <span class="comment"> * going on between SPUs and PPU.</span>
|
|
<a name="l00203"></a>00203 <span class="comment"> **/</span>
|
|
<a name="l00204"></a>00204
|
|
</pre></div></div>
|
|
<hr size="1"><address style="text-align: right;"><small>Generated on Thu Feb 12 13:49:47 2009 for MPI On Cell (Documentation) by
|
|
<a href="http://www.doxygen.org/index.html">
|
|
<img src="../../doxygen.png" alt="doxygen" align="middle" border="0"></a> 1.5.6 </small></address>
|
|
</body>
|
|
</html>
|