• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            We build the dream world digital.

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              2 Posts :: 0 Stories :: 8 Comments :: 0 Trackbacks
            SSE Assembler vs Optimizied C++
            打破匯編的神話?


            匯編語言對(duì)于軟件工程人員來說,是高速精簡(jiǎn)的代稱,但同時(shí)也是晦澀難懂的代名詞。學(xué)校的老師,各種各樣的書籍寶典,總是舉出各種各樣的例子來向我們灌輸著這樣一個(gè)定律:C++編譯后產(chǎn)生的代碼在執(zhí)行效率上不如匯編編譯成機(jī)器代碼。但是匯編代碼在編寫的時(shí)候晦澀難懂,使得開發(fā)效率大為降低。但是在那個(gè)CPU寄存器非常珍貴,內(nèi)存異樣稀少的時(shí)代,匯編相對(duì)C有著獨(dú)特的優(yōu)勢(shì),可以極其精確的為每一個(gè)變量分配寄存器和內(nèi)存,但是同時(shí)也使得開發(fā)過程緩慢無比,因?yàn)橐徊涣羯窬蜁?huì)造成寄存器分配沖突。同時(shí)由于那個(gè)時(shí)代的C++的編譯器的編譯效率不高,造成了編譯的時(shí)候產(chǎn)生的代碼無論在算法和體積上都無法和匯編相比。

            最近在編寫引擎的時(shí)候,一直在匯編的執(zhí)行效率和C++的編寫效率上猶豫不覺。一開始試著編寫了2個(gè)不同版本的Vector類,叉積分別使用SSE匯編和C++優(yōu)化。然后我試著編譯了這兩個(gè)不同的版本,編譯的時(shí)候?qū)⑺袃?yōu)化選項(xiàng)全部打開,并最大化速度優(yōu)先。測(cè)試程序?qū)τ诿總€(gè)版本調(diào)用1億次叉積運(yùn)算,總共進(jìn)行了10次,最后的出的結(jié)果令人瞠目結(jié)舌。SSE匯編10次測(cè)試全部敗于C++,C++所用的時(shí)間只相當(dāng)于SSE的三分之一。

            今天新編了一個(gè)四元數(shù)類,同樣在從四元數(shù)向矩陣的轉(zhuǎn)換中,使用了Intel網(wǎng)站上的Id Software的匯編代碼,和C++代碼。同樣進(jìn)行速度最大化優(yōu)化,1億次轉(zhuǎn)換測(cè)試,結(jié)果在預(yù)測(cè)之內(nèi),差別雖然沒有向量測(cè)試的那么驚人,但C++仍然比匯編高效。

            新一代編譯器都支持在編譯時(shí)打開SSE增強(qiáng)指令集,這意味著,包括Visual Studio在內(nèi)的C++編譯器,能夠在從C/C++到匯編代碼的過程中,自動(dòng)盡可能的使用SSE增強(qiáng)指令集來提高匯編代碼效率。手寫SSE匯編,由于人員之間的水平差異,不可能將匯編代碼優(yōu)化到最高水準(zhǔn),而編譯器使用了高效的算法來優(yōu)化產(chǎn)生的匯編代碼,這使得,一個(gè)資質(zhì)普通的程序員寫出的SSE代碼,會(huì)比由C++編譯器編譯出的匯編代碼要慢的多。當(dāng)然這個(gè)世界上總是有著驚人天賦的天才,一定能夠在同等條件下寫出比編譯器快得多的匯編代碼,但是這不具有普遍性,在軟件業(yè)高速發(fā)展的今天,通用性,易用性,費(fèi)效比,以及重用性才是軟件工程中最重要的,而花大錢雇一個(gè)匯編高手來寫核心意味著這個(gè)代碼具有最差的移植性,最差的可讀性,以及最差的重用性,這是不可取的。

            我們應(yīng)該相信現(xiàn)代編譯器能夠在最短時(shí)間內(nèi)編譯出最優(yōu)代碼,而事實(shí)上,這個(gè)也已經(jīng)成為了既定的現(xiàn)實(shí)。拋棄手動(dòng)的SSE匯編,讓編譯器來完成這項(xiàng)工作,是最明智的做法。當(dāng)然我們應(yīng)該在編寫C++代碼時(shí)稍微考慮一下數(shù)據(jù)流的生成順序,以便讓編譯器發(fā)揮出最大效能,至于如何優(yōu)化數(shù)據(jù)流,將在下一篇中介紹。

            ps: 在Visual Studio.NET 2003下,將“啟用增強(qiáng)指令集”設(shè)置為SSE/SSE2即可。

            posted on 2007-01-05 11:35 如展 閱讀(1747) 評(píng)論(6)  編輯 收藏 引用 所屬分類: C++ Programming

            評(píng)論

            # re: SSE Assembler vs Optimized C++ 2007-01-05 13:59 zhshgao
            真的嗎?編譯器是不是只能進(jìn)行比較明顯(相對(duì)編譯器來說)的優(yōu)化啊?比如連續(xù)的相同運(yùn)算什么的。這些優(yōu)化應(yīng)該沒有專門針對(duì)SIMD匯編去修改算法效率高吧?
            ----------剛開始學(xué)習(xí)的新人

              回復(fù)  更多評(píng)論
              

            # re: SSE Assembler vs Optimized C++ 2007-01-05 19:59 空明流轉(zhuǎn)
            你實(shí)作一個(gè)Mat4x4的乘法就知道,VS2003對(duì)SSE的支持還是欠缺太多。會(huì)生成出非常垃圾的代碼。

            真正應(yīng)該使用的其實(shí)是VS所提供的instrinct。這樣編譯器可以在你的基礎(chǔ)上進(jìn)行優(yōu)化。  回復(fù)  更多評(píng)論
              

            # re: SSE Assembler vs Optimized C++ 2007-01-05 23:57 如展
            我當(dāng)然做過MAT乘法。問題的關(guān)鍵在于設(shè)計(jì)正確地處理數(shù)據(jù)生成流程。大多數(shù)人使用SSE匯編產(chǎn)生的代碼長(zhǎng)度會(huì)比編譯器自動(dòng)產(chǎn)生的長(zhǎng)的多。

            MAT,VEC之類最簡(jiǎn)單的運(yùn)算,因?yàn)樘嗳藘?yōu)化過,所以那些匯編的精簡(jiǎn)程度很高,但是除了這些基礎(chǔ)運(yùn)算有現(xiàn)成的算法,那些其他的算法恐怕就沒多少現(xiàn)成高效的SSE可以使用了。再說現(xiàn)在3D的MAT,VEC的計(jì)算,主流是推送到ShaderLanguage來完成的,基本不用自己編程計(jì)算。

            VS的instrinct才會(huì)產(chǎn)生真正的垃圾代碼,具體去看Intel的文章,那上面很詳細(xì)的講了如何優(yōu)化C++數(shù)據(jù)流程。  回復(fù)  更多評(píng)論
              

            # re: SSE Assembler vs Optimized C++ 2007-01-07 14:29 空明流轉(zhuǎn)
            那就期待你的下一篇文章了。

            你說的文章沒找到。也許是關(guān)鍵字的問題。可以發(fā)給我么。謝謝。

            我的QQ 14735407
            mail wuye9036 _at_ gmail dot com  回復(fù)  更多評(píng)論
              

            # re: SSE Assembler vs Optimized C++ 2007-01-26 23:54 學(xué)習(xí)
            如果C++代碼的速度快過匯編,那是因?yàn)閰R編的代碼不夠優(yōu)化;
            如果匯編的效率高于C++,那是因?yàn)閷懙氖切〕绦颉?nbsp; 回復(fù)  更多評(píng)論
              

            # re: SSE Assembler vs Optimized C++ 2010-04-16 16:15 mincomp
            不知道你有沒有測(cè)試過vc08的SSE速度?我使用SEE intrinsic的速度比不使用要快40%,所有優(yōu)化都打開,并且打開SSE編譯開關(guān)
            運(yùn)行10億次下面的代碼

            __m128 result = _mm_mul_ps(*m1, *m2);
            r = _mm_add_ps(r, result);

            float result[4];
            for (int j = 0; j < 4; j++)
            {
            result[j] = data1[j] * data2[j];
            fr[j] += result[j];
            }  回復(fù)  更多評(píng)論
              


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            91久久九九无码成人网站| 久久亚洲AV成人出白浆无码国产 | 亚洲精品蜜桃久久久久久| 波多野结衣久久一区二区| 久久久亚洲AV波多野结衣| 国产精品久久久久久久久软件| 浪潮AV色综合久久天堂| 色综合久久88色综合天天| 精品国产日韩久久亚洲| 久久精品亚洲精品国产色婷| 99久久精品费精品国产| 久久九九久精品国产免费直播| 久久精品国产一区二区三区日韩| 久久强奷乱码老熟女| 精品国际久久久久999波多野| 人妻无码精品久久亚瑟影视| 久久精品国产亚洲av麻豆小说| 国产三级精品久久| 久久66热人妻偷产精品9| 久久亚洲高清综合| 久久综合中文字幕| 日韩精品久久久肉伦网站 | 久久久国产精品网站| 综合网日日天干夜夜久久| 精品久久久久国产免费| 久久国产精品77777| 波多野结衣久久一区二区| 久久精品国产清自在天天线| 久久精品国内一区二区三区| 亚洲综合伊人久久综合| 亚洲伊人久久综合影院| 欧美久久一区二区三区| 精品久久国产一区二区三区香蕉 | 久久伊人五月丁香狠狠色| 2021国产成人精品久久| 久久精品国产亚洲网站| 久久91精品国产91久久户| 人妻精品久久无码区| 亚洲精品乱码久久久久久| 一本色道久久88精品综合| 久久天天躁夜夜躁狠狠躁2022|