SSDはソフトウェア開発目的でも有用？ 76
ストーリー by hylom
欲しいけど容量に不満、 部門より
欲しいけど容量に不満、 部門より
あるAnonymous Coward 曰く、
本家/.で、Can SSDs Be Used For Software Development?（SSDはソフトウェア開発向けに使えるか？）という記事が上がっていました。最近ではSSDの価格も大幅に安くなり導入がしやすくなっています。ソフトウェア開発作業（というかコンパイル作業）では多数の小さいファイルにアクセスすることが多いため、ランダムアクセスが速いSSDはコンパイル時間の短縮にも効果的なような気がします。一方で頻繁な書き換えも多いため、その寿命が気になるというのも事実。
ということで、実際にSSDをストレージに使っている方にSSDの使い勝手の是非をお聞きしたいところです。
本家に書いてある別解 (スコア:4, 参考になる)
* Linuxのtmpfs（メモリ上のファイルシステム）を使え。
# コンパイルをしている間にアレたまを見に来てしまった。
# NFS上のホームディレクトリでコンパイルすると遅い遅い。
love && peace && free_software
t-nissie
Re:本家に書いてある別解 (スコア:3, すばらしい洞察)
なるほど…。SSDが普及すると、ビルド中に/.J覗くなんて贅沢もやりにくくなるかもしれませんね。:-(
.
# …なーんて、うそぽん。（・∀・）
Re:本家に書いてある別解 (スコア:4, おもしろおかしい)
＞# …なーんて、うそぽん。（・∀・）
cpuのクロックが、なんちゃらHzになったら …… とか、
ストレージの容量が、なんちゃらTbになったら …… とか、
メモリ容量が、なんちゃらGbになったら ……
ビルドも何も、あっと言う間に終わって、
我々には息つくヒマも無くなるであろう、
と、前世紀から言われ続けていたハズです。
ですが、我々は未だ、スラドを閲覧するゆとりを維持しています。
SSD如きで、状況が悪化するハズは無いですね。
// なんだかんだ言って、SSDへの頻繁なアクセスはやっぱり怖いのでid
Re:本家に書いてある別解(オフトピ） (スコア:2)
＞フルスピードで思考し続けられるのは週40時間くらいが限界です。
うぉ～、ずいぶん高い限界ですね・・・
#自分はせいぜい７～１０時間くらいです
#息抜きの合間に人生を(ry
人事を半分尽くして天命を待つ
Re:本家に書いてある別解 (スコア:1, 興味深い)
ソース、コンパイラなど一式RAMディスクにおいてTurbo C走らせたらむちゃくちゃ早くて感動したな。
#比較対象はフロッピーディスクだけど
Re:本家に書いてある別解 (スコア:1, おもしろおかしい)
よくわかるよ。
そして、どの後デバッグ中にOSをクラッシュさせた後の起動の遅さにがっかりしてたな。
Re:本家に書いてある別解 (スコア:1, おもしろおかしい)
ウォームブートといっても・・・ (スコア:1)
Re:ウォームブートといっても・・・ (スコア:2)
そしてコンパイル中のファイル一式を納めてなお余裕があるサイズのDisk chacheを使うようになったあの日々。
ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
Re:本家に書いてある別解 (スコア:1)
スタニスワフ・レムって人が『ソラリスの陽のもとに』
っていう本に書いてました。
love && peace && free_software
t-nissie
Re:本家に書いてある別解 (スコア:1)
レムってすげー。
おすすめは i-RAM (スコア:3, 参考になる)
私は、SSDでは無く、i-RAMを選択しました。
ソースコードはsubversionで管理しているので、
i-RAMはあくまでも作業コピーを置く一時ディレクトリです。
１年以上使っていますが、データが消えるなどのトラブルも無く、かなり快適です。
Re:おすすめは i-RAM (スコア:1)
私も一時期Mozillaのビルド用の作業領域にi-RAMを使っていました(Windows)。かなり希に(数ヶ月に一度程度?)一部のファイルが壊れることはありましたが、それなりに使えました。ただ、容量が4GBと少なすぎるのが問題でした。Firefoxでデバッグビルドを作ると、ソース+バイナリで2GB程度必要なので、せいぜい二つ用意するのが限界で。
現在はANS-9010(16GB)を代わりに利用 [d-toybox.com]していますが、メモリがよくないのか、ANS-9010自体の問題なのか分かりませんが、よく保存しているファイルやインデックスが壊れて困っています。
コストパフォーマンス的にはSamusungのSLCのSSDの方が優れているかもしれません(64GBで35,000円ぐらい [kakaku.com])。さすがにアクセス速度はRAM Diskよりは劣りますが、HDDに比べれば圧倒的に高速ですし、ビルドにそこまでの速度が必要かどうかは不明です。
案外平気かも (スコア:3, 参考になる)
SSDの信頼性は、すでにHDDを超えている [impress.co.jp]
～東芝セミコンダクター社 インタビュー
上記の記事によると、書き換え3000回でいきなりダメになるわけじゃなく実際はもっと持つし、徐々に使えないセルが増えていく形になるので容量が減っていくけど、致命的なことになるわけじゃないようで。
SSDの寿命はあまり気にしなくてもいいのかもしれませんね。
Re:案外平気かも (スコア:4, 興味深い)
プログラム開発とはちょっと別の話からで申し訳ありませんが、
たとえば某BTO大手のノートPCにVistaSP1+去年末くらいまでのWindowsUpdate+メーカー最新パッチ
という状態では、スリープに失敗すると電源強制断するまで
延々とHDDにフルスピードアクセスしっぱなしになる
(スリープ以外でも、chkdskとかで同様の状態になり、
レスポンスの劇的な低下＋最終的にHDDを止めるためには電源強制断が必要)という事象がありました。
その後のWindowsUpdateや、Intel Matrix Storage Managerの手動で更新(- これがクサイ)
などの結果、当方環境では上記の事象はどうやら解消したようですが、
「これがSSDで起きていたら・・・・・」と正直思いましたね。
書き込み速度が上昇するほど、上記
「プログラムのエラー(など)で異常アクセス状況となったときの劣化速度」も上昇するわけで、
品質が低い状態のプログラムを実行する環境でSSDってのも考え物かなぁと思いました。
#もちろん、職業プログラマの方からすれば時間への投資としてあっという間に元が取れるのは承知の上で
Re:案外平気かも (スコア:2, 興味深い)
頼んでもないディスクアクセスが多くて、通常運転でさえVistaにSSDはちょっと怖い気がします。
Windows 7はSSDに最適化した動作モードとかがあるといいんですが。
うちではフィールド用のノートに、システムドライブをSSD、データとスワップ用にCardbus経由で
CFカードを入れ、固定ディスク化して使ってます。
時々シャットダウン前にデータをSSDにコピーすれば簡易バックアップにもなるし、今のところこれが
現実的な使い方かな、と思ってます。
〜◍
Re:案外平気かも (スコア:1)
>SSDに最適化した動作モードとかがあるといい
っ Embeded Winodws XP
Re:案外平気かも (スコア:2, 参考になる)
組み込みっぽい用途ならEmbededもいいんだけどねー。
普通ののXPは殺せるだけサービス殺しても、何故かたまにディスクアクセスしに行くよね。
でもVistaよりぜんぜんマシ。XPならEWF [so-net.ne.jp]使えばさらに安心。
〜◍
Re:案外平気かも (スコア:1, すばらしい洞察)
それってディスクにフルスピードで書き続けるバグなんですか？
読むだけなら寿命関係ないですよ。
Re:案外平気かも (スコア:2)
本来の挙動で言えば、スリープする際には
何も「読み"続け"」ませんし、「書き"続け"」もしません。
それじゃいつまで経ってもスリープに落ちませんよね。
で、そこで「バグ」が入ると～"続ける"可能性が出てきます。
この実際に発生しうる不意の挙動について「本来なら"続ける"ことはないから～」
なんて言っても、
「"バグが無ければ問題は起こらないから"問題は起こらない」という主張くらい説得力が無いでしょう。
なので、読みなのか？書きなのか？を、今回の件についてだけ決定しようとしても
意味がありません。
今回は例としてVistaのスリープ時の問題を取り上げてみましたが、バグはそれこそ無限に存在します。
元書き込みで
(HDDの発熱具合から、HDTuneでのスキャンと同等クラスの発熱があるので
おそらく書き込み処理であろうとは思っていますが、意図的に)
「書き込み」ではなく「アクセス」と書いたのはそのためです。
示したかった重要な点は、
「バグのあるプログラムにより不意にSSDへ長時間アクセスが集中し続ける可能性がある」
ことであって、「偶然それが読みだったから助かった、書きだったから助からなかった」は二の次です。
Re:案外平気かも (スコア:1)
Vista のハイブリッドスリープはスリープ時に「万が一スリープ中に電源断されても大丈夫なように」ストレージに書き込み (サスペンド) もしておきますよ。スリープから復帰した場合はそのまま復帰するだけですが、ノート PC でのバッテリ切れや急な電源断 (掃除のおばちゃんがコンセントを抜いた等) の場合にはサスペンドからの復帰扱いになります。
このため、ハイブリッドスリープを有効にしている場合はスリープに遷移する際であってもがっつり書きこみます。
Re:案外平気かも (スコア:4, 参考になる)
ネット上には鬼のような書き込みの繰り返しで加速試験をしている人々がちらほらいますが、
それを見るに、壊れるときはほぼ一気に全破壊するようですよ。
HDDのような部分回収とかは期待薄。
SSD耐久テストhttp://www004.upp.so-net.ne.jp/botchy/ssd.htm [so-net.ne.jp]
Re:案外平気かも (スコア:4, 参考になる)
USBフラッシュを加速試験で壊したことあるけど、あの壊れ方はやばいっすよ。書き込んだ直後はちゃんと読めるんで、すぐには気がつかないんです。ところが一定時間経過後に読もうとすると壊れてる。かといってHDDのように異音がするわけでも、リトライで異常に遅くなるわけでもなく、ただ普通に壊れたデータを読み出せる。気がつかずに使い続ける場合も多いんじゃないかなぁ。
パリティやCRCを保存して破損を検出できるようにするとか、メモリブロックごとに書き込み回数をカウントするとかしないと、ちょっと危ないんじゃないかなぁ。
すでに実装済みです。 (スコア:5, 参考になる)
>パリティやCRCを保存して破損を検出できるようにするとか、メモリブロックごとに書き込み回数をカウントするとか
これがUSBメモリとSSDと呼ばれるメモリの差のようですよ。
例えば以下はMTRONのspecの一部となります。
>- Wear-leveling algorithm : Dynamic and static wear-leveling
>- ECC : 7-bit Error Correction Code(ECC)
>- Bad Block Management algorithm
ということでして、おっしゃる機能はすべて実装されています。お買い求めになったUSBメモリは
ECCやBBMはあってもWear-levelingなどは行わなかったのかもしれませんね。すくなくともWear-leveling
を動的に行うUSBメモリというものを私は知りません。
Re:マジメに作ってあるUSBメモリには実装済みです。 (スコア:2, 参考になる)
>パリティやCRCを保存して破損を検出できるようにするとか、メモリブロックごとに書き込み回数をカウントするとか
これがUSBメモリとSSDと呼ばれるメモリの差のようですよ。
USBメモリでもマジメに作ってあるものはこの辺がケアされています。
例えばM-System社のTrueFFSが載っているUSBメモリだと
メモリーの長寿命化をはかる書換え回数分散処理
エラーブロックの代替機能
データの信頼性を高める、４ビットエラー訂正機能
機能がついています。
http://www.iodata.jp/prod/usbmemory/easydisk/2006/epsl/ [iodata.jp]
ダメUSBメモリはここまで挙がっている通り、壊れてもRD/WRエラーを報告しないので注意が必要です。私も経験しました。コントローラーはNetacでした。
Re:案外平気かも (スコア:3, 参考になる)
私のUSBメモリ(8G)も寿命が来て壊れました。
そのときはこれまで大丈夫だったデータが、
ファイルはあるのに中身は壊れているという症状でした。
書き換えしていないファイルまで一斉に破損していたのですが
それに気づかず、HDDのデータに上書きしてしまったので被害甚大でした・・・（これは不注意だった）
この件があったからかフラッシュメモリの信頼性はそれほど高くないと感じているので、
未だにSSDを導入する気がおきません。
便利なのは理解しているので、この不安を払拭してくれるSSDが登場してくれないかな？
Re:案外平気かも (スコア:2)
HDDは読み書き回数だけじゃなく、温度とか回転時間とか多くのパラメータに左右されるので、寿命の検出は難しそうですが、
SSDの場合、書き込み回数監視するだけなので、設計寿命来たよアラート出せるようになりそうな感じはしますが。
Re:案外平気かも (スコア:3, 興味深い)
開発マシンじゃないですが、うちのメインマシンのHDDを
OCZ Apex 120Gに換装して使ってます。(OSはWindowsXP SP3)
体感速度は目に見えて向上したため、導入した甲斐がありました。
ただ仮想メモリを作るとプチフリーズが頻発したので、仮想メモリは
作っていません。またメインメモリは4GB搭載してGavotte Ramdiskを
使ってramdiskにtmpを移動しました。
今のところSSD単体での運用は怖いので、バックアップソフトを使って
データ部分だけを通常のHDDに退避しています。
当面はSSDとHDDの平行稼動で様子を見ます。
And now for something completely different...
Re:案外平気かも (スコア:1)
開発者じゃない人の立場から (スコア:2, すばらしい洞察)
私はソフトウェア開発者ではないのですが、ソフトウェアの体感速度は
昔と比べてずいぶん遅くなっていると思います。
使っているハードウェアは、最新のものではないにせよ、数年おくれ
くらいでは、ついていっているつもりです。
それは、開発者が速いパソコンを使いすぎているからではないかと
思ったりすることがあります。開発者は、自分が開発しているソフトウェアが、
パンピーが使っているそれなりのハードウェアで、どんなにのろのろと
動くか、体験したことがないんじゃないかって。
コンパイル用に高速なマシンというのは理解できますが、テスト用には
一般人が使っているようなマシンを使ってもらいたいものです。
Re:開発者じゃない人の立場から (スコア:2, すばらしい洞察)
きっと逆ですよ。
貧弱な環境しか与えられないために、開発した機能が重くても
「普通のパソコンなら軽く動かせるはず」と思ってしまうのです。
Re:開発者じゃない人の立場から (スコア:2, おもしろおかしい)
・ライブラリがマルチスレッド対応で、すこし遅くなった
・昔は端折っていたチェック処理が入り、すこし遅くなった
・CではなくC++を使うようになったので、すこし遅くなった
・DRAMのアクセスタイムが、20年で半分にしか短縮されてない
・1024x768→1920x1200で画素数が3倍になっている!
・デバッグビルドなど、もっともっと重いのを触っていて、感覚が麻痺している
・どうせリリースする頃にはPCの性能が向上しているからと、多少遅くても工数さけない
・自分のPCでも重いが、高速化に要する工数と、PCのアップグレードのコストを比較すると、やる気が失せる
・機能を正常に動作させるだけで手一杯だ
・重いライブラリも使ってしまう
・必要なところだけ再描画するのが面倒なので、ぜんぶ再描画しちまえ
・バグ修正やバージョンアップで重くなってしまったときのために、わざと遅く作っておく
・カリカリに効率を高めてしまうと、何か変更したときに、遅くなってしまう
・そもそも効率のよいソフトを作るスキルがない
・VMware上で開発するため、レスポンスが悪いのが当たり前になっている
・歳をとって感覚が鈍り、遅さが気にならなくなった
・高速なマウスさばきとキーボードタイプが、若気の至りだと反省した
・ていうか、パンピーは/.Jに来るなよ。
Re:開発者じゃない人の立場から (スコア:1)
と言うのが主な要因だったりして。
＃ 後から遅いって言われてもなぁ・・・。
Re:開発者じゃない人の立場から (スコア:1, すばらしい洞察)
たぶん皆さんおなじみのパソコンソフト作ってるけど、
会社支給のマシンなんて 7 年落ちですよ(泣
仮にリプレースされるとしても、最低スペックの
エントリーモデルだったり・・・。
こういう会社もあるということで・・・。
ただ、おっしゃるとおり、お客さんのマシンはそれなりのスペックは
想定してるかもです。
複数コアやそれなりのメモリー容量を前提としたプログラム設計とか。
だから、それを自分の開発マシンで動かすとやっぱり重い（苦笑
# さすがに AC
Re:開発者じゃない人の立場から (スコア:1)
＞コンパイル用に高速なマシンというのは理解できますが、テスト用には
＞一般人が使っているようなマシンを使ってもらいたいものです。
これは普通にやってるんじゃないかなあ。
むしろターゲットとされる顧客層というのがあって、あなたのマシンがその顧客層が
使っているであろうと仮定されるマシンスペックよりずっと非力であるとか、或いは
単にメーカーの技術力が低くて肥大化し続けてるとかじゃないかと。いつまでも古い
マシンを後生大事に使っている貧乏ユーザー（失礼）が、新しいソフトを次々と買って
くれる優良顧客になるとは考えにくいですからね。
そうそう。「コストダウンの上に納期を早められて、結果として品質低下」というのも
ありえるかな。なにせ世知辛い世の中ですから。
Re:開発者じゃない人の立場から (スコア:1, 興味深い)
> Webアプリが増えたせいだろ。
遅くてやってられないものの代表格は、MS Office 2007だと思います。
インタプリタの上でインタプリタを動かして、その上で動いてるんじゃないかって
思うくらい。UI描画で人を待たせるなんて本末転倒もいいところ。
OpenOffice.orgとかgimpとかのオープンソース系も遅くてやってられない。
Re:開発者じゃない人の立場から (スコア:1)
＞遅くてやってられないものの代表格は、MS Office 2007だと思います。
それでも、昔(PC-9801VM2 上での p1.EXE)よりは随分速くなりました。
Re:開発者じゃない人の立場から (スコア:1)
XP 環境の話ではありませんか? Vista 上だとそれなりの速度で動くのに XP 上だと泣けるほど遅い、というのは Office 2007 が出た直後から言われているように思います。
C2D 1.2GHz クラスのパワーがあるとは言えない Vista 入りノート PC でもストレス感じませし、一太郎 3 (9801VX+HDD) よりこの環境の Word 2007 の方が快適で速いですよ。
PCH (スコア:2, 参考になる)
プリコンパイル済ヘッダーやインクリメンタル・コンパイル、インクリメンタル・ビルドなどで、2回目以降が速いです。
それが逆にトラブルの原因にもなることもあったりもしますが。
久しぶりにFreeBSDに戻ってみて愕然としました。
makeが-jで並列に処理するのには感心しましたが、しかし、ソースファイルが短いのにコンパイルが遅い。
1クラス1ファイルとか、1関数1ファイルなのに、けっこうな時間がかかる。
それらのファイル群を片っ端から#includeして1ファイルに纏め上げたら、速いのなんのって。
make -jすればディスクアクセスがランダムになりやすいのでSSDで高速化するでしょうが、
それは乱暴なソリューションかもしれません。
Re:PCH (スコア:2)
Re:PCH (スコア:2)
makeだと通常1ファイルごとにコンパイラーを起動するから数が多いと遅くなるね。
Visual Studioは複数のファイルをまとめて一度にコンパイルしている模様で、コンパイラーの起動・終了オーバーヘッドが相対的に小さいとか、PCHの内容をメモリ内で使いまわしてるとか、その辺りの手法で差が出ているかも。
Re:PCH (スコア:1)
gcc でも 3.4 からプリコンパイル機能が追加されています。
a.h をコンパイルすると a.h.gch というファイルができて、
以後 a.h を include するときに a.h.gch が優先的に読み
込まれます。
他所様のソースをプリコンパイル向けに最適化するのは難し
いですが、ゼロから作るならプリコンパイル対応にするのも
良いかもしれません。
試しに 11 ファイル(ソース 6000行、ヘッダ 800 行)からな
る plain C のプロジェクトをコンパイルした結果を置いてお
きます。
OS は FreeBSD 6 RELEASE、プリコンパイルヘッダはあらかじ
め作成しておき、全ファイルをコンパイルしています。
単純リプレースでok (スコア:1, 参考になる)
SSDはIntel,Mtronに限定するという前提の話だが、
VisualStudio+MSDNライブラリをインストールしているような環境においては単純にHDDをSSDにリプレースしてしまってかまわない。
対話的処理の一切合切の処理が速くなると考えればよい。たとえWD VelociRaptorを持ってきてもSSDにはかなわない。
ただしNortonGhostなどのイメージングツールでコピーするのではなく、新規にWindowsをゼロクリーンインストールした方がよいようだ。
実験はしていないが、理屈から言うとOCZ Core, OCZ Vertexあたりでも同じような効果は得られると思う。
プチフリーズ (スコア:1)
Re:プチフリーズ (スコア:2)
Mtronは35シリーズに「微妙」という気配があり、他のシリーズでも相性問題を出しやすいので、
絶対安牌ということを考えるとIntelかSamsungがよいかと。
別のHDDなどに分散させておけばあとはどうせ消えてもデータには被害が少なく、小容量で済むOS起動とバッファ用にするなら、
価格が落ちて買いやすくなった超絶対安牌のX25-E 32GBにIYHすれば間違いありません。
あとは全部まだまだ人柱向けかなぁ。
=-=-= The Inelegance（無粋な人） =-=-=
今のところXubuntuでは経験無し (スコア:2)
そこに活用の鍵があるような気がします。
Windowsだとシステムの任意ディレクトリだけをSSDに入れ替えるといったことが難しいから
起動ドライブをSSDにするのが普通で、プチフリーズを招く一因になっているんだと思う。
書き込みアクセスの多いところに使わなきゃいいわけだし。
私は開発者ではありませんが、通常のコンパイルでの書き込みアクセス頻度を考えると
コンパイル時に使うディレクトリだけ、SSDに置くのが吉ってことだと思います。
そのためには、HDDとSSDを両方使えるPCが欲しいわけで、ノートPCでは限られるんですけど…
ちなみに、車の中で振動を気にせず、Googleストリートビューとか利用するために
X31にOCZのIDEな32GBを突っ込んであります。OSはXubuntu。
いろいろ考えたものの、シングルスピンドル機ですから、システム全部/パーティションだけ構成。
HDDからdd複製しただけのシステムで、IOの設定も変えていません。
swap無しにするために、メモリーを1.5GBに増やしましたが、1GBのままでも行けてた気がします。
プチフリーズらしき現象には出会っていません。
起動時間は気にするほどの差じゃ無いですが
回線速度さえ速ければ、ストリートビューのスクロールは
若干SSDのほうが軽快な気がしています。
Re:今のところXubuntuでは経験無し (スコア:1)
システムの一部を……というのはやや難しいですが、NTFS なら普通に任意のフォルダにドライブをマウントできます。もちろんドライブレターを振る必要もありません。
ただ、ACL の設定等を考慮すると Windows、Program Files、ProgramData 以下を気軽にマウントすると面倒な事になると思います。
また、ネタにしか見えない SSD 24 台構成のシステム [gigazine.net]なんかを見ると、高速化したい部分 (Windows 以下、Program Files 以下) を高速化するにはやっぱりシステムドライブにするのが素直かな、と思います。
Re:プチフリーズ (スコア:1)
製品の選択肢が少なすぎる (スコア:0)
Intel X25-Eの32GBで\43k、X25-Mの80GBで\40k。
その他SLCチップ物が32GBで\24k前後。
エロ寒ことIO-DATAのSSDN-S64Bが\10k（あんまし数出てないので入手が難しい）。
まだ入荷されないOCZのVertex32GBが\12k、完売中の一番速度の出るVertex120GBが\40k（値上がりするらしい）。
まともな製品ってこんぐらいですよ。
確かに値段下がったとはいえ、開発環境のストレージにこんなに金出すぐらいなら、
モニタをデュアルにしてメモリ積みまくってRAMDISKにチェックアウトしてた方が効率的じゃないかなぁ。
Re:製品の選択肢が少なすぎる (スコア:1)
で一応含まれているかと...。
http://blog.nabe.jp/archives/000168.html [blog.nabe.jp]
#「エロ寒」って何だろう？って悩んじゃった。
# IOがエロになってサムソンが寒いのね。