SSE 包含了整數運算、浮點運算以及load/store, cache管理的指令(pre-fetch)
而發展到SSE2, 有個指標意義是當初Intel有打算讓SSE2取代堆疊架構的老舊x87
但後來P4(P7)夭折, 所以這件事也不了了之了

至於1.2 + 1.3 , 如果把它當成A.B + C.D, 而假設B+D會小於10
他可以簡單的用兩筆整數運算就取代了, 但這種情況太特殊了, 不會是一般通運的case
所以針對通用性的程式或演算法, 這種通常都會直接用浮點來處理

至於大家在討論的, 怎樣算是浮點運算, 怎樣算是整數運算
只要某個指令使用了FPU的運算資源, 基本上, 他就可以歸類為浮點運算了
而跟是不是用SSE/SSE2指令, 沒有甚麼關係, SSE指令強調的是Stream... 也就是SIMD

大推...
樓主的論點十分正確, 可以讓別人澄清許多觀念
現階段雙精度是以64bits儲存, 但實際進入硬體運算時是以80bits做計算
按照IEEE754的規格來說, 只能記錄大約有效位數15位的精度

下一世代會有128bits的浮點的硬體出現, 有效位數就可以提升到33位, 應該數十年之內都可以滿足所有的需求了(除非是真正的需要100%精確數值的大數 XD XD)

總之, 大推樓主的言論, 十分正確

我是第一次看到SuperPI的source code (抱歉了, 才粗學淺)

P4的浮點運算能力不弱, 但他的x87非常的弱, 這兩個是不同的事情

如果說程式又大量使用浮點運算, 程式在編譯時, 沒有針對SSE2運算做調整, 我不認為單靠ADD指令優勢, 以及高記憶體頻寬的P4架構會有甚麼優勢

我倒是傾向於他在編譯程式時, 使用了SSE2加速, 但SSE2指令並不是requirement
(如有興趣, 請參閱Intel compiler的設定)
所以程式仍然是可以在一般的CPU上頭跑, 而P4跑起來也不至於都得用那跛跛的x87

以上只是我的猜測, 如果有說錯, 也歡迎指教討論

記得十幾年前,開始用MP3格式聽音樂的時代,不管是播放或者wav轉MP3,都要使用CPU的浮點運算.那時候,不管是Cyrix,AMD,它們的浮點運算能力都大輸Intel,後來的K6也一樣.
早期的386或者低階的486(不含FPU),無法轉MP3.Pentium 133轉一首4分鐘半以內的Mp3,大約要轉18分鐘多一點,它牌的要花上30分鐘.播放時,它的CPU佔用率最低約50-60%,它牌的要90%以上.同時脈比較.

Super PI 的測試,當然是測浮點運算,毫無疑問的.除非圓周率是整數.您能說3.1415926
這個近似值是[整數]嗎?求質數算的數值雖是整數,但它也可以用浮點運算的功能.
轉檔軟體也是要用到浮點運算的.3D遊戲也是會用到.顯示卡的SP,它的強項是平行計算,
浮點運算高達數百GFlops,GTX 280 接近 1TFlops,4870高達1.2T.不過那應該是理論數據.而且是單精度浮點運算.倍精度可能只剩十分之一左右.CPU的浮點運算,以3GHz的四核心來推估,大約36G.i7架構的四核,應該比LGA 775的四核高大約30%.淺見,大家一起討論吧!
以前寫過用整數運算求質數的程式,但效能比起浮點運算的慢.硬體的I/O,用整數計算即可.

http://www.mobile01.com/topicdetail...8大大可以看這篇.

有沒有 聽過 整數 可以 模擬 浮點數 運算?

那是發生在 硬體 沒 浮點運算器 , 可是 程式是寫浮點數運算
那 CPU 產生中斷 , 用 整數模擬浮點數運算
or
GCC 在 編譯時, 直接 連結 整數模擬浮點數運算 的 函式庫




不過 重點是 要看程式是怎樣寫的

像 影像計算相關的公式 如果可以 轉成 整數運算的形式
當然 換成 整數運算
因為 整數運算 比較快 (一樣的公式 不同的形式)

(或者 整數運算 會有小誤差 , 但是沒影響很大)

所以 video轉檔 會是 整數運算
<---- 1.上述描述有錯嗎? 我一直以為影片轉檔與多媒體處理是浮點數運算呢...
2.DataBase的更新、查詢等操作算是整數運算or浮點運算?
整數運算

3.遊戲的3D渲染應該都是浮點數運算吧?
看遊戲 怎寫的 , 如果是 以前的 Doom , Quake 是 整數
(整數運算 會有小誤差 , 但是沒影響很大)

4.常見的浮點數運算的工作項目還有哪些呢?
工程計算

你知道Super PI跑1M需要算到小數點後面幾位嗎？
就算是long double的資料型態，也只能精確到小數點後19位
而且用整數做圓週率運算也不是不可能
例如3.1416可以乘10000變成31416的整數
跑32m如果不用整數運算，由於精度的問題
會使得運算時間出現極限，某些性能明明應該比較高的硬體
卻跑出比自己性能還要差的硬體同樣的成績

沒FPU的ALU也是可以處理小數點之後的運算的，前提是犧牲一點精確度，某些時候還得看
程式語言本身之不支援，至少組合語言可以用Q-function來玩。C跟JAVA大概得自己來了，
但應該不是啥大問題，頂多手指頭累一點多打一下。

以這帖很夯的1.2+1.3為例，一BYTE取2位整數的UINT：

01001101 + 01010011 = 10100000 剛剛好2.5，沒失真就當運氣好賽到吧。

視訊方面考量到精確度的需求，使用上述的方法沒有任何問題，新的壓縮方法還自動
幫你DOWN精確度來算(某些BLOCK內)，看看那個H264...

早在看到這篇文章的時候就想回了
但懶得打字

而且 恩
其實後面講的人大概都講到重點了
像applecore與Weichung提到的算得上是正解


所以
我只講個算是本篇討論的重點
但實際上也不只是表面的那樣的解釋的解釋


因為我想
應該還有很多人看完整篇，
還搞不太清楚整數運算與浮點運算最主要的差異在哪？


若要我濃縮成兩個字，嗯。 就是











"精度"

整數運算 浮點運算 就是因此而存在的 :ase

那這樣以使用catia、 pro/e、UG、solidworks的3D工作要用AMD還是Intel :shock:

SuperPI 是使用 Gauss–Legendre algorithm
http://en.wikipedia.org/wiki/Super_PI

Gauss–Legendre algorithm
http://en.wikipedia.org/wiki/Gauss-Legendre_algorithm

實數並不等於浮點數，簡單地說，浮點數像一個框，可以框住任一段實數，這個框愈大，精確度愈高。

大數的運算需要用整數來算，因為浮點數只能提供有限的精確度。

其實這也是個考驗程式功力的方法，會寫程式的，不妨回去想想，怎麼寫一個可以做「任意位數」運算的計算機，只怕記憶體、硬碟空間不夠；只怕人會按到手抽筋，不怕位數太多算不出來的計算機。

最簡單的由加減乘除開始，接下來就可以做更深入的挑戰。