ramdisk真的有比較快?

  • 主題發起人 主題發起人 hu10us22
  • 開始日期 開始日期
hu10us22 說：
windows 內建的快取機制
明明就是個好東西
不綁手綁腳.本身就是動態管理
系統需要大量記憶體時 就縮小快取量
系統只有佔用少量記憶體時 就把硬碟常用的檔案 先快取到記憶體裡
就算是 動態ramdisk 也只能做到 , 動態調整自己本身的大小罷了
按一下展開……

所以動態Ramdsk只管理自己要.一定要的檔案而已...
這不是很好嗎^^
(或許只是暫存Garbage而已...)

在足夠Ram空間條件下...
不干擾.也不影響Windows OS的大方向運作^^
 
jamesfuh 說：
所以動態Ramdsk只管理自己要.一定要的檔案而已...
這不是很好嗎^^
(或許只是暫存Garbage而已...)

在足夠Ram空間條件下...
不干擾.也不影響Windows OS的大方向運作^^
按一下展開……

你覺得好就好囉
我只是認為 別用 ramdisk 多出來的記憶體
都讓 windows 決定是否要快取
更實在罷了
 
jamesfuh 說：
好吧^^
那來到Win7時代.SSD盛行...
微軟卻自動關掉主動式Superfetch. Prefetch...
原因是否正是這些快取幫不上忙呢? ^^
按一下展開……

我認為是 SSD 太快囉
Superfetch. Prefetch 會在系統碟生成類似標籤的索引檔
下次如果要執行這檔案就會先去找有沒有標籤阿
傳統硬碟會因為這技術 而提高性能
但 SSD 實在太快了 並不太需要用到 這種 主動式快取
或者該說 SSD 用了 提高的性能實在太少囉 (幾乎感覺不出來)
 
hu10us22 說：
你覺得好就好囉
我只是認為 別用 ramdisk 多出來的記憶體
都讓 windows 決定是否要快取
更實在罷了
按一下展開……

這是當然的...
每個使用者有他自己的選擇方式...
您我都不例外...

站在OS主控發展上去看...
儲存媒體IOPS的快速發展.UEFI的開啟....
或許日後真的再也沒必要使用Ramdsk...
像WinPE, Windows to Go這些未來產品...
作業系統OS幾乎是唯讀狀態...
所有能寫入都只是個人的東西而已^^

更遙遠的可預見未來...
一塊晶片.可包含了所有軟硬體.會更強!!
 
在往下看之前，請你先想想：
檔案快取是拿來做什麼的？
什麼樣的檔案我會想讓其快取？
你想要的快取究竟是Cache還是Buffer？

Ramdisk是使用者可以控制的快取，
Windows內建快取是無法控制的。
何況Windows對檔案IO的快取很小，容易感覺到的只有少量的寫入快取而已。
這不是不好的設計，而是以OS層來說，沒辦法去得知最適合每個軟體對檔案的快取策略，導致命中率低下，開大了也沒有意義；當然，OS本身可以對自己的服務做預載入，這又是另一回事了。
何況快取策略是雙面刃，一來要額外的開銷計算快取Hit/Miss的分支；二來要額外處理快取的套用/淘汰機制；三來如果這筆資料根本不需要快取，那多一層IO反而慢了；四來會占用額外的記憶體。
所以Windows不把檔案層快取開大，也不讓使用者做進一步的控制。

由於我們不能控制Windows的檔案快取機制，故：

I. 最好的方法是軟體內使用自己的快取，
(通常而言)軟體本身會使用對於自己最好的快取策略，以達到高的命中率，讓額外使用的記憶體適得其所。
但缺點是每套軟體都有自己的快取空間，占用記憶體就是大家的總和，以一個良心軟體來說，勢必不能用太大。
以CPU的觀點來說，這層就像是L1：各個core使用自己的，不能共用、不能干涉。

II. 其次則是進階使用者針對軟體，去設定Ramdisk、Fancycache，達到控制檔案快取策略的目的。
用途就是我一開始問的，快取會用在哪裡？
1. 使用者預期會重複使用的檔案IO。 ex: P2P
2. 使用者認為，工作階段中可能會重複使用，但工作階段完成後用完就丟的檔案。ex: temp
3. 程序間不支援管道IO且無法修改，使用檔案做資料交換機制。 (少見，但偶爾會用到)
4. 程序無法預估產生資料會有多大、或是32bit程序對記憶體較吃緊，故不保留在記憶體中而是存放在硬碟中。 但使用者可以預估其大小而決定是否將其放在高速緩存中。 ex: h264 2pass encode mbtree
以CPU的觀點來說，這層就像是L3：所有core共用一塊較大的，但既可以不互相影響，必要時亦可以互相干涉。

你會覺得Ramdisk/Fancycache沒用，不是工具差，而是你沒用在對的地方。
 
最後編輯：
litfal 說：
在往下看之前，請你先想想：
檔案快取是拿來做什麼的？
什麼樣的檔案我會想讓其快取？
你想要的快取究竟是Cache還是Buffer？

Ramdisk是使用者可以控制的快取，
Windows內建快取是無法控制的。
何況Windows對檔案IO的快取很小，容易感覺到的只有少量的寫入快取而已。
這不是不好的設計，而是以OS層來說，沒辦法去得知最適合每個軟體對檔案的快取策略，導致命中率低下，開大了也沒有意義；當然，OS本身可以對自己的服務做預載入，這又是另一回事了。
何況快取策略是雙面刃，一來要額外的開銷計算快取Hit/Miss的分支；二來要額外處理快取的套用/淘汰機制；三來如果這筆資料根本不需要快取，那多一層IO反而慢了；四來會占用額外的記憶體。
所以Windows不把檔案層快取開大，也不讓使用者做進一步的控制。

由於我們不能控制Windows的檔案快取機制，故：

I. 最好的方法是軟體內使用自己的快取，
(通常而言)軟體本身會使用對於自己最好的快取策略，以達到高的命中率，讓額外使用的記憶體適得其所。
但缺點是每套軟體都有自己的快取空間，占用記憶體就是大家的總和，以一個良心軟體來說，勢必不能用太大。
以CPU的觀點來說，這層就像是L1：各個core使用自己的，不能共用、不能干涉。

II. 其次則是進階使用者針對軟體，去設定Ramdisk、Fancycache，達到控制檔案快取策略的目的。
用途就是我一開始問的，快取會用在哪裡？
1. 使用者預期會重複使用的檔案IO。 ex: P2P
2. 使用者認為，工作階段中可能會重複使用，但工作階段完成後用完就丟的檔案。ex: temp
3. 程序間不支援管道IO且無法修改，使用檔案做資料交換機制。 (少見，但偶爾會用到)
4. 程序無法預估產生資料會有多大、或是32bit程序對記憶體較吃緊，故不保留在記憶體中而是存放在硬碟中。 但使用者可以預估其大小而決定是否將其放在高速緩存中。 ex: h264 2pass encode mbtree
以CPU的觀點來說，這層就像是L3：所有core共用一塊較大的，但既可以不互相影響，必要時亦可以互相干涉。

你會覺得Ramdisk/Fancycache沒用，不是工具差，而是你沒用在對的地方。
按一下展開……

你的說法讓我聯想到這篇文章裡的
這位網友的看法
变心金刚2
第9頁~第12頁
http://bbs.pceva.com.cn/thread-35083-9-2.html

快取本來就不能控制
你會想去控制 CPU 的 快取 嗎?:PPP:
 
hu10us22 說：
你的說法讓我聯想到這篇文章裡的
這位網友的看法
变心金刚2
第9頁~第12頁
http://bbs.pceva.com.cn/thread-35083-9-2.html

快取本來就不能控制
你會想去控制 CPU 的 快取 嗎?:PPP:
按一下展開……

你頗奇怪的，我說的跟那位網友的八竿子打不上關係。
不要引用別人的話了，說說你自己的看法吧。
引經據典、再把焦點模糊沒有意義，只是顯得你不懂別人在說什麼而已。

我不知道你的目的是什麼，但你這棟樓只是用各種方式一昧否定Ramdisk，完全沒有要討論的意思。

另外，快取不應該被控制只是你的偏見而已。
 
你必須登入或註冊才能在此回覆。
上方 下方