AMD Ryzenレビュー

先週末にようやっと届きました。
CRYORIGのリテンションが届いてませんが、とりあえずリテールクーラーで組み立てました。
本日からリテンションのタイプごとに発送を開始したみたいなので、もう少し待っておけば良かったかなと思いましたが、いつ来るか分からずまた延期の可能性も無くはなかったので、組み直す面倒さよりも早く動作検証したい気持ちの方が大きかったです。
そう言えば、CRYORIGに乗り換えたことをブログに書いてませんでしたね…。
書かなきゃと思ってましたが、これはまた改めて書きたいと思ってます。


前回PCの新調を検討する記事を見返して見ると、次のPC導入までの繋ぎとして考えるといったことが書かれてましたが、繋ぎどころか6年ちょっと使ってしまいましたね(笑)
恐るべしSandy Bridge。今までで一番長く使ったと思います。
もしRyzenが残念だったり、今後発売されるIntelのCoffee Lakeが残念ならきっともっと長く使っていたでしょう。


AMDのCPUは初めての導入になります。
その昔先生にどちらかのCPUに拘るのではなく、Intelが良い時期とAMDが良い時期があるから、情勢を見て選ぶと良いと教わったのですが、自分が初めて自作したCore 2 Duo以降は周知の通り事実上Intelしか選択肢が無かったため、ずっとIntelでした。
先生の言うIntelが良い時期とAMDが良い時期というのは、AthlonPentiumで両社が競ってた時代ですね。
まぁそうは言っても安定性を求めるならIntelというのが一般的に言われていることですし、特に音楽制作用途だとニッチであり、またIntel一強時代が続いた故このところはソフトもIntelのCPUを前提に開発されてると思われますので、AMDのCPUを選択する不安はありました。
しかしCubaseでは特に問題なさそうでしたので、Ryzenにしました。
やや冒険的なところもあるかもしれないけど、今回の性能向上はそのリスクを取ってでも試みてみたい程のものでした。
だって、Intelの8コアであるCore i7 6900Kを買おうと思ったら10万円以上します。。

買ったもの



自分が自作PCのCPUを換える時の3点セットで、その他のレビューしてないものはまた別で書こうと思います。

AMD Ryzen 1700


発売されて色々とレビューが出て来る前までは第一候補として1700Xにしようと思っていました。
予算的な面と、発売前まではXFRがX付きモデルのみと噂されていて、またもっとブーストされると思われてましたので、1700Xが良いかなと思ってました。
しかしレビューが出てくるとXFRによる伸びは0.1GHzだけで、またXなしモデルでもその半分はブーストされることが分かり、そしてどのモデルも4GHz辺りに壁があってその付近までは1700でもOCが可能なことが分かり、1700でいいやとなりました。
実際Ryzen 7の中では1700が一番人気で現在もショップによっては品薄です。
次に人気が4GHzの常用やそれ以上のOCを目指す選別品ということで1800X、1700Xは中途半端といった意見が多いようです。


定格ではTDP65Wですし、普段は定格で使用し、処理が厳しい場面が出てきたらOCといった感じで使いたいと思っています。




AMD CPU Ryzen7 1700 with WraithSpire 95W cooler AM4 YD1700BBAEBOX

AMD CPU Ryzen7 1700 with WraithSpire 95W cooler AM4 YD1700BBAEBOX

ASUS PRIME X370-PRO


発売前、もし1700にするならXFRがないとされていたこともあって、同社のPRIME B350-PLUSの方にしようと思っていました。
PCIeの仕様などはPRIME B350-PLUSでも個人的には十分だから、1700と合わせてコストをなるべく下げるプランとして考えていました。
ですが色々調べて勉強している内にOCするにはある程度フェーズ数があった方が良いことを知ったり、B350は蟹LANばっかだったり、といった点でX370の方にしました。
あとAMDが提供するRyzen Masterユーティリティを使いたかったのもありますね。
B350のマザボでも使えたといった情報がありましたが、使えないものもあり、X370なら間違いないのでこちらにしました。


ASUSマザボを選んだのは、今までずっと使ってきているのと、シェアが大きく色んな人が使っているので、やはりそういったものは何か問題があった時に情報を探しやすいからです。
あと何より早々にPRIME X370-PROでCubaseのレビュー情報があったのも大きいですね。
ただ今回ASUSは上位マザボのROG CROSSHAIR VI HEROで文鎮化する不具合をやらかしており、その時は多少浮気も考えました。




ASUSTeK AMD X370搭載 マザーボード PRIME X370-PRO【ATX】

ASUSTeK AMD X370搭載 マザーボード PRIME X370-PRO【ATX】

Corsair CMK16GX4M2B3200C16


Corsairのメモリを選んだのは、発売当初にAMDが各メディアに提供した評価キットでこのメモリのワンランク下のものが使われていたためです。
発売当初よりRyzenはかなりメモリの相性がシビアといった情報が多かったため、Corsairにしておけば無難かなと思いました。
ASUSのウェブサイトではOCで3200まで対応となっていて、3000との価格差もそれ程でもなかったため、3200のこちらにしました。
あと、背が低いのもポイントでした。ケース上高さの抑えられたトップフローのCPUクーラーしか使えないので。


初めてのOCメモリになりますね。
メモリのOCを知るまで、ごっついメモリは何のためにあるのか、飾りなのかと思ってましたが、ヒートシンクなんですね。
OCすると発熱量が増えるためにメモリにヒートシンクが付いているという。


CPUの取り付け


AMDの場合ピンがCPU側にあります。
CPU側にせよマザボ側にせよピン折れのリスクがあることには変わりありませんが、通常はマザボよりCPUの方が高額ですので、AMDの場合そのリスクが大きいということになります。
AMDのCPUは初めてなので身構えて用心して取り付けましたが、思ってたよりすんなり取り付けることが出来ました。
取付方向さえ間違えず、乱暴に扱わなければ大丈夫だと思います。
あとはCPUクーラーを取り外すときの所謂「スッポン」と呼ばれる現象は気を付けたいですね。


ベンチマーク


恒例のベンチマークですが、今回はCrystalMarkだけでなくその他のソフトも載せたいと思います。
Core i7 2600のCrystalMarkは組み立て時にも計測して掲載してますが、その時からドライブ等が変わっているため改めて計測してます。
1700は3.8GHzのOC、メモリクロックが2666MHzです。
MaxxMEMのベンチだけ2933MHzです。

Core i7 2600




Ryzen 1700





OCとは言え、順当な性能向上です。
Cinebenchで2.7倍、掲載してませんが定格でも2.3倍アップです。
CrystalMarkはグラボとドライブが変わってないので全体のベンチ結果の伸びはそうでもなさそうですが、個別でCPUとメモリを見るとやはり伸びてますね。
MaxxMEMもCore i7 2600の方はメモリクロックが1333MHzですし、それなりに伸びてます。
実際体感でも分かる場面があったので、サンプラー使用においてのNVMeの記事を追記する時に書きたいと思います。

メモリOC


先程も少し書きましたが、メモリの相性がシビアでなかなかクロックを上げることが難しいとされています。
ですのでBIOSの大きなアップデートがあるとされる5月までは最低でも2400MHzで使えれば良いかなと思っていました。
ですが前項のようにXMPの設定で2666MHz、2933MHzと動きます。
3200MHzは一応動いたのですが、起動しないこともあり、不安定な模様。
設定を詰めれば安定動作するかもしれませんが、5月も近いし2933MHzでも動くし、とりあえずこれでいいやと思いました。
思ってたよりも上げることが出来たのは、BIOSのバージョンをAGESA 1.0.0.4適用の0604にしたからでしょうか。


因みに現状はSamsung製のBダイと呼ばれるメモリチップを搭載したものが相性良いようです。
自分のCMK16GX4M2B3200C16はVer5.39で、残念ながらHynix製です。
Ver4台がSamsung製のようです。


RyzenはCCXといった仕組みで4コアを一組としてそれが二つあって、Infinity Fabricと呼ばれるもので接続されています。
メモリOCというのは大幅な性能向上は望めませんが、Ryzenに関してはこの仕組みを採用しているが故、クロックが上がる程より性能が上がるようです。
ですので、Ryzenを活かしたい方はOCメモリを導入するのが良いと思います。

周辺機器について


AMD製の新製品にするということで、周辺機器、特にオーディオインターフェイスとUAD-2が問題なく使えるのか気になっていました。
しかし自分の環境ではFireface 800もUAD-2 OCTOも問題なく使えました。
あ、UAD-2 OCTOに乗り換えたこともブログに書いてませんでしたね(笑)
というか今過去記事を見返して見ると、QUADに乗り換えたことも書いていない。。
これもまたブログに書くかもしれません。


その他の機器も、相性で認識しないとか動作しないといったことはありません。


追記


某所でUAD-2 OCTO以外のPCIe版ではPCIブリッジチップが違うため動作しないとの情報がありました。今後UA側で対応するとは思われますが、QUAD以下を使用している方は様子見が良いかもしれません。

USB3.0について


発売当初からUSB3.0で接続された機器が切断・再接続されたり不安定といった情報がありました。
これはX370特有の問題で、B350の方では大丈夫なようです。
不安定な場合はカードで拡張してそちらを使うと良いようですが、幸い自分の環境では安定しているようです。
これは本当に助かりました。
何故なら勘違いしていてもうPCIスロットに空きがなかったためです。
グラボを挿すことでPCIe x1が一つ死ぬことが頭から抜けてました。

Legacy OpROM


PX-256M8PeGNの記事Sandy Bridge世代なので恐らくLegacy OpROMを選択しないとうまく動作しないのかもといった事を書きました。
RyzenUEFIのみに出来るかと思ってましたが、残念ながら出来ず。
相変わらず最初のBIOSに入る前の画面でフリーズします。
ということは、やっぱりGV-N75TOC-2GL自体がUEFIに対応出来ないということなのかな。
古いグラボとは言い難いものだと思うのですが…。
しかしコンセントから一旦外したら初回は起動出来ない件は、無事改善されました。

個人的な問題


Ryzenによる問題ではありませんが、PCを換装して起きた問題を書き留めておきたいと思います。

USB3.0の内部19ピンが干渉で使えない。


マザボが最新のものになったので、ようやく拡張カードなしでUSB3.0の内部19ピンが使えると思ってましたが、JONSBO RM2の上部にファンを2基取り付けているので、これが干渉して挿せませんでした。
最も、ファン2基は両面テープで取り付けているだけなので、位置をズラせば取り付けは出来そうですが、排気面積的にあまりズラしたくないかなぁ…。
拡張カードは前述の通り使用出来なかったので、とりあえず今はフロントのUSB3.0ポートの使用を諦めてます。
L字に変換するコネクタがあれば、プラグ部がマザボに対して水平になって取り付けることが出来そうですが、流石にそんなものは販売されてなさそうです。


追記


CRYORIGのリテンションが届いたので、全てばらしてファンも一旦外しました。
何とか内部19ピンのUSB3.0が使えないかパーツを仮配置してみて、以下の形で何とかいけました。
ファンは天板ですが、作業をするためケースを逆さまにしています。



すごくダサいかもしれませんが、機能性重視です(笑)
まず左のファンは左奥に詰めたらぎりぎり干渉しなかったので、これで確定して、右のファンをズラすようにしました。
しかし大きく傾けることが難しく、右側の赤丸のフィルターを支えているネジを外すことで何とか収まりました。
このネジ、実はUSB3.0のプラグの下にもあって干渉していたため、こちらも外しました。
あと元々外す予定ではありましたが、ファンを傾けたことでブラケットも干渉していました。
SSDは移動時に外したり付けたりするので、ブラケットには付けずにケース前方に立てかけて使っていました。
ですので無くても問題ないし、無いことで空調的・メンテナンス的な利点もあります。


フィルターの金具を外せばもう少し自由に配置することが出来て、傾ける必要もないと思いますが、排気方向とは言えトップなのでゴミが混入しやすいと思いますし、両面テープを貼れる箇所が限られる問題が出てきます。

ファイルシステムの破損


あれこれ検証して再起動を繰り返してましたが、ある時から起動時にディスクチェックを求められるようになりました。
起動して「chkdsk」をするとエラーが検出されるので、「chkdsk /f」を行なってみるものの、
「ファイル システムの種類は NTFS です。
現在のドライブはロックできません。
ボリュームが別のプロセスで使用されているため、CHKDSK
実行できません。次回のシステム再起動時に、このボリュームの
チェックをスケジュールしますか (Y/N)?」
といった表示旨がされます。
これをYにすると起動時にchkdskを2重に行うことになります。
その他「sfc /scannow」や「dism.exe /Online /Cleanup-image /Restorehealth」を試みてみましたが、
改善されないため、諦めました。


CrystalDiskInfoでは問題ないし、物理的な不具合には見えません。
ドライブは例のPX-256M8PeGNなので新しいですし、Ryzenが来るまで暫く使っていたので初期不良とも考え難いです。
起動時にchkdskが開始されたり、検証するとエラーが出ること以外は動作的には問題ないため、このまま暫くこのまま使い続けます。
OSを再インストールする気持ちになった時、再インストールすればその時直ると思います。
OSも全然入れ替えてないからそろそろ変えなきゃな。
Windows 8.1の時から入れ替えてなく、多分2年以上再インストールしてないと思う。

Cubaseの使用感



レビューを見ていたので予想はしていましたが、現状では性能を活かしきれてない感はあります。
サンプリングレートが88.2kHzの設定で、VSTパフォーマンスが100%近くだったあるプロジェクトが、OC後で70%程度といった感じです。


また、使えないプラグインなどは今のところ確認出来ず、これまでと同じような感じで使えています。

書き出し時間


上記の尺が5:13の楽曲がどれくらいの時間で書き出せるか検証してみました。
するとCore i7 2600が4:28、Ryzen 1700(定格) 2400MHzが4:05、3.8GHz 2666MHzで3:30となりました。
やはり書き出し時間は改善されましたね。
以下に書きますように、エンコードみたいにリソースを使い切ってもっと短く書き出して欲しいところですが…。。

スレッドの割り当て


自分の所謂「おま環」なのかもしれませんが、以前からCubaseでマルチコアをうまく活かしきれていないようで、スレッド1に処理が偏ります。
設定は問題ないと思われ、設定のマルチプロセッシングも有効にしています。自分の基本のバッファ設定は1024サンプルです。
ベンチマークソフトやエンコードではないので、綺麗にリソースを使い切ることが出来ないのは分かっていますが、もっとCPUが動いて欲しいところです。
先程VSTパフォーマンスが70%と書きましたが、この場合のCPU使用率は15%前後です。。



うろ覚えで間違っているかもしれませんが、Cubaseは挿さってるプラグインごとではなく、トラック毎にスレッドへ割り振っていると聞きます。
ですので試しにグループトラックを多く立ち上げ、多段挿しになってたものを各トラックに割り当ててどうなるか検証してみました。
すると停止時のVSTパフォーマンスの負荷はやや下がったのですが、再生時は変わらず、といった結果になりました。


VSTパフォーマンスの仕様について調べてみると、一番多くリソースを食ってるスレッドがVSTパフォーマンスに反映されるとの情報がありました。
これなら確かにその通りになってますが、ですがやはり問題の解決にはなってないですね。
その仕様なら、スレッド1と他のスレッドの差が減らせればそれだけ多くの演算が出来てる、或いはVSTパフォーマンスを下げることが出来るので、差がある程無駄が発生していることには変わりないように思います。
まぁこの問題は今後もあれこれ考えたいと思います。


追記


マルチプロセッシングをオフにするとVSTパフォーマンスのメーターが下がるといった情報があったので、半信半疑で試してみたところ、確かにアベレージは下がりました。
そしてタスクマネージャーを見てみると、スレッド1に偏っていたのが3つのスレッドに同じくらいの使用率で分散しています。



しかしASIO-Guardが外れることでリアルタイムのピークがぐっと上がりました。
ですが一応まだ余裕があり、その状態ではプチノイズが発生することもなくなりましたので、こちらの方が望ましそうです。
今まで何もしていないのに瞬間的にピークが上がってプチノイズが発生することもありました。
そういったものを防ぐための仕組みがASIO-Guardだと思うのですが、自分の環境では逆になっているという…。。
上記を試してから元の多段挿しの方でどうなるか立ち上げてみると、これはこれで面白い結果が得られました。



画像ではVSTパフォーマンスが気持ち異なってますが、再生中上下する中での一コマをキャプチャしたもので、どちらも同じような感じでした。
面白いのは、多段挿しの方は主に4つのスレッドに振られてるところです。
しかし単に4つに割り振っているというより、先程の3つで処理していたものに1つ追加されたような感じで、分散させた方は平均CPU使用率が11%だったのに対し、こちらは16%と全体のCPU使用率が上がっていました。周波数も3.12GHzとブーストされてますね。
分散させたのは前述の通り他のスレッドへ割り振って欲しかっただけで、トータルの演算量は変わらないと思ってたのですが、トラックを分けるとCPU使用率が下がるのは面白いですね。
こうなる理由はよく分かりません。


結論。リアルタイムのピークに余裕がある場合はマルチプロセッシングとASIO-Guardをオフにするのが良いと思いました。
あと、上記でも分かるように設定にあるマルチプロセッシングの有効化は、多分文面通りの意味ではない気がします。
オフになってても1コアしか使わないといったことはありません。
ただ、8コアフルで使ってくれるのかは分かりません…。。


再追記


編曲用のプロジェクトを開いてマルチプロセッシングを有効、ASIO-Guardをオンにした場合、上記とは違ってアベレージが下がりました。
但しスレッド1に処理が偏るのとプチノイズが発生するのは変わらず。
ということで、結論はプロジェクトによって合わせるのが良いのかもしれません。