|
||
|
Power Member
 加入日期: May 2000 您的住址: Taiwan
文章: 697
|
引用:
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 |
||||||||
2009-02-08, 02:30 AM
#41
|
|
|
Power Member
加入日期: May 2000 您的住址: Taiwan
文章: 697
|
引用:
大推... 樓主的論點十分正確, 可以讓別人澄清許多觀念 現階段雙精度是以64bits儲存, 但實際進入硬體運算時是以80bits做計算 按照IEEE754的規格來說, 只能記錄大約有效位數15位的精度 下一世代會有128bits的浮點的硬體出現, 有效位數就可以提升到33位, 應該數十年之內都可以滿足所有的需求了(除非是真正的需要100%精確數值的大數 XD XD) 總之, 大推樓主的言論, 十分正確 |
|||
|
2009-02-08, 02:47 AM
#42
|
|
|
Power Member
加入日期: May 2000 您的住址: Taiwan
文章: 697
|
引用:
我是第一次看到SuperPI的source code (抱歉了, 才粗學淺) P4的浮點運算能力不弱, 但他的x87非常的弱, 這兩個是不同的事情 如果說程式又大量使用浮點運算, 程式在編譯時, 沒有針對SSE2運算做調整, 我不認為單靠ADD指令優勢, 以及高記憶體頻寬的P4架構會有甚麼優勢 我倒是傾向於他在編譯程式時, 使用了SSE2加速, 但SSE2指令並不是requirement (如有興趣, 請參閱Intel compiler的設定) 所以程式仍然是可以在一般的CPU上頭跑, 而P4跑起來也不至於都得用那跛跛的x87 以上只是我的猜測, 如果有說錯, 也歡迎指教討論 |
|
|
2009-02-08, 03:03 AM
#43
|
|
|
*停權中*
加入日期: Aug 2008
文章: 615
|
記得十幾年前,開始用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大大可以看這篇. 此文章於 2009-02-08 03:20 AM 被 Ruark8263 編輯. |
|
2009-02-08, 03:18 AM
#44
|
|
|
Master Member
加入日期: Mar 2004 您的住址: 亞洲.台灣.台北
文章: 2,054
|
有沒有 聽過 整數 可以 模擬 浮點數 運算?
那是發生在 硬體 沒 浮點運算器 , 可是 程式是寫浮點數運算 那 CPU 產生中斷 , 用 整數模擬浮點數運算 or GCC 在 編譯時, 直接 連結 整數模擬浮點數運算 的 函式庫 不過 重點是 要看程式是怎樣寫的 像 影像計算相關的公式 如果可以 轉成 整數運算的形式 當然 換成 整數運算 因為 整數運算 比較快 (一樣的公式 不同的形式) (或者 整數運算 會有小誤差 , 但是沒影響很大) 所以 video轉檔 會是 整數運算 <---- 1.上述描述有錯嗎? 我一直以為影片轉檔與多媒體處理是浮點數運算呢... 2.DataBase的更新、查詢等操作算是整數運算or浮點運算? 整數運算 3.遊戲的3D渲染應該都是浮點數運算吧? 看遊戲 怎寫的 , 如果是 以前的 Doom , Quake 是 整數 (整數運算 會有小誤差 , 但是沒影響很大) 4.常見的浮點數運算的工作項目還有哪些呢? 工程計算 |
|
2009-02-08, 04:08 AM
#45
|
|
|
Elite Member
  
加入日期: Mar 2001 您的住址: Rivia
文章: 7,051
|
引用:
你知道Super PI跑1M需要算到小數點後面幾位嗎？ 就算是long double的資料型態，也只能精確到小數點後19位 而且用整數做圓週率運算也不是不可能 例如3.1416可以乘10000變成31416的整數 跑32m如果不用整數運算，由於精度的問題 會使得運算時間出現極限，某些性能明明應該比較高的硬體 卻跑出比自己性能還要差的硬體同樣的成績
__________________
Folding@home with GPGPU集中討論串 Unix Review: ArchLinux●Sabayon●OpenSolaris 2008.5●Ubuntu 8.10 AVs Review: GDTC●AntiVir SS●ESS●KIS 09●NIS 09●Norton 360 V3  I Always Get What I Want. |
|
|
2009-02-10, 01:12 PM
#46
|
|
|
Regular Member
 加入日期: Nov 2003
文章: 64
|
沒FPU的ALU也是可以處理小數點之後的運算的，前提是犧牲一點精確度，某些時候還得看
程式語言本身之不支援，至少組合語言可以用Q-function來玩。C跟JAVA大概得自己來了， 但應該不是啥大問題，頂多手指頭累一點多打一下。 以這帖很夯的1.2+1.3為例，一BYTE取2位整數的UINT： 01001101 + 01010011 = 10100000 剛剛好2.5，沒失真就當運氣好賽到吧。 視訊方面考量到精確度的需求，使用上述的方法沒有任何問題，新的壓縮方法還自動 幫你DOWN精確度來算(某些BLOCK內)，看看那個H264... |
|
2009-02-10, 05:50 PM
#47
|
|
|
Advance Member
加入日期: Apr 2005
文章: 479
|
早在看到這篇文章的時候就想回了
但懶得打字 而且 恩 其實後面講的人大概都講到重點了 像applecore與Weichung提到的算得上是正解 所以 我只講個算是本篇討論的重點 但實際上也不只是表面的那樣的解釋的解釋 因為我想 應該還有很多人看完整篇， 還搞不太清楚整數運算與浮點運算最主要的差異在哪？ 若要我濃縮成兩個字，嗯。 就是 "精度" 整數運算 浮點運算 就是因此而存在的 
__________________
提高計算速度的方法不只一種。 平行計算只是一種提高效率的方式，具有不確定性與複雜性。關於提高效率的方式，存在著各種不同的理論。 對於我們來說，那並不是完美的東西。 |
|
2009-02-10, 08:18 PM
#48
|
|
|
*停權中*
加入日期: Sep 2006
文章: 597
|
那這樣以使用catia、 pro/e、UG、solidworks的3D工作要用AMD還是Intel
 |
|
2009-02-10, 08:57 PM
#49
|
|
|
Golden Member
加入日期: Feb 2004 您的住址: 從來處來
文章: 2,765
|
引用:
SuperPI 是使用 Gauss–Legendre algorithm http://en.wikipedia.org/wiki/Super_PI Gauss–Legendre algorithm http://en.wikipedia.org/wiki/Gauss-Legendre_algorithm 實數並不等於浮點數，簡單地說，浮點數像一個框，可以框住任一段實數，這個框愈大，精確度愈高。 大數的運算需要用整數來算，因為浮點數只能提供有限的精確度。 其實這也是個考驗程式功力的方法，會寫程式的，不妨回去想想，怎麼寫一個可以做「任意位數」運算的計算機，只怕記憶體、硬碟空間不夠；只怕人會按到手抽筋，不怕位數太多算不出來的計算機。 最簡單的由加減乘除開始，接下來就可以做更深入的挑戰。 |
|
|
2009-02-10, 09:32 PM
#50
|
|
