|
||
|
Senior Member
 
加入日期: Oct 2006
文章: 1,384
|
關於整數與浮點運算
日前在大陸網站IT168看到一篇文章
以下是對於SPEC CPU 2006的描述 整數運算主要包含編譯、壓縮、人工智慧、視頻壓縮轉換、XML處理等，此外，各種日常操作也主要是基於整數操作。SPEC CPU 2006的整數運算包含了400.perlbench PERL程式設計語言、401.bzip2 壓縮、403.gcc C編譯器、429.mcf 組合優化、445.gobmk 人工智慧：圍棋、456.hmmer 基因序列搜索、458.sjeng 人工智慧：國際象棋、462.libquantum 物理：量子計算、464.h264ref 視訊壓縮、471.omnetpp 離散事件模擬、473.astar 尋路演算法、483.xalancbmk XML處理共12項。 浮點運算包括的全部都是科學運算，科學運算需要用到大量的高精度浮點數據，如410.bwaves 流體力學、416.gamess 量子化學、433.milc 量子力學、434.zeusmp 物理：計算流體力學、435.gromacs 生物化學/分子力學、436.cactusADM 物理：廣義相對論、437.leslie3d 流體力學、444.namd 生物/分子、447.dealII 有限元分析、450.soplex 線形程式設計、優化、453.povray 影像光線追蹤、454.calculix 結構力學、459.GemsFDTD 計算電磁學、465.tonto 量子化學、470.lbm 流體力學、481.wrf 天氣預報、482.sphinx3 語音辨識共17項測試。 ---- 個人有幾個小問題想問一下 1.上述描述有錯嗎? 我一直以為影片轉檔與多媒體處理是浮點數運算呢... 2.DataBase的更新、查詢等操作算是整數運算or浮點運算? 3.遊戲的3D渲染應該都是浮點數運算吧? 4.常見的浮點數運算的工作項目還有哪些呢? 謝謝 |
|||||||
2009-02-05, 06:21 PM
#1
|
|
|
Master Member
  
加入日期: Nov 2000 您的住址: 新開的店
文章: 1,586
|
轉影片都是整數沒錯啊
因為 RGB 都是整數 字元處理也都是基於 Byte 壓縮法只是多 Byte 合拼再存成 Byte，也還是整數 一般用途，像我們平常做做文書 是用不到浮點運算的 遊戲的話應該也不需要浮點運算 3D 處理 (除非是 3D 繪圖軟體) 也不需要太精準 因為顯示的畫面像素不會有 0.1 只要約略就好了 因為浮點運算一定比整數運算慢 所以程式設計師都會避開浮點運算 只要用點程式的小技巧就能很快速的處理有小數點的計算了 浮點運算除非特殊用途 不然，真的很少用到 以上有點亂的解釋不知道你能不能了解? 簡單講 基本上基於 Byte (位元組) 的運算 都是整數運算 此文章於 2009-02-05 06:48 PM 被 EIGHTS 編輯. |
||
|
2009-02-05, 06:40 PM
#2
|
|
|
*停權中*
加入日期: Jan 2008
文章: 1,281
|
不好意思插個嘴請問一下 EIGHTS 大
那個 Super PI 用的「演算法」是否也是整數運算？ 另，我個人是懷疑 Super PI 的主要演算迴圈應該是用組合語言寫的，不知大大覺得呢？ |
|
2009-02-05, 07:04 PM
#3
|
|
|
Master Member
加入日期: Nov 2000 您的住址: 新開的店
文章: 1,586
|
引用:
對 Super PI 沒有研究 大概找了一下資料 以圓周率的計算方法來看 不太可能不用到浮數點 http://www.mathland.idv.tw/life/picpu.htm http://forum.coolaler.com/archive/i...p/t-145828.html 個人是認為通常會用程式方法去快速計算小數點 位數都不會太多 不然，反而本末倒置 其他的得去研究原始程式碼 才能給你答案了 現在應該沒有人用組合語言寫程式 C++ 就夠快了，也比較方便維護 |
|
|
2009-02-05, 07:28 PM
#4
|
|
|
Major Member
加入日期: Feb 2003
文章: 198
|
引用:
蠻懷疑的。 DCT transform, half pixel motion estimation 都應該是浮點。 除非 DCT 改用 DWT， half pixel motion estimation 用 linear interpolation。 |
|
|
2009-02-05, 07:33 PM
#5
|
|
|
Senior Member
加入日期: Oct 2006
文章: 1,384
|
pi有多種算法
程式也有多種寫法 不過日本那個super pi 應該沒支援SSE 而Pentium 4只有在super pi可以幹掉同期的K8 K8在x87浮點運算拜3組複雜解碼器之賜比Pentium 4強多了 所以反推super pi 程式應該是整數運算  |
|
2009-02-05, 07:38 PM
#6
|
|
|
Senior Member
加入日期: Oct 2006
文章: 1,384
|
引用:
我對轉檔不熟 但看一些軟體的設定會讓我覺得可能是浮點 不過大多的軟體都有SSE指令集最佳化 Pentium 4之所以在轉檔可以勝過同期的k8 我想是因為SSE2最佳化的關係...正好符合Intel NetBurst的企圖 當初Pentium 4在MPEG4與K7的較量也曾引起大爭議 http://www.tomshardware.tw/306,review-306-2.html |
|
|
2009-02-05, 07:49 PM
#7
|
|
|
Master Member
加入日期: Nov 2000 您的住址: 新開的店
文章: 1,586
|
引用:
個人以為螢幕的色彩表示用浮點數沒有意義 再怎麼弄也是 256 階 演算法可能很複雜，會產生許多的小數值 但實際寫成程式樣子會不一樣 不一定要照演算理論去寫 尤其像影片、照片這類資料 我並不需要絕對的數值 只要近似就好了 所以 Super PI 之類的是不是用整數去計算 除非看他的程式碼 不然，我是覺得很難猜吧 因為也有可能是寫了笨程式，或用了特殊運算去寫 以上是個人的看法，有錯請再指教  |
|
|
2009-02-05, 07:54 PM
#8
|
|
|
Master Member
加入日期: Nov 2000 您的住址: 新開的店
文章: 1,586
|
剛剛吃飯時，還不停的在思考這些問題
想到很多可能性 不過，由於自身程度還不到能完全理解 就請各位再討論了 |
|
2009-02-05, 08:42 PM
#9
|
|
|
Major Member
加入日期: Feb 2003
文章: 198
|
引用:
RGB 轉YUV要不要浮點。 怎麼可能浮點數沒有意義。(起碼就理論上) 既然您對 video encoding 這麼不熟，我想您保留一下你的看法會比較好。 有可能有特殊程式寫法可以減少浮點或怎樣，但是還是要實際最佳化過的人比較清楚。 例如大家全部乘1000後當整數來算等等。 記得 tmpegenc 2.0 在 motion estimation 有選項可以選用整數或浮點。 所以就看要用什麼軟體什麼樣的選項來跑。 也不一定是絕對，只是我想完全不用浮點應該不太容易。 PI用整數的原因是，64bit double 根本裝不下，數字太大了。 所以用整數自己處理大數運算比較快。 就我所知大數運算都是用整數。當然，也很可能是我見識不夠廣。 此文章於 2009-02-05 09:30 PM 被 xaren 編輯. |
|
|
2009-02-05, 09:25 PM
#10
|
|
