【正文】 | | | 16, 32 |++++++| 相乘 | 16 | | | 8x16 |++++++| 相加 | 8, 16, 32 | | 16 | 16, 32 |++++++在這個表中，這些數(shù)字表明了字段的大小，以位為單位，因此每個操作都是支持的。考慮推行使用四個原色的8位整型向量通過使用普通32位操作來實現(xiàn)兩個源向量的相加操作。很顯然結(jié)果是正確的，除了每個字段里的最有效位。控制字段值而另外兩個分區(qū)的操作方法來執(zhí)行兩個寄存器中心得到利用的最大空間，可以更有效地計算，而不是控制字段值，使不同字段間的進/借位永遠不會發(fā)生。 | D 6:0 | C39。然而，這次修改卻非常簡單。例如，例如，即使像素的FFT變換一樣的操作，如需要相鄰像素值從操作數(shù)，并作為平滑需要更復(fù)雜的（較少本地化）的通訊模式。 0x000000ff))真正的問題是當更一般的溝通模式必須得到執(zhí)行。然而，x[y]以后都慢于鄰近的溝通計算機，即便是這些超級計算機，所以許多算法的目的是為了盡量減少x[y]操作的需要。 ++i) t += x[i]。 0x000003ff)其實，第二步執(zhí)行兩個16位字段的相加…但前16位加法是沒有意義的，這就是為什么結(jié)果是一個偽10位的結(jié)果。 特別是，英特爾已經(jīng)開發(fā)了幾個“性能庫”，能夠向用戶提供各種任務(wù)的手，共同優(yōu)化多媒體程序。這些工具目前正在發(fā)展，但還沒有一個在Linux下充分發(fā)揮作用。inline externint mmx_init(void){ int mmx_available。例如，MMX指令PADDB MM0，MM1可被編碼為GCC里的如下代碼：__asm__ __volatile__ (.byte 0x0f, 0xfc, 0xc1\n\t)。在知道幾乎所有研究都是居于自己之前，理解一個道理：盡管它可能很難找到一個適當?shù)腖inux PC主機特定的系統(tǒng)，在Linux平臺PC是一個非常適合少數(shù)這種使用類型。源代碼免費提供全面和廣泛的“黑客”導(dǎo)游，顯然是一個巨大的幫助。，特別是每MIP或MFLOP。雖然有些聲卡和調(diào)制解調(diào)器包括DSP處理器的Linux驅(qū)動程序可以訪問，大收益來自使用一個附加的有四個或更多的DSP處理器的并行系統(tǒng)。 其他的DSP處理器家族最近已經(jīng)被用于連接并行系統(tǒng)，有ADI公司的SHARC（又名，ADSP2106x）。但是，最近進展中的電可編程FPGA（現(xiàn)場可編程門陣列）已廢止了那些反對。Altera的ARC的PCI（Altera的可重構(gòu)計算機，PCI總線），是同類型的卡，但是使用的是Altera FPGA和一個PCI總線，而不是ISA總線。出于他們的用途來使用這些語言和編譯器，你會更更短的開發(fā)時間，更容易調(diào)試和維修等。如我們以前認識的CM Fortran語言，MasPar Fortran，或者Fortran D；它延伸的Fortran90具有增強的并行處理的布局，主要集中在制定的數(shù)據(jù)。免費提供的并行Fortrans可能工作于的并行Linux系統(tǒng)包括：（自動數(shù)據(jù)并行翻譯，），它們可以利用MPC或PVM將HPF翻譯成77/90代碼，但沒有提及到Linux。GLU（清晰的粒狀結(jié)構(gòu)）GLU（清晰的粒狀結(jié)構(gòu)）是一個非常高層次的建立在混合編程模型上的編程系統(tǒng)，結(jié)合了內(nèi)涵和必要的模型。Mentat執(zhí)行系統(tǒng)使用類似于非阻塞遠程調(diào)用技術(shù)。網(wǎng)絡(luò)版Linux機組還未被支持。它能否運行于Linux ?更多的信息可見。它生成調(diào)用一個簡單的消息傳遞接口，稱為鐵人，并通過系統(tǒng)一些功能，構(gòu)成這個接口可以很容易地實現(xiàn)使用幾乎任何消息。盡管如此，有一些硬件差異你還是應(yīng)該注意的。 至少有一些現(xiàn)代化的處理器采用熱傳感器和電路，用于內(nèi)部時鐘速度慢，如果工作溫度過高（企圖減少熱輸出，提高可靠性）。 我建議至少有一臺備用，并希望有至少一個群集不遺余力地為沒一臺16電腦貢獻自己的力量。這個文件的各種項目中列出了各個地方相似的并行Linux配置等。在沒有一個明確的聯(lián)絡(luò)人請求的情況下，不會有任何網(wǎng)站被列出。 AMD K6 MMX (MultiMedia eXtensions) Sun SPARC V9 VIS (Visual Instruction Set) There are a few holes in the hardware support provided by the new microprocessors, quirks like only supporting some operations for some field sizes. It is important to remember, however, that you don39。s consider a greatly simplified SWAR mechanism that manages four 8bit fields within each 32bit register. The values in two registers might be represented as: PE3 PE2 PE1 PE0 +++++Reg0 | D 7:0 | C 7:0 | B 7:0 | A 7:0 | +++++Reg1 | H 7:0 | G 7:0 | F 7:0 | E 7:0 | +++++This simply indicates that each register is viewed as essentially a vector of four independent 8bit integer values. Alternatively, think of A and E as values in Reg0 and Reg1 of processing element 0 (PE0), B and F as values in PE139。s instruction set and generally places many restrictions on field size (., 8bit fields might be supported, but not 12bit fields). The AMD/Cyrix/Intel MMX, Digital MAX, HP MAX, and Sun VIS all implement restricted versions of partitioned instructions. Unfortunately, these different instruction set extensions have significantly different restrictions, making algorithms somewhat nonportable between them. For example, consider the following sampling of partitioned operations: Instruction AMD/Cyrix/Intel MMX DEC MAX HP MAX Sun VIS++++++| Absolute Difference | | 8 | | 8 |++++++| Merge Maximum | | 8, 16 | | |++++++| Compare | 8, 16, 32 | | | 16, 32 |++++++| Multiply | 16 | | | 8x16 |++++++| Add | 8, 16, 32 | | 16 | 16, 32 |++++++In the table, the numbers indicate the field sizes, in bits, for which each operation is supported. Even though the table omits many instructions including all the more exotic ones, it is clear that there are many differences. The direct result is that highlevel languages (HLLs) really are not very effective as programming models, and portability is generally poor. Unpartitioned Operations With Correction CodeImplementing partitioned operations using partitioned instructions can certainly be efficient, but what do you do if the partitioned operation you need is not supported by the hardware? The answer is that you use a series of ordinary instructions to perform the operation with carry/borrow across fields, and then correct for the undesired field interactions. This is a purely software approach, and the corrections do introduce overhead, but it works with fully general field partitioning. This approach is also fully general in that it can be used either to fill gaps in the hardware support for partitioned instructions, or it can be used to provide full functionality for target machines that have no hardware support at all. In fact, by expressing the code sequences in a language like C, this approach allows SWAR programs to be fully portable. The question immediately arises: precisely how inefficient is it to simulate SWAR partitioned operations using unpartitioned operations with correction code? Well, that is certainly the $64k question... but many operations are not as difficult as one might expect. Consider implementing a fourelement 8bit integer vector add of two source v。s amp。 Integers