アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
導入コストがすごそう… (スコア:1)
でも信頼性やランニングコストの実績として有効なデータが取れそうですね
Re: (スコア:2, すばらしい洞察)
チップ製造元に直接依頼してるので、それ相応の価格にはなるかと思います。
しかし、HDD→SDDとなるとPCシステムとしてのボトルネックの一つが解消されるので、
またCPUパワーを上げなくても良くなりますね。
一昔前のCPUでもまったく問題ないような状況が今以上に加速されるように思えるんですけど、
当のIntelはナニ考えているんだろうなと。
#NAND部門とCPU部門って別なんだろうけどね・・・
本当にボトルネックは解消されるのか!? (スコア:4, 興味深い)
自分でも CrystalDiskMark 等でベンチ取ってみてる限りにおいては、
相当に高価なフラッシュメモリーでもない限りは、
フラッシュメモリが HDD に勝るのは
シーク速度がボトルネックとなる 4K read のみと言う結果になる。
はっきり行って、ストライピングとかしない限りにおいては
フラッシュメモリのシーケンシャルアクセスはたいして速くない。
同じくシーク速度がボトルネックとなりそうな 4K write に至っては
write cache による遅延書き込みが効くぶん HDD のが 2 桁以上も高速という結果もしばしばで、
フラッシュメモリ
uxi
Re:本当にボトルネックは解消されるのか!? (スコア:1)
SDDに遅延ライトキャッシュ搭載しちゃえば解決することだったりして。
要は今がどうかではなく、こうしたいという力が働けば
既存技術の組合せで実現できることは、割と簡単にできてしまうと思いますね。
問題は・・・まーけてぃんぐ とか せいじ とか、ちょっとよく分からないゾーンで
あって技術的な問題じゃない気がします。
#ええ・・・
#あくまで、そんな気がするだけですよ・・・
Re:本当にボトルネックは解消されるのか!? (スコア:1)
それほど短期間で解決できる問題とは思えない。
ある程度長い期間で、と考えると、
素性がよろしくないんじゃないかと思えてしまうフラッシュメモリよりは、
MRAM のが本命じゃないか?と思う。
# まぁ見た目 SSD と言うくくりにはけど
# 中身的には MO と HDD くらいの差はある事になる。
とりあえず、最近の 3.5in 7200rpm の HDD の場合、
シーケンシャルで 80MB/s くらいは普通に出る。
シーケンシャルなので書き込みキャッシュは無視できるとすれば、
つまり、シークなしで 4KB の書き込みに必要な時間は 1/(80*1024)≒1.2e-5[s]
シークタイムはおおよそ 12[ms] = 1.2e-2[s] くらいなので、
4KB ランダムアクセスではシーク速度が大半であり、
有効数字2桁ならデータ転送速度は誤差の範囲。
結局シーク速度で計算した4KBランダムアクセスの理論値は
1/1.2e-2*4e-3=0.33MB/s
くらい
結局、現状のランダムアクセス性能は
リードはフラッシュメモリがHDDの10倍程度高速だが
ライトはHDDがフラッシュメモリの10倍程度高速と考えられる。
キャッシュを積んでも、ランダムライトの性能差は埋まらないだろう。
シーケンシャルに関しては、言わずもがな。
シーケンシャルはストライピングでどうにかなるだろうけど。
当面、ランダムライトが糞みたいに遅くても足を引っ張らないという状況でしか
SSD によるパフォーマンス改善は望めない。
省電力、省スペースという点に魅力を見出せたとして、
もう3~5年くらいしないと容量単価的に苦しいものがあると思われ。
uxi
Re: (スコア:0)
> もう3~5年くらいしないと容量単価的に苦しいものがあると思われ。
容量単価とかランダムライトのパフォーマンス云々って、そういった全般的なSSDの話であって、この記事や引用先、及び、親コメントの内容と関係あります?
情報ソースから判断できることとしては、まずは一部のサーバ(何サーバだかよくわかりませんが)への省電力化が目的なのだし、さらに、リードが多く発生する類いのサーバに用いるのなら、複数側面のパフォーマンス改善が望めると思います。
っていうかそもそも、その程度の効果やパフォーマンスの試算もせず、Googleがそういう動きをするはずないんじゃ。。。