序
かなりツッコミどころ満載のため、色々と声が上がっているが、DTMや動画編集はしない人が多いため、「よくわからない」という声もあるようだ。
そこで、簡単に解説する。
DTM
DTMでは「プラグイン」と呼ばれる外部ソフトウェアを多用する。
これは、MIDI信号を受け取って音声を返すソフトウェア音源であったり、リバーブやコンプレッサーなどの音声を加工するエフェクトだったりする。
DTMにおいて中央ソフトウェアとして使用するDAWはまず、インストールされているプラグインを検索する。 ここで未知のプラグインは、それを読み込んで情報を取得するため、プラグインの追加時や初回起動時はちょっと時間がかかる。
また、プロジェクトを開いたときは、そのプロジェクトに含まれているプラグインが起動される。 プラグインはその数だけプロセスとして起動される。つまり、3つのトラックにそれぞれの楽器、1と2のトラックにそれぞれコンプレッサー、マスタートラックにリバーブ、なら6つ起動される。 もし、1と2のトラックのコンプレッサーが同じプロセスに入るようになっていれば5つだが、そういうことはあまりない。それよりは、3つのトラックの楽器が同一のプロセスを利用する可能性のほうが高い。
私が知る限り、このプロジェクトを開くときのプラグインの起動は並列で行われるものはない。 そして、これは単純に「連続のアプリケーション起動」という挙動である。
大きなプロジェクトになると数分かかるようなものもあるが、紅茶を入れられる、果てはお風呂に入れるというのは「プラグインの挿しすぎ」を感じる。 ブラウザでタブを無限に開いてリソースを食いつぶすタイプだろうか。
ただし、一回読み込むとプロジェクトを開いている限り、プラグインのプロセスはすべて起動したままになる。 これは再生時に同時に使われているプラグインのプロセスがすべて使われることになるため、ここでは明確にコア数優位である。 私もシングルスレッド性能が低く、コア数が多いサーバープロセッサをDTMに使っているが、これは多くのプラグインが走る状況で刺さってしまわないようにである。
しかし、DTMの場合、バウンス、あるいはフリーズという処理があり、これはトラック単位でレンダリングを行い、トラックをレンダリング済みオーディオに置き換える。 これを使えば同時に使用されるプラグイン数を削減でき、性能の低いPCでも処理しやすくなる。
なお、プラグインの描画が妙に重いというケースがあり、ワークスペースを広くする場合、割とビデオカード性能が必要だったりする。
しかし、DTMで何より問題なのは「ストレージ」だ。 DTMで使うプラグインは大容量のものが多く、単体で100GBくらいあるものもあるし、私が愛用しているKOMPLETE 10 ULTIMATEだとインストール時に600GBを超える。 どれくらいプラグインを買う人かにもよるけれども、1TBというのはDTMにはあまりにも少ない容量であり、2TBでも足りない可能性は少なくない。
そうなるとSSDを入れづらいのだ。ところが、HDDだとCPUなんかよりも先に読み出し速度が音を上げる。 DTMで使える高速で大容量なSSDを揃えるところにめちゃくちゃコストがかかる。
動画編集
動画編集が重いのは事実で、エフェクトを挿すとプレビューがどんどん困難になっていく。 だが、その部分のCPU使われ方でいうと、シングルスレッド性能優位である。
レンダリングは、ハードウェアレンダリングも可能ではあるが、品質面から一般的にはソフトウェアレンダリングを行う。 しかし、比較的並列度の高いlibx265であっても完全な並列ではないため、多数のコアを降るに活用することはできず、やはりここでもややシングルスレッド性能優位である。
単純にカットしてつないだだけのシーンで重くなることは基本的にはない。エフェクトが挿してあったり、多数のクリップを組み合わせるようなものだと重い。 動画再生時間に対してリニアに近い、というのは、たとえFHD 30FPSであってもかなり速い。
ECCメモリ
Ryzen Threadripper 3990Xと組み合わせられるのは、ECC Unbufferedメモリである。
そもそもECCメモリは、何らかの理由で書き換わってしまったメモリのビットを訂正するものである。
このビット腐敗は半ば都市伝説と化しているが、原因はともかく、メモリ上のビットが書き換わってしまう事象そのものは起こりうる。 それは極めて稀だが、長い時間の中で1回以上発生する可能性はそれなりにある。 そして、そのような極めて稀なケースにおいてもエラーを発生させないようにするためのものがECCである。
だが、一般ユーザーにとっては必要性は皆無と言って良い。 これは実際よりも非常に高頻度な計算になるが、10年間の全時間中、ビット腐敗が2度起きるとする。 10年間のすべての時間、コンピュータを起動しているならその問題には遭遇するだろう。 ただし、「ビット腐敗がこれから参照されようとしている確保済みの領域」で発生する確率は非常に低いし、メモリの使用率が下がればそれだけ低くなる。 メモリが解放されたり、新たに確保されればその問題は消滅してしまうし、コンピュータを停止した場合も同様だ。
一般にデスクトップユーザーにとってプロセスのライフタイムは短く、カーネル領域のメモリが書き換わりでもしない限り、問題は発生しない。 さらに、コンピュータのアクティブ時間の割合も低いわけで、一般ユーザーがECCを必要とする場面に当たる確率は、宝くじに当たる確率よりも低いだろう。
もしも、何日、何ヶ月にも渡って計算しつづけるプログラムを走らせるのであれば、途中で停止することがそれまでの結果を失うことになるかもしれないから、念の為にあったほうが良い。 だが、それよりは、途中から計算を再開できる設計にしたほうが安い。
ECCメモリは高可用システムにおける完全性のための部品である。なおかつ、可用性に関わる部分としては極めて確率の低いものになる。 データが破損する可能性でいえばストレージ上で発生する確率のほうがはるかに高く、ECCメモリによって可用性を担保するためには、ファイルシステムもファイルの破損を検証する機能を持つジャーナリングファイルシステムである必要がある(例えばZFSやBtrfs)。 それをせずにECCメモリによって可用性を確保しようとするのは無意味である。
さらに、半導体上のエラーを生じるよりは電気的なエラーを生じる可能性のほうが高いため、ECCに対応することよりも先にレジスタードメモリであることが望まれる。 ECC Unbufferedというのは、非常に中途半端であり、「何をしたいのかよくわからない」ものだ。
なお、私はメインストリームワークステーションは一般にECC Unbufferedのメモリを搭載していることから、そのようなマシンではECC Unbufferedのメモリを積んだままにしていることもあるし(普通のメモリに積み替えているものもある)、サーバーマシンはECC Registeredなメモリしか受け付けないので、ECC Registeredメモリを使っている。 そして、その意義は全く感じていない。他の人よりははるかに長い時間の連続稼働をしているが、ビット腐敗が原因のメモリエラーと目されるエラーを検出したことは一度もない。 もちろん、アプリケーションのクラッシュがそれが原因だった可能性はないではないが、それは「問題が生じる局面」ではない。
32スレッド
ツッコミが上がっているが、Threadripper 3970Xは32コア64スレッド。
もちろん、仮想スレッドをオフにする、という選択肢自体はあるだろう。
しかし、3970Xで100万円超えというのは随分贅沢仕様。