Zen2 AMD Ryzen 3000シリーズ
AMDからRyzenのZen2世代の発表がされましたね。
主な仕様は以下な感じ
| 名前 | コア数/スレッド数 | ベースクロック | ブーストクロック | キャッシュ | TDP | 価格(ドル) |
|---|---|---|---|---|---|---|
| Ryzen 5 3600 | 6/12 | 3.6 GHz | 4.2Ghz | 35 MB | 65W | $199 |
| Ryzen 5 3600X | 6/12 | 3.8 GHz | 4.4Ghz | 35 MB | 95W | $249 |
| Ryzen 7 3700X | 8/16 | 3.6 GHz | 4.4Ghz | 36 MB | 65W | $329 |
| Ryzen 7 3800X | 8/16 | 3.9 GHz | 4.5Ghz | 36 MB | 105W | $399 |
| Ryzen 9 3900X | 12/24 | 3.8 GHz | 4.6Ghz | 70 MB | 105W | $499 |
今回はRyzen 5、Ryzen 7そしてなんと12コア24スレッドのRyzen 9がラインナップに来ました。
リーク情報で噂されていましたが、ついに12コアをメインストリームに投入してくるとは・・・。
Zen2アーキテクチャを採用し高クロック化とIPCの改善を実現
デスクトップ向けCPUでは初となる7nmプロセスルールを採用しています。
これは今のiPhoneとかと同じ最先端のプロセスルールですね。
プロセスルールとは回路の細かさの指標で、7nmの太さで回路が描かれています。
回路が細ければ細いほど、小さな面積に沢山の回路(トランジスタ)を描ける=性能が高い傾向にあります。
また細い銅線に大電流を流せば焼き切れるのと同じように、細い回路は少ない電力で動かす必要があるため
必然的に低発熱になり省電力にも貢献します。
(正確にはリーク電流という量子力学的な世界の問題が起こります)
ちなみにインフルエンザウイルスの大きさが100nmぐらいです。とんでもない細さですね。
東京ドームにシャーペンで線を引くような物とも。
Intelは7nm(10nm)の移行に苦戦していて、AMDが一歩先に市場に投入する形です。
従来のRyzenはIntelのCoreシリーズに比べてクロックで劣っていましたが、プロセスルールが一歩進んだことで
消費電力、発熱に余裕が生まれてCoreシリーズにより近い周波数になりました。
Zen2ではIPCの改善もされていて、Ryzen2000シリーズより13%アップしています。
IPCとは「1クロックあたりの性能」の指標で、 これが高いとざっくり1クロックで出来る仕事量が増えます。
Coreシリーズは動作周波数とこのIPCが高いこともあってコア数で劣っていてもRyzenより高い実性能を誇っていましたが
13%というのは近年のCPUでは考えられない驚異的な進歩で、現にCoreシリーズはここ数年殆ど増えていません。
Ryzen 1000シリーズから2000シリーズの時でも3%程度だったのでこれはすごいですね。
Coreシリーズをいよいよ同コア同クロック条件で脅かす存在になってきました。
またキャッシュも16MBから2倍の36MBに増えました。
Ryzen 9は特に70MBという目を疑うレベルのキャッシュが搭載されています。
12コア/24スレッドをメインストリームに投入
これも事前に噂されていた通り、メインストリームに初めて12コア/24スレッドのCPUを投入してきました。
しかも価格は499ドルです。頭がおかしい。
12コア/24スレッドといったらIntelはIntel Core i9 9920Xというエンスージアスト向けCPUが該当しますが、
これは一般用ではなく、価格も15万円ぐらいするCPUです。
それを省エネと性能で上回るCPUが5万5千円程度でぶっこんくるのは完全に価格破壊ですね。
これだけコア数を積んでるとRAW現像やら動画編集もさぞかし快適なので、待望の人も居るのでは無いでしょうか。
ただしRyzen 9 3900Xは6コア×２チップという構成なので、チップ間転送の遅延を考えると
ゲーミング性能は１チップで８コアのRyzen 7 3800Xのほうが高そうです。
しかし、配信する場合はRyzen 9で決まりでしょう。i9 9920Xと同等なら
リアルタイムH.264のソフトウェアエンコードが可能なはずなので
限界フレームレートより、高画質で配信したい場合などはRyzen 9 3900Xは十分選択肢に入ります。
ソケットは従来のAM4を採用、B350~X470も互換性あり
驚きなのがRyzen 9でも現行のAM4マザーボードでの利用可能という所。
(一部BIOSアップデートが必要です)
もちろんPCI Express Gen4やおそらく自動オーバークロックを最大効率で使用することは出来ないのですが
現行のマザーボードで動作するのはとても経済的で良いですね。
ポン乗せでCPUを最新世代に換装出来るのはさすがのAMDですね。
またRyzen 3000シリーズに合わせて、X570チップセットのマザーボードも発売されます。
最大性能を引き出す場合は要チェックですね。
UnityでGoogle Play Storeの64ビット要件対応の対応をする
この前UnityのアプリをGoogle Play Storeのアルファチャンネルにアップロードした時、64ビット対応の警告が出ていました。
そういえば、1月頃にこんなアナウンスがありました。
android-developers.googleblog.com
2017年頃からアナウンスはされてたんですが、2019年8月1日からGoogle Play Storeにアップロードする全てのネイティブコードを含むアプリに対して64ビットバイナリを含める事が必須となります。
例外としてゲームデベロッパー向けにUnity 5.6系に関しては2021年8月までは更新を受け入れてくれるようです。
つまりどういうことだってばよ？
Unity 2017以降を使用しているゲームデベロッパーはArm64バイナリのビルドが必須になります。
もうちょっと正確にいうと、AndroidもMonoではなくIL2CPPかつARM64(Target Architectureチェックいれて)
ビルドしなければいけません。
Storeの64ビット対応のためにIL2CPPを使うのがちょっと混乱してて記事も少ないのですが、
ココらへんの歴史的背景はiOSと同じでMonoのランタイムは32Bitにしか対応していないので使えないのです。
UnityでAndroidのArm64対応APKを出力するには
まずUnityのバージョンですが5.6系は無理なので気合でバージョンアップするか諦めます（ええ・・・）
Unity 2017に関してはArm64ビルドのバックポートがLTS版のUnity 2017.4.16f1から入っているのでLTS版まで更新します。
Unity 2018以降はUnity 2018.2からARM64ビルドがサポートされてます。
次にPlayer Settingsを開いてScripting BackendをIL2CPP、Target ArchitectureのARM64にチェックを入れます。
これで準備完了！あとはビルドするだけ
しかしそう簡単にビルドは通らない
新規プロジェクトならともかく、プロダクトの終盤でこの問題に気づいて
この設定を入れたらまず100%ビルドは通りません。
やっとビルド出来たと思ったら起動直後に落ちます。
今まで見たことのない訳のわからないエラーでエンジニアは七転八倒します。
しかし落ち着いて対応しましょう。
まずは初歩的な事として、Android NDKがちゃんと設定されているか確認します。
入ってない場合は、こちらの記事
次に、IL2CPPのビルドで出るエラーは(大抵)ネイティブライブラリの64ビット版が入ってないからです。
ネイティブライブラリとは、つまるところPlugins/Androidとかに入っている.soライブラリのことです。
代表的なライブラリとしては
Firebase Unity SDK
こちらはFirebase SDK 5.2.0からARM64をサポートしていますので古い場合は最新版に更新しましょう。
そのときは一旦Firebaseを全て消したほうがゴミが残らないので安心です。Play Games Plugin for Unity
0.9.51からARM64対応です。こちらも最新版になってるかチェックしましょう。
Firebaseなどを入れた時に付属しているPlayServicesResolverの自動Resolverを切っている場合は手動で動かして更新を掛けます。
他にもビルドが失敗している、起動したら落ちる場合logcatを見て読み込めないライブラリを特定し
そのライブラリの更新をチェックします。
よっぽど特殊なライブラリでなければ、ARM64対応していないということは無いと思います。
ただし、自分で用意した.soなどはARM64でリビルドする必要があります。
この時、ARM64版はAssets/Plugins/Android/libs/arm64-v8aに入れましょう。
IL2CPP自体はエイリアンテクノロジーで大分こなれているのでそれ起因の不具合は少ないと思います。
特にiOS同時開発の場合はiOS側のほうが(主にApple側の制約で)不具合を引くことがあるので
一度動けばスムーズに動くはずです。
処理速度の方はあんまり早くなったように思えないけど・・・。
注意点としてIL2CPPにした場合、iOSと同じようにビルド時間が長くなります。
特にCppCompilerConfigurationをRelease/Masterにすると半端なく長いです。
動作確認で手元でビルドするときはDebugにするか、IL2CPP出力はバッチビルド時だけにしてMonoで出力するほうが良いでしょう。
iOSと違ってランタイム制約がないので、Monoはそのまま使うことが出来ます。
GAEにUnityWebRequestを使ってgzip圧縮転送をする
UnityWebRequestでgzip転送をしたいときがあります。
通常gzip転送する場合は、Accept-Encodingにgzipを指定します。
ただしGAEの場合は、それだけではgzip転送が有効になりません。
詳細は以下の公式ドキュメントに書いています。
How do I serve compressed content? cloud.google.com
Accept-EncodingとUser-Agentにgzipを入れないと有効になりません、ややこしいですね
通常のブラウザだとUser-Agentにgzipは入ってませんが、GAEはgzipで転送してくれます。
つまり、主要なブラウザであるか、gzipがUser-Agentに入っている必要があります、ややこしい。
ということでRequest-Headerに設定するだけです。
ちなみに、UnityWebRequestのSetRequestHeaderにはこんな事が書いています。
These headers cannot be set with custom values on any platform: accept-charset, access-control-request-headers, access-control-request-method, connection, date, dnt, expect, host, keep-alive, origin, referer, te, trailer, transfer-encoding, upgrade, via.
It is possible to set a custom value for the accept-encoding header but the resulting behavior is unreliable so it is strongly recommended to let it be automatically handled unless you can accept the risk of unexpected results.
The user-agent header is automatically set by Unity and it is not recommended to set it to custom value.
流し読みするとUser-Agentは変更できないような感じに見えますが、変更をお勧めしないだけであって変更できます。
変更できることはUnity 2018.3でPC,iOS,Androidで確認しています。
ただし上のサンプルのようなUser-Agentだと訳が分からないので、UnityのバージョンやOS、アプリのバージョンなどを仕込んでおくと良いでしょう。
最終的にどこかにgzipという単語さえ入っていればGAEはgzipで転送してくれます。
まぁでも通常はAccept-Encodingの指定だけでいいので、GAE使う人以外は中々User-Agentを書き換えないと思いますが・・・
余談: しかし標準のUser-AgentはiOSとAndroidで全然形式が違って見にくいですよね。User-Agentは書き換えたほうが統一出来るような気がします。
【Unity】Editor拡張でScriptableObjectを保存するには
時々Editorスクリプトを書くと、これをよく忘れてしまいます。
そして調べると、複雑なコードのサンプルが多くて訳がわからなくなります。
Editor拡張したときの設定情報をScriptableObjectに書き出してAssetにすることがよくありますが
そのときの保存方法です。なるべく簡単に書きました。
ぶっちゃけ保存するときには、書き換えた後にEditorUtility.SetDirty()というメソッドを使用します。
引数にはAssetDatabaseで開いたScriptableObjectを指定します。
サンプルコードです。
EditorGUI.BeginChangeCheck()~EditorGUI.EndChangeCheck()で変更を検知して、
EditorUtility.SetDirty()を呼び出します。
こうするとUnity終了時にScriptableObjectの中身がassetに書き出されます。
アセットを保存するというとAssetDatabase.SaveAssetsとか使おうとしちゃいますね。
こっちを使うとDirtyが立ってるAssetを保存するだけなので、実は反映されません。
UnityEditor.Undo.RecordObjectはおまけです。入れておくとRedo/Undoができますね。
ところでUnityはProjectSettings等、終了時に吐き出す物が多いです。
コミットをするときはUnityを終了してから行うように心がけたいですね。
2019年になった今、Ivy Bridgeはどのぐらいの性能なのか？（最新CPUとの比較）
さて、2019年ということでIvy Bridgeおじさんの私も
さすがにそろそろPCを新調したいなと思います
なんて言ったって2012年のCPUですからねｗ
しかし最近のIntel CPUの価格を見ていると・・・
これは・・・メインストリームであるCore i5 9600Kは年末から値上がってますね
最安値はかなり頑張っているショップがあるようですが、いつまで持つかわからない感じ
Core i7の値段は安定してるようですが、そもそも4万円以上の値がついています
ちなみに今使っているのはCore i7 3770ですが、それでも当時3万円しなかったのを考えると
最近CPUの値段は大分上がっているようです
去年はPayPay祭りやら、今年は10月に増税も控えていて
買い替えの誘惑に駆られそうですが、今のCPUはどの程度の性能があるのか
気になって調べてみました
さて、まず長年の相棒であるCore i7 3770ですがこいつのGeekBenchスコアは
シングルコア3769、マルチコア12279
という結果ですね
さて、値上がりから人気そうと予想されるCore i5 9600Kはいくらでしょう？
ちなみにこちらはCore i5ということで現行のミドルハイクラスの位置づけです
シングルコア5772、マルチコア22310
ですね、さすがにとんでもないですね・・・
シングル比で53%アップ、マルチコア比で81%もアップしています
マルチスコア比が大きいのは、こちらのほうが物理コアが2つ多いからですね
第8世代からコア数が増えています
i5 9600K(6C6T)はHTが無効なのでスレッド数ではi7 3770(4C8T)のほうが多いのですが
HTは見せかけ上の数なので、性能の伸びは物理コアが増えるほどは良くないです
IntelのCoreシリーズは10年近く続いてるので
同じCoreでも世代が違うと7と5の比較でもここまで性能差が出るのは驚きですね
さて、こうなると我々Ivy 世代のCPUは、現在どの程度のランクのCPUと同じなのか？
もう1ランク下のエントリークラスであるCore i3 8100を見てみましょう
ちなみにCore i3は第9世代はまだ発売されてません
シングルコア4382、マルチコア12544
おっ！Core i7 3770とマルチは同じぐらいですね
シングルは相変わらずの猛威ですが3770KモデルでOCしたら同じぐらい行くのではないでしょうか
Core i3 8100は1万5千円ぐらいなのでかなり安いですが、同じぐらいの性能となると
メモリもM/Bも買い換えないといけないので、ちょっと買い替え対象にするのは難しいですね・・・
ここらへんを見るとCore i5 9600Kに人気が集中して値上がりする理由が良くわかります
（正確にはそれだけが原因ではないのですが・・・）
ちなみに巷で人気のRyzenのミドルレンジはどうなのかというと・・・
シングルコアは9600Kに敵わないものの、マルチスコアはいい数字ですね
値段もこちらは2万5千円ぐらい（現在）とIntelよりは手を出しやすい価格になっています
自作であればRyzenを選ぶのもいいかもしれませんね
【個人的おすすめ】Unity導入(Android NDKビルド環境)
※この記事は、以下の記事の続き(おまけ)です。
UnityのAndroid ビルド環境をセットアップしてない方はこちらをお試しください
UnityでNDKビルド(IL2CPP)する場合、最新のNDK環境だと以下のエラーが出ることがあります。
No toolchains found in the NDK toolchains folder for ABI with prefix: mips64el-linux-android
これはAndroid Studioや、sdkmanagerで最新のNDKを入れた場合に起こります。
mips64el-linux-androidというフォルダが最新のNDKでは削除されているのですが、
UnityのGradleが何故かmips64のtoolchainsを必要とします(なんでだろう？)
解決方法は色々ありますが
一番安定するのはAndroid Studio(sdkmanager)でNDKを入れずに
対応したバージョンに差し替える方法です。
※Android StudioやsdkmanagerでNDKをセットアップ済みの場合は
SDKフォルダからndk-bundleフォルダを削除してください
※前回の記事の方法でセットアップした場合は、NDKは入ってないので
このまま先の手順に進んでください。
対応したNDKのダウンロード
UnityのIL2CPPが必要としているNDKは
Android NDK, Revision 13b (October 2016)なのでNDK Archivesから64Bit版をDLします
NDK Archives | Android NDK | Android Developers
これを適当なフォルダに展開します
(今回は C:\Users\%USERNAME%\sdk)
あとはUnityを起動して
Edit -> Preferences -> External Tools のAndroidの項目で
NDKのパスを指定します
UnityのNDKビルドは結構トラップが多いですね
この問題は5.6系のときは起こらなかったので、環境を更新したらハマる事が多いです。
