マルチでコアなおつきあい

12/12/30初稿

 PC-Audioでは、「CPUコアは少ない方がいい。ていうかシングルコアがいい」と言われることがあります。ですが、イマドキのマルチスレッドなシステムにおいて「マルチコアなハード」は本当に音質的に不利になるのでしょうか。だとするなら、それは何故なのでしょうか。
 PC-Audioではコア数やコアの割り当てなどの変更すら出来ちゃう以上、これも“チューニング”と言えますのでその理解と判断を試みました。


■何がどうマルチなのか

・プロセス・スレッドとは何か
 まずは、何がどうマルチなのか知っておく必要があります。そのためにはコンピュータシステムにおける「プロセス」や「スレッド」について、パーフェクトに正確ではなくともいいので基本的な理解をしないと始まりません。
 ので、自分のお勉強としてざっくりまとめてみました。

 プロセス・・・アプリ実行ファイル単位
 スレッド・・・プロセスが生成する独立した処理単位

 ひとつのプロセスでも複数のスレッドを生成して同時処理することは、同アプリにおける入力系と処理系の分離同時処理などで昔から行われています。もちろんPC-Audioにおいても、例えば「foobar2000 1.1.15」では3~8スレッドを生成して走らせています(再生ソースのフォーマットや操作履歴によって数は変動)。
 あるアプリ(プロセス)がいくつスレッドを動かしているかは、タスクマネージャの「表示/列の選択」でスレッドを表示するように設定すれば確認できます。
 ひとつのプロセス(アプリ)でも複数のスレッドを同時処理しているのですから、複数のプロセスが同時に走ることに不思議はありません。

・スレッドはどうやってマルチに動いているか
 複数スレッドの同時動作は、CPUコア(本稿ではHyperThreadingによるものも含むこととします)が“ひとつしかなかった”時代からも行われています。今でもシングルコアCPUはもちろん存在します。そもそも、マルチタスクOS上ではOSのプロセスが複数同時動作していますが、(代表例として)WindowsはシングルコアCPUでも動作するのは言うまでもありません(Windows7や8は言うまでもなくマルチスレッド対応OSであり、OS自身としてだけでもクリーンな環境でもおおよそ30以上のプロセスと500以上のスレッドが動いています)。

 演算する機能が1系統しかないのに複数同時処理するには、時間的に分割して順番に少しずつ処理するしかありません。

 簡単に言えば“高速に時分割処理”しているのですよね。なので、シングルコアの場合、ミクロで考えれば正確には「同時処理」ではないということになります。マルチコアの場合は、一応、ミクロで考えても「同時処理」“も”していると言っていいでしょう。時分割処理するコアが複数あってそれぞれ連携しているイメージです。

・「マルチスレッド対応」と「マルチコア対応」
 アプリの「マルチスレッド対応」はハードがマルチコアかシングルコアかとは無関係ですし、「マルチコア対応」と同義ではありません。

 「マルチスレッド対応」アプリをシングルコアCPUで動作させた場合、“OSが”時時分割でマルチ処理してくれます。マルチコア対応ハードで動作させた場合は、さらにスレッドを複数コアに分散処理してくれます。

 一方、「マルチコア対応(当然マルチスレッド対応)」のアプリは、OSのスレッド分散機能に依らず、自らが複数コアにスレッド処理を分散させて高速化を図ります。動画エンコードソフトなどが代表例ですね。

 ちなみに、「マルチスレッド非対応」アプリについてはここでは考えません(イマドキ、一般的には対応しているので)。以後、特記なきアプリはすべて「マルチスレッド対応」として記述します。
 もちろん、OSもマルチスレッド・マルチコア対応として記述します(というかWindows7/8を想定)。

 参考サイト
http://sooda.jp/qa/97027
http://ascii.jp/elem/000/000/653/653041/


■どうするといいのか

・ある特定のアプリをスムーズに動かしたい
 いくら最新のマルチコア環境と言っても、システムが動かしているスレッド数よりコア数は遥かに少ないのですから、時分割処理は必ず発生しています。あたりまえですが。
 時分割処理時のスレッド処理は、OSがその都度その時点で最適と判断するコアに割り当てられるので、ひとつのスレッドが同じコアに固定的に割り振られることはありません(設定しない限り)。タスクマネージャではコアを「CPU」と表記しているのでCPUをその意味で記すと、直前がCPU0で実行されていたとしても、時分割処理から戻って再開した時はCPU3での動作となったりする可能性があるワケです。

 つまり、「同じプロセスのスレッドは同じコアで実行されるとは限らない」というワケです。
 そして、いずれの場合も、分散処理の制御や時分割調停のためのオーバーヘッドが発生します。

 以上より、次のことが言えるのでないかと思っています。

あるプロセスの時分割処理を少なくすると、そのプロセス=アプリの処理は低遅延でスムーズになる。
「他人に邪魔されずに自分のペースで作業に没頭できる」イメージ。


 なるべくそうするための考え方は大きくふたつあるのではないかと思います。

1.あるCPUコアをあるプロセス専用にする
  (あるプロセスはそのCPUコアしか使わないようにする)

 そのためには、

 ・あるプロセスが使用するCPUコアを限定する
 ・そのCPUコアは他のプロセスに使用させない

ように設定する必要があります。

 これは、プロセスごとに「プロセッサの関係の設定(Affinity)」を行い、実行するCPUコアを明示的に割り振る作業になります。タスクマネージャでプロセスのプロパティから変更する方法が一般的だと思いますが、あらかじめ設定した内容で一気にやってくれるフリーソフトもあります。例えば「Bill2's Process Manager(以下BPMと略)」などです。

Affinity.jpg  ←関係の設定(i7-2600K)

 CPUの独占設定でひとつ注意すべきなのは、「あるプロセスの使用コアを限定する」だけでは不十分で「その他プロセスの使用コアと排他にする」設定も同時に必要という点かと思います。
 ですが、BPMなどでもユーザが「Affinity」を設定できないプロセスも存在するので、あるプロセスで特定コアを100%占有することはできないでしょう。が、それはやむを得ないとして無視します。実際、E-350(DualCoreCPU)にて、BPMで設定できるプロセスをすべてCPU1に割り当ててもCPU0の負荷は完全に0%にはなりませんでした。

 なお、優遇したいプロセスに専用に割り当てるCPUコアは1個でなければならない理由はありません。マルチスレッドアプリですから、マルチコアで処理した方が各スレッドの時分割発生は減るであろうからです。
 例えば3コア以上あるシステムであれば、CPU0とCPU1を専用に割り当て、その他コアをその他プロセスに割り当てた方がよい可能性もあります。

2.そもそも時分割処理を減らす

 そのためには、

 ・プロセス数を減らす
 ・処理速度を上げる
 ・コア数を多くした方がいいかも?

のも効果的ということになります。プロセス数が少ない方がいいのは言わずもがなですが、CPUの性能(クロック)が低すぎたりプロセスが多すぎると頻繁に時分割され、最悪の場合次の処理が必要になるまでに順番が回ってこずリアルタイム処理が破綻してしまいます。
 実際、E-350にてBPMで設定できるプロセスをすべてCPU1に割り当てて作業するとPC-Audio再生で音飛びが発生します。
 コア数が多いというのは空間的広がりがあることになりますので、時間的な分割が減る可能性があるのではないかと思います。

 ちなみに、本稿の内容を考えている中で無性にやりたくなったWindowsのプロセス削減の顛末はこちらです。


■PC-Audioに適用するなら

 前述「1」の想定からすると、「コア数が少ない方が音がよい」というのは、少なくともソフトウェア的には根拠が薄いことになります。時分割処理回数が増えちゃいますので。

 前述「2」の想定からすると、CPUの処理性能(周波数やコア数による)は高い方がいい可能性もあります。

 以上考えてきた限りでは、コア数はそれなりにあった方がよさそうです(多いほどいいとも言い難いですが)。もちろん事実は解りませんが、ERI的にはそう考えることにしたいと思います。

 さて、とするなら、同じハードでも、上記で言う「あるプロセス」をコア割り当て設定などによって“優遇”してやることで音質向上に効果があるかもしれません。
 「あるプロセス」としてPC-Audioで音質チューンする場合の代表は「プレーヤソフト」でしょう。
 MMCSSを司るプロセスなども候補になると思いますが、本稿では、まずはプレーヤソフトに着目し、コア割り当てを変更することでどんな変化が発生するのかみてみます。プレーヤは現状現役のuLilithです。

 ただし、スムーズになると音質がよくなるとしても、その因果関係は解りません。「専用コア割り当て優遇」していない時にはリアルタイム性が破綻しているとは思えませんので…

 なお、たとえPCではなくAudio専用機であっても、「ファイルオーディオ」である以上は、ネットワークからのデータ受信やUSBメモリからファイルシステムを操作してのデータ読み出しなどをしながらDACへの送出を行っているハズです。もちろんUIFの制御もリアルタイムで必要です。
 つまり、Windowsのような汎用OS環境ではないにしても、マルチタスク動作しているハズです。「ファイルオーディオ」な以上は。

・PC-Audio環境での試聴結果
 主力PC-Audio環境(E-350+HD5450のHDMI-Audio。この時点ではOSはWindows7)で実際試してみた結果を以下に記します。

 uLilithをBPMとタスクマネージャで可能な限り以下のように“優遇”してみたところ、かなり変化あると思います。

 CPU0・・・uLilithのみ割り当て
 CPU1・・・uLilith以外を割り当て

 高域の量は多くないが聴きやすいまとまりのある音。
 CPU割り当てを逆にするとやや高域が増えてその分解像感が高くなる。まろやかさは減少する?
 uLilithだけは両CPUに割り当て許可するとまた変わる。
 しかし、変わるとは思いますが“善し悪し”というレベルとは言い難いです。

 なお、E-350を200MHz駆動にしてK10statのコア別負荷率を見たところでは、uLilith専用に割り当てたCPU0とその他のCPU1の負荷率は20%程度で拮抗していました。

・PC-Audio環境じゃないPCでの試聴結果
 E-350ではコアがふたつしかないのであんまり実験パターンがありません。そこで、Core i7-2600K(HT含めて8コア相当)のメインPCでも試してみました。
 uLilith x64 Core2バージョン。もちろん排他WASAPIイベントモード。クロックは1.6GHzにダウンしている状態です。AudioデバイスであるSoundBlasterPremiumHDのDACは44.1kHzが通らないため、2496ソースを使いました。ヘッドフォンジャックからダイレクトにHD650で聴いています。
 BPMにてAffinityを弄った結果です。BPMのコアナンバリングはタスクマネージャと異なり「CPU1」から始まるので、BPMの場合は「BPM-」を付けて記述します。

 リアルCPUをuLilith、HT-CPUを「その他プロセス」に割り当てるとよい気がします。逆にするとやや曇る?
 BPM-CPU1&そのHT&BPM-CPU2&そのHTの計4コアをuLilith、その他コアをその他プロセスに割り当てるとよい気がします。
 いずれも、デフォルトで何も制御しない8コア時より良いと思いました。弄った後デフォルト状態に戻すと、低域のふくらみがあり音量が大きくなったように聴こえましたので。これは結構違う気がしましたが、どうでしょう?
 また、BIOS設定によるシングルコア状態と8コアの比較も行いました。
 聴き始めはシングルコアの方がよいかと思いましたが、しばらく聴いているとやや8コアの方が明瞭感があってよい気がしました。
 しかし、「非PC-Audio」環境ですから、あんまり自信はありません(苦笑)。

・特別なコア
 上記の環境にて。
 BPMによると、アイドル状態では8コアのうちBPM-CPU1(タスクマネージャではCPU0に当たる“先頭のコア”)の負荷が他の7個より高くなっています。

BPM:CPU使用量

 一方、BPMでは設定できないプロセスがあります。それらはBPMの日本語表示では「未処理」となりますが、英語は「Unhundled」なので「処理できない」の方が近いのではないかと思います。
 つまり、BPMで割り当て変更できないプロセス=システム関連のプロセスはBPM-CPU1を重点的に使っているのではないでしょうか。
 とするなら、“優遇”すべきプロセスは“先頭のコア”以外を使った方がよいのではないかと思われます。

 以下、Windows8に入れ替えたE-350環境にて。
 Windows8では、CPU負荷グラフの中のカーネル資源分に色を付けられます。デフォルトではCPU0とCPU1をまんべんなく使っているようですが、uLilithをCPU1固定にするとCPU0だけ使うようになるようです。色で見た限りですが。つまり、使っていいことになっていても、忙しいコアに無理矢理割り込むようなことはしていないと推定されます(当たり前の話かも知れませんが)。

 また、MMCSSなどPC-Audio関連サービスを司るsvchostだけuLilithと一緒のコア(CPU1)に固定したり、それ以外をCPU0に固定したりしてみましたが、その差は微妙かつ動的(いろいろな条件で変わってしまいそう)なので、あまり突きつめるところではない気がしました。

 なので、無理せずuLilith以外のプロセスはそのままOSのスケジューリングに任せることにして、現在、「Thindows8」環境にてuLilithだけ「CPU1のみ使う」という設定を行っています(予告なく変更する可能性が高いです(笑))。
 Affinityの自動設定方法などについてはプレーヤソフト環境をいぢくる記事をどうぞ。

 なお、システムプロセスまで弄くる場合は、Windows8の「高速スタートアップ」ではシステムプロセスのAffinityも保持されますので、BPMの自動設定と合わせて使うと楽かも知れませんね(完全初期化されないところがちょっとキモチワルイですが)。

・つまるところ
 一通り調べてテストした結果、「プロセスが使うコアの指定やコア数につき何をどうした方がよいかは客観的には言えないだろう」というのが現在の思いです。例えばHyperThreadingは事実上「同じコア」なので有利なのか不利なのか。キャッシュを共有するアーキテクトが有利なのか不利なのか…
 「優先度」設定もあわせてプロセスの設定はいくらでもできますし音質変化も認められると思いますが、どうするのが理屈上良いというものではなくトーンコントロールするつもりで弄るパラメータ、みたいに考えています。
 ただ、トーンコントロールにしてはいちいち調べないと現在どうなっているかが明示的に判らないところがネックですね。

 なお、本稿ではソフトウェア的観点に絞って記載していますが、コア数が少ないとCPU資源的に小さくなり、電流値の減少やノイズ減少に繋がる可能性はあり、そのようなハードウェア的影響もあるかも知れません。
 が、それはコアの数だけの問題ではなく、CPUアーキテクト(キャッシュの仕組みやメーカや世代やその他もろもろ)や消費電力や動作周波数なども大きく関係しますから、「コア数と音質」だけをハードウェア的一般論として語るのは非常に困難だと考えています。


メインメニューへ

テーマ : オーディオ
ジャンル : 趣味・実用

最新記事
ERIへようこそ

Author:らかせ
「最新記事」または
「メインメニュー」からどうぞ

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です

・一応、拍手にコメント(非公開)付けられるようにしてあります

・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください

・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください

・引用の考え方については「007:諸事」をご参照ください

・アフィリエイトはAmazonのみです

・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

カテゴリ
検索フォーム
FC2カウンター