隨著計算速度的加快,「硬算」的演算法是不是會逐漸淘汰掉「討巧」的演算法?

時間 2021-06-02 10:44:24

1樓:francium bobo

放心, 人類對於計算能力的需求是沒有止境的, 目前我的領域使用十幾億個取樣點, 也只能『粗略』的估計等離子體內部的一些『大尺度』的過程,這都需要幾千核心算一兩天。 要想用『硬算』來模擬哪怕是一滴水那麼大的氣體都是不可能的, 必須用各種巧妙的方法來降低計算量。

計算流體裡面的直接法求解NS方程也是, 直接法早就有了,應該也算是一種『硬算』, 只不過現在還沒有計算機可以滿足他的效能需求而已。現在的計算流體很多都是用了各種簡化方程才能模擬一些飛機區域性物理過程。全機模擬還早呢, NASA給出的路線圖是到2023年可能實現全飛機的模擬。

計算機領域的飛速進步給我們一種假象就是我們現在的計算機技術好像無所不能了, 但是在面對哪怕是問題的時候, 現在的計算能力增長速度都是渣渣, 何況等離子體領域『硬算』的複雜度是。

如果談數值誤差問題更是這樣, 算得快不代表算得準, 每一步都會產生積累誤差, 迭代次數太多的話我自己都不會相信計算的結果。這個也是很棘手的問題, 不是單純通過提高計算速度救能夠解決的。

2樓:Leung Garging

硬體水平提高對及算時間有幫助,但優化演算法也是必要的。

模擬下徒步,硬體計算速度好比走路的速度,而演算法就好比走的路線,好的路線可以縮短路程,配合高的計算速度可以更好地完成計算任務。

3樓:

好多優化問題就算硬算比現在塊 1.E10 倍也沒有用

因為它的解空間也許是 1.E1000

對於只有有限生命的我們來說同樣還是一樣遙不可及

4樓:趙磊

有的討巧的演算法可以帶來指數級的時間優化,但是硬體上的優化往往即便是常數級優化也有很大成本提公升 ,所以演算法的發展是必須的。

有時候囿於硬體效率的底下,我們更難使用一些黑科技。比如記憶體很小的時候可能就很難在語言中支援閉包,硬體條件提公升之後這些被發明已久的討巧的技術(這個例子是程式結構上的,和題主說的效能上的不太切題)才有可能真正投入使用。

5樓:

因為它是衡量的一般性標準。

你願意消耗兩倍的效能在這上面。

還是消耗三倍的效能在安全上,等等。例如通訊,記憶體。

這就是我們為什麼需要高效的演算法。

by--麻省理工學院公開課:演算法導論。

現代CPU的浮點計算速度為什麼這麼快?

Bluebear Inst 327 X86 IMUL r16,r16L 1.17ns 2.3c T 0.39ns 0.78c Inst 328 X86 IMUL r32,r32L 1.09ns 2.2c T 0.39ns 0.78c Inst 329 AMD64 IMUL r64,r64L 1.17...

人腦的計算速度可以被量化嗎?如果能,大概是多少 GHz?

人腦與CPU構造和工作原理上相差甚遠,不具有可比性。再者,主頻不是衡量CPU效能的唯一指標,畢竟CPU效能還由快取 記憶體位寬 架構 微架構 I O的效能 記憶體的架構 快取記憶體一致性 cache coherence 決定。如果真要衡量的話單位應該是flops,即每秒執行的浮點運算 小數運算 次數...

如何測試工作站來確定限制CFD計算速度的短板?

李龍翔 各位大佬不必硬答。像CFD這種模板計算程式,90 都是記憶體頻寬瓶頸。問題中標明是工作站,那麼可以認為只考慮單節點伺服器,不存在節點間通訊過程。對於單節點,一般只有三個地方存在瓶頸 CPU 記憶體頻寬 IO頻寬。對於CFD模擬,IO過程可以根據使用情況進行調節,並且除非進行IO測試,其他測試...