新CPUとかのはなし

AMD
7nmとなり、ついにIntelよりプロセスで先行できるZen2は非常に強力になっているみたい。半分の速度のAVX/AVX2とか、Load/Storeが2ポートしかないとかいったZenでの弱点をつぶし、おそらくIPCではSkylakeを上回れると期待できそう。初代Ryzenは、AVX2が弱いためにx265が速度が出ない問題があったのだが、Zen2ではx265も速度を期待できそうだ。また、グリスでなくはんだと明言されているあたりも安心できる。

キャッシュを増量も驚異的で、キャッシュ容量が減少傾向なIntelとは対照的になっている。というか12/16コアのL3=64MBって、もうeDRAMかというレベル。恐ろしい時代になったものだ…。

問題はあとから16コアが来ます、ということになってしまったことで、どれを買えばいいか迷ってしまうということ。やはり3950X(16コア)を待つべきなのだろうか? まあお買い得なのが3900X(12コア)なのは自明だけど…。

あとAMDといえば一番の問題は日本での価格。クオカード…。

とりあえず、7/7が楽しみ。

---

Intel
Intelのほうはついに10nmが動き出し、IceLakeが発表された。IPCが18%も向上するとされており、これは最近のアーキテクチャの変更としてはかなり大きいように思う。Haswell→SkylakeのIPC改善がぱっとしないものだっただけに、非常に楽しみなところだ。

問題は、このIcelakeがデスクトップにやってくる気配がないこと。
https://ascii.jp/elem/000/001/873/1873186/

どうやら、10nmは(難産なだけに)初期の14nm同様、やっぱりクロックが上がらないらしく、デスクトップには向かないということらしい。記事中では否定的な書かれ方がされているものの、やっぱり14++でIceLakeを作ってほしいなあという気持ちが強い。ダイサイズが問題ならもうGPUとかThunderboltとかなくてもいいからさ… → あるいはCascadeLake-Xの後継でもいいのよ? IceLakeはサーバー向けはあるらしいからいけるのでは?

おもしろかったのは、シングルスレッドの性能をBroadwellと比較したもので、ぱっと見た感じ
Broadwell 1.00
Skylake 1.09
Kabylake 1.22
WhisleyLake 1.42
IceLake 1.47
となっていること。

まず、Broadwell->Skylakeはアーキテクチャが変わっているのに向上率が低い。これはまあやっぱりな、という感じで、Skylakeの拡張がぱっとしなかった感触と一致すると思う。というかSkylakeの本命はSkylake-Xで、AVX512の導入の準備をした、というだけの位置づけなのだろう。(AVX512をport0/1で束ねて実行できるように演算ポートを再配置するとか、L2を8wayから4wayにしたりとかいろいろ)

そのあとのKabylakeからWhiskeyLakeにかけては同じSkylakeアーキテクチャなのにぐんぐん性能が上がっているのもびっくり。これは同じアーキテクチャなので、クロックががんがん伸びたとみることができて、14→14+→14++のプロセス改善効果が大きいことを表しているのだと思う。そして、もとの記事中にもあるように、IceLakeでの大きなIPC向上は、10nmの低クロックによってほぼ相殺されてしまうというのがなんとも悲しい…。まあ10+/10++とかいっそ7nmとかに期待すればいいのだろうか?

CUDA buildのGenerateDepsがとても遅い時のメモ

CUDAのビルドは、普通のC++コンパイルと比べるととても重いのだが、ある時からCUDAのビルドに入る前の処理が重い、という事態になって、とても困っていた。

この度めでたく解消したのでメモ書き。

続きを読む

続きを閉じる

---

CUDAのビルドに入る前段階が遅いというこの現象、Visual Studio 2015 + CUDA 8.0, Visual Studio 2015 + CUDA 10.1, Visual Studio 2019 + CUDA 10.1のいずれの環境でも発生していた。まあ、ビルドが遅いというとディスクの問題が考えられるけど、さすがにNVMe SSDでディスクが原因ということはないと思っていた(もしそうなら突然遅くなったりしない)。

そもそも、この現象はそれなりに報告例がある。
Slow compilation C++/Cuda GenerateDeps
Slow performance after update KB4093112
Why CUDA 7.5 + Visual Studio 2013 extremely slow “generating dependencies”?

問題はいずれの報告例も未解決だったり解決方法が「Windowsの再インストール」だったりで、ちょっとそれは…という感じだった。

解決の糸口になったのはこの記事。
Tremendously slow build with Visual Studio 2013 (MSBuild)
I had to edit Nvda.Build.CudaTasks.*.dll files because cl.exe /E (Preprocess to stdout) option in the dll file makes my build crawl. It happens during AddCudaCompileDeps target. Does anyone have similar experience?

この記事だけだとあまりよくわからないが、これで検索キーワードを少し変えると、
Visual Studio 2012 build hangs
I had to replace cl.exe /E option to /P within Nvda.Build.CudaTasks.vX.Y.dll files to evade the problem. There wasn't the problem few days ago so I'm not sure at all why the problem has surfaced.

そしてついにこちらの記事に行き着いて、対策方法を見つけることができた。

これによれば、Nvda.Build.CudaTasks.v*.*.dllの"/E"→"/P"に置換すればよいとのこと。(理由はよくわからないけど…)

CUDA 10.1なら、Nvda.Build.CudaTasks.v10.1.dllを、xeditなどのバイナリエディタで(wcharなので) "2F 00 45 00" (/E) を "2F 00 50 00"(/P)に置換すればよい。

NVEnc.slnのフルビルドの時間を測ってみたところ、GenerateDepsのところが200.7秒から8.7秒に大幅に高速化されているのがわかる。…というかこのぐらいが普通なのでは…?

実行コマンド
Msbuild NVEnc.sln /p:Configuration=RelStatic;Platform=x64 /t:Build /v:diag

変更前

タスク パフォーマンスの概要:
        0 ミリ秒  Message                                   33 回呼び出し
        0 ミリ秒  AssignTargetPath                           9 回呼び出し
        0 ミリ秒  AssignProjectConfiguration                 5 回呼び出し
        0 ミリ秒  CudaSetEnvironmentVariable                16 回呼び出し
        0 ミリ秒  CountItems                                15 回呼び出し
        0 ミリ秒  ReadLinesFromFile                          5 回呼び出し
        0 ミリ秒  ResolvePaths                              15 回呼び出し
        0 ミリ秒  Touch                                     10 回呼び出し
        0 ミリ秒  AssignCulture                              1 回呼び出し
        0 ミリ秒  CreateItem                                 1 回呼び出し
        0 ミリ秒  SanitizePaths                             31 回呼び出し
       16 ミリ秒  SetEnv                                   100 回呼び出し
       16 ミリ秒  SplitToItemMetadata                       16 回呼び出し
       16 ミリ秒  ResolvePackageFileConflicts                5 回呼び出し
       16 ミリ秒  MakeDir                                   60 回呼び出し
       16 ミリ秒  GetOutOfDateItems                          6 回呼び出し
       31 ミリ秒  XmlPeek                                   15 回呼び出し
       31 ミリ秒  Delete                                    24 回呼び出し
       94 ミリ秒  CustomBuild                                1 回呼び出し
       94 ミリ秒  ReadMetadataLinesFromItems                15 回呼び出し
      172 ミリ秒  RC                                         1 回呼び出し
      203 ミリ秒  WriteLinesToFile                          38 回呼び出し
      922 ミリ秒  Exec                                       2 回呼び出し
     2265 ミリ秒  LIB                                        4 回呼び出し
     6873 ミリ秒  CL                                         6 回呼び出し
    35601 ミリ秒  Link                                       1 回呼び出し
    143716 ミリ秒  CudaCompile                               15 回呼び出し
    200708 ミリ秒  GenerateDeps                              15 回呼び出し
    578494 ミリ秒  MSBuild                                   14 回呼び出し

変更後

タスク パフォーマンスの概要:
        0 ミリ秒  AssignTargetPath                           9 回呼び出し
        0 ミリ秒  Delete                                    24 回呼び出し
        0 ミリ秒  AssignProjectConfiguration                 5 回呼び出し
        0 ミリ秒  MakeDir                                   60 回呼び出し
        0 ミリ秒  CudaSetEnvironmentVariable                16 回呼び出し
        0 ミリ秒  ReadLinesFromFile                          5 回呼び出し
        0 ミリ秒  CountItems                                15 回呼び出し
        0 ミリ秒  XmlPeek                                   15 回呼び出し
        0 ミリ秒  CreateItem                                 1 回呼び出し
        0 ミリ秒  ResolvePaths                              15 回呼び出し
        0 ミリ秒  SanitizePaths                             31 回呼び出し
        0 ミリ秒  AssignCulture                              1 回呼び出し
       16 ミリ秒  Touch                                     10 回呼び出し
       16 ミリ秒  GetOutOfDateItems                          6 回呼び出し
       16 ミリ秒  SplitToItemMetadata                       16 回呼び出し
       16 ミリ秒  Message                                   33 回呼び出し
       16 ミリ秒  ResolvePackageFileConflicts                5 回呼び出し
       31 ミリ秒  SetEnv                                   100 回呼び出し
      109 ミリ秒  ReadMetadataLinesFromItems                15 回呼び出し
      125 ミリ秒  CustomBuild                                1 回呼び出し
      125 ミリ秒  WriteLinesToFile                          38 回呼び出し
      156 ミリ秒  RC                                         1 回呼び出し
      937 ミリ秒  Exec                                       2 回呼び出し
     2234 ミリ秒  LIB                                        4 回呼び出し
     6842 ミリ秒  CL                                         6 回呼び出し
     8673 ミリ秒  GenerateDeps                              15 回呼び出し
    35755 ミリ秒  Link                                       1 回呼び出し
    145903 ミリ秒  CudaCompile                               15 回呼び出し
    390885 ミリ秒  MSBuild                                   14 回呼び出し

というわけでだいぶ速くなったけど、CudaCompileはまだ遅い…。まあ、工程が複雑なうえにプロセスを起動したり落としたりを繰り返しているから仕方ないのかな?

あと、今回は工程ごとの時間を/v:diagを使って表示したかったのでMsbuildでビルドしたけど、Msbuildでビルドすると逐次実行になっているようで、普通にVisual StudioからビルドするとCudaCompileは並列実行されるので、そこまで苦痛ではない。GenerateDepsはVisual Studioからビルドしても並列にはならないようなので、結構苦痛だった。

WD Ultrastar DC HC530 14TB HDD (WUH721414ALE6L4)

HDDはバックアップの都合上、基本的に同じ容量のものを2台導入することにしている。

前回は東芝の14TBのHDDだったので、今度はWD(HGST)の14TB HDDにしてみた。

今回のディスクもちゃんと瓦(SMR)でないことが明言されているので安心して使うことができる。



続きにベンチマークを。

続きを読む

続きを閉じる

---

CrystalDiskInfoの表示。14000GBはいつ見ても圧巻。



ベンチマーク結果(1GB)↓。265MB/sと、これまたHDDとしては恐ろしい速度だ。



このHDD、キャッシュが512MBもあるというので、念のためテスト容量を32GBにして再テスト↓。ややスコアが下がるものの、それでも250MB/s越えはすごい気がする。



とはいえ、ずっと250MB/sを維持できたとしても14000GBすべて読むには15.5時間かかる…というと14TBという容量の巨大さがわかると思う。(しかも実際には内周に行くにつれて速度は下がる)

---

参考までにこれまでのベンチマークまとめ。

容量	メーカー	型番	Seq. Read	表	裏	info	bench
320GB	SA	HD321KJ	63.7	*	*	*	*
500GB	H	HDP725050GLA360	93.9	*	*	*	*
500GB	H	HDP725050GLA360						カッコンして死亡
1TB	WD	WD10EACS_00ZJB0	80.9	*	*	*	*	不良セクタ増
1TB	WD	WD10EACS_00ZJB0						不良セクタ増で死亡
1.5TB	WD	WD15WARS_00Z5B1	96.9	*	*	*	*
1.5TB	SA	HD154UI	114.6	*	*	*	*
2TB	H	HDS722020ALA300	132.9	*	*	*	*
2TB	H	HDS723020BLA642	149.0	*	*	*	*
2TB	H	HDS723020BLA642	172.4	*	*	*	*
2TB	H	HDS723020BLA642	172.4	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	120.6	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	118.8	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	126.7	*	*	*	*
3TB	H	HDS723030ALA640	155.3	*	*	*	*
4TB	H	HDS724040ALE640	169.6	*	*	*	*	不良セクタ増
4TB	H	HDS724040ALE640		*	*
4TB	H	HDS724040ALE640		*	*
4TB	H	HDS724040ALE640		*	*
5TB	T	MD04ACA500	196.7			*	*
6TB	H	HDN726060ALE610	226.9	*	*	*	*
6TB	T	MD04ACA600	196.7	*	*	*	*
10TB	H	HUH721010ALE600	245.7			*	*
10TB	WD	WD100EFAX_6BLHPN0	202.8	*		*	*
14TB	T	MN07ACA14T	237.6	*	*	*	*
14TB	WD	WUH721414ALE6L4	265.4	*	*	*	*

H ... HGST / WD ... WesternDigital / T ... Toshiba / SA ... Samsung

2018年を振り返る (PC編)

といっても今年あんまり買ってないんですよねえ…。

今年はやっぱり個人的にはGeforceの次世代としてRTX20xxが登場して、NVENCの画質がかなり改善したのが一番かなあ。実際に買ってみると、HEVCへのBフレーム機能の追加でかなりの改善が見られたのがうれしかった。

画質比較 2018.11 (アニメ版)
画質比較 2018.11 (実写版)
画質比較 2018.11 補足 - エンコ速度

続きを読む

続きを閉じる

---

覚えてる限りの買ったCPU/GPUリスト & 2019年欲しいもの

	Intel	AMD	GeForce	Radeon
2008	C2Q6600		GT8600
2009	i7 920		GT9600
2010	Xeon W3680			HD4350
2011	i5 2500		GTX460
2012	i7 3770K
2013	i7 4770K		GTX 660
2014	i7 5960X	A10-7850K
2015	i7 6700K Celeron N3150		GTX970
2016	Celeron J3710		GTX1080 GTX1060	R7 360
2017	i7 7700K i9 7980XE	R7 1700
2018			GTX2070
2019	IceLake (SunnyCove)?	Zen2? (R7 3700X?)

だいたいのCPUは買ってよかったと思っているけど、ちょっと後悔したのは
・i5 2500: i7 2600Kにしとくべきだった
・i7 6700K: 思いのほかクロックが上がらなかった(外れだっただけ?)のもあって、オーバークロック込みだとi7 4770Kからの向上が微妙だった定格なにそれ?

CPU
今年もどんどんCPUのコア数が増えて、メインストリームで8コアCPU(i9 9900K)が登場した。i9 9900Kはすこし興味はあったのだけど、やっぱり値段が高いのとfgoで石使いすぎたのとアーキテクチャはSkylakeのままなので、やっぱり買うなら新アーキがいいなあ…とか思ったりしてしまった結果、これまで狂ったように毎年Intel CPUを買ってきたのに、ついに今年はなにも買わないという結果になってしまった。

まあ、2015年から続く14nm & Skylakeアーキ系CPUにはさすがにそろそろ飽きてきたので、来年はSunnyCoveを買いたいところ。SunnyCoveはいろいろ拡張されるようで楽しみ。問題は最近ずっと言ってる気がするけどやっぱり10nmがちゃんと出てくるか、だと思う。

GPU
Pascalから2年ぶりにコアが更新されたTuringが登場した。GDDR6対応もあって順当に性能が伸びていてよいのだけど、ついでに消費電力はまあいいとしても値段が結構高くなっているのがやや難点。一時期RTX2060はGTX1060を作りすぎたのでしばらく出ないよみたいな話があったのでついRTX2070を買ってしまったけど、エンコードのために7万近いGPUを買うのはしんどいかも。正直RTX2070を買ってなければi9 9900Kを買うのもありだったかなあ…。

それでも目的のHWエンコ機能には大満足。NVENCのHEVCのBフレーム対応などで大幅に改良され、なかなかびっくりした。ここまでよくなるとは…。

DRAM
去年～今年前半はばんばん値上がってやばかった。最近は値下がり気味。高すぎたので最近買ってない。

SSD
こちらは結構値下がってきている。NVMeでも512GB程度ならかなり安く手に入るようになってきていて、やっぱり今後はOS用にはより高速なNVMeを導入して行きたい感じ。
2TBのSSDも出てきているけど、安いやつは気を付けないとQLCという地雷が潜んでいる…。SLCキャッシュを使い切ったら120MB/s前後でしか書けないらしく、ちょっと微妙。記事中には135GBまでは大丈夫なので実用上問題ないとあり、まあたしかに常に135GBのSLCキャッシュがあればその通りだと思うけど、ディスクを使っていけばおそらくキャッシュ領域もどんどん減るのだろうし、そうなってくるとやはり微妙だと思う。
とはいえ、やはり容量単価が安いに越したことはないので、TLCも次第に普及して気づけばTLCだらけになってしまったように、そのうちQLCだらけになる日が来るのだろうか?

HDD
まだまだ大容量化は進んでいて、14TBというHDDが出てきている。

ただ、プラッタ当たりの容量はほとんど伸びなくなっているようで、それを打ち破る当面の策が瓦(SMR)なのだと思う。それもSSDみたいにブロック単位でしか消せなくなるなど性能的には微妙なので、将来的にはHAMRやMAMRなどの技術が実用化されなければ、SSDに容量単価でも追いつかれてしまう日が来てしまうかもしれない。

番外編
スマホ
Fate Grand Order(fgo)がXperia XZでとても遅いのでiPhone Xsを買ってしまった。

iPhone Xsは、たしかにfgoがすごく速いし、7nmだし、画面もきれいだし、電池もよく持つし、製品としては素晴らしいと思う。思うんだけど、とにかく値段が高いんですよねー。14万て…。でもまあfgoが速いのでよしとしよう…。なにしろバトル画面のロードが40秒超かかっていたのが、8～10秒まで短縮されたのは大きい。

iPhone Xsの前に使っていたXperia XZなどandroid系端末でfgoが悲惨なほど遅いのはいったいどいうわけなのかと調べてみると、どうやらこういう古いAndroid系端末のストレージにはeMMCなフラッシュばかり使われているから…らしい。

一方、iPhoneはさっさとNVMeに移行済みで、ストレージに決定的な速度差があるという。たしかにeMMCなWindowsタブレットも悲惨なほど遅かった記憶があるので、そういわれると納得できてしまう。また、最近ではAndroidもストレージがより高速になりつつあるが、それでもUFSという接続らしく、NVMeには及ばないらしい。(なので、最近のAndroid端末でもバトル画面のロードが20秒きるのがやっとらしい…)はやくNVMeの普及を願うばかりだ。よくわからんけど、りんごができるんだから他ができないはずはあるまい…。

このあたり、スマホのストレージの情報は乏しいことが多いのだけど、やっぱりチェックしておく必要がある部分だと思う。

まあ、ストレージの速度の影響を激烈に受けるfgoみたいなもののほうが珍しいのかもだけど。

東芝 14TB HDD (MN07ACA14T)

いい加減、fgoの周回も飽きてきたので、ちょっとベンチマークでも。

今回は9枚プラッタ入りという東芝の14TBのHDD。プラッタの枚数が多いのは大容量化に貢献する反面、消費電力増やHDDの重さにつながるので、必ずしもよいことではないけど、まあ瓦(SMR方式)よりはいいでしょう。(というか最近の2TB/プラッタはだいたい瓦らしいので…)



続きにベンチマークとか。

続きを読む

続きを閉じる

---

14000GB、9枚プラッタの力業とはいえ、すさまじい容量。


クリックで拡大

速度は250MB/sぐらいいくかなと思ったけど、それほどでもない模様。音は主観だけど静かなほうだと思う(ランダムアクセスのベンチマーク中でもそんなにカリカリ音が響かない)。


クリックで拡大

参考までにこれまでのベンチマークまとめ。

容量	メーカー	型番	Seq. Read	表	裏	info	bench
320GB	SA	HD321KJ	63.7	*	*	*	*
500GB	H	HDP725050GLA360	93.9	*	*	*	*
500GB	H	HDP725050GLA360						カッコンして死亡
1TB	WD	WD10EACS_00ZJB0	80.9	*	*	*	*	不良セクタ増
1TB	WD	WD10EACS_00ZJB0						不良セクタ増で死亡
1.5TB	WD	WD15WARS_00Z5B1	96.9	*	*	*	*
1.5TB	SA	HD154UI	114.6	*	*	*	*
2TB	H	HDS722020ALA300	132.9	*	*	*	*
2TB	H	HDS723020BLA642	149.0	*	*	*	*
2TB	H	HDS723020BLA642	172.4	*	*	*	*
2TB	H	HDS723020BLA642	172.4	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	120.6	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	118.8	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	126.7	*	*	*	*
3TB	H	HDS723030ALA640	155.3	*	*	*	*
4TB	H	HDS724040ALE640	169.6	*	*	*	*	不良セクタ増
4TB	H	HDS724040ALE640		*	*
4TB	H	HDS724040ALE640		*	*
4TB	H	HDS724040ALE640		*	*
5TB	T	MD04ACA500	196.7			*	*
6TB	H	HDN726060ALE610	226.9	*	*	*	*
6TB	T	MD04ACA600	196.7	*	*	*	*
10TB	H	HUH721010ALE600	245.7			*	*
10TB	WD	WD100EFAX_6BLHPN0	202.8	*		*	*
14TB	T	MN07ACA14T	237.6	*	*	*	*

H ... HGST / WD ... WesternDigital / T ... Toshiba / SA ... Samsung

RTX2070を買ってしまった

Turing世代も欲しいな、と思いつつ、RTX2080/RTX2080Tiはさすがにゲームもしないのに買うのは高すぎた。まあ、RTX2070も70番台のわりになんだか十分高いのだけど…。

EVGA GeForce RTX 2070 XC Gaming, 8GB GDDR6で、Amazon.comで$625。現状のRTX2070の国内最安値が7万弱なので、それと比べれば少し高いだろうか。少しファンとか頑張ったモデルだと8万越えているので、それよりは安いと思う。10/25注文、10/30発送、11/3到着。







結構大きめの2連ファンのGPU。



Skylake-XのPCに取り付けるとこんな感じ。下段のGTX1060が小さくて可愛いく見える…。



RTX2070の--check-featuresの結果はこちら。ついにHEVCにBフレームが追加されたのが特徴。

GPU-Zはこんな感じ。高いだけのことはあってなかなかのスペック。(まあ、それでもエンコードしかしないのだが…)

DVDの寿命

どんなメディアにもたいてい寿命がある。

寿命が短いというと、フロッピーとかSDカードとかで、調べるとだいたい5年～10年とかと書いてあって、やっぱり結構短めだ。というかSDカード等のフラッシュ系って2～3年しか保たない印象あるが…、まあそれはいいか…。

こうした中、比較的寿命が長いとされているDVDをはじめとする光ディスク系だと、5年だったり、数十年だったり、なんかいろんなことが書いてある。

まあたしかに、メディアの品質、書き込み方法、保管状態等、条件が変われば大きく変わってしまうということになるんだろうけど、結局どんなもんなのかよくわからない。

で、じゃあ、自分の持ち物ではどうだったのか、という話。

500枚の古いDVDを読み込んでデータ移行をしようとしたときに、どのくらいのDVDが読めなかったか、数えてみた。

続きを読む

続きを閉じる

---

経緯とか

---

最近、わりと昔に録画したDVDを再生しようとしたら、読み込んでくれなくて、「フォーマットしてください」とか言われてしまった。いやいや消しちゃあかんから…。

思い返せば、DVDレコーダなるものを導入したのは2004年ぐらいで(たぶん)、そうするとそこからは14年たっているわけで、さっき調べた「寿命」を考えれば、そろそろ危ないのかな、ということになる。

そこで、とりあえず今後も保存しておきたいデータをHDDに移行することにした。

まあ、最近のDVD/BDレコーダだとCPRM(いわゆるコピー10とか)がかかってしまって録画したDVDのバックアップとかできないわけなのだが、当時はアナログ放送だったのでそんなものもなかったし、地デジチューナー搭載のDVDレコーダを買っても(アナログ停波までは)あえてアナログ放送を録画していたので、DVDを読めさえすればコピーは問題なくできるのだった。(まあある時期から〇V4を買ったりしたわけだが…)

ちなみに、こうした録画データはTVMW6で読み込みからエンコード(x265)まで全部やってしまうのが便利。やはりDVDを読み込んで一括でフィルタをかけてバッチ登録して…といったあたりを手間をかけずにできるのはいいと思う。とはいえ、読み込んだ枚数が多かったので、3台のDVD/BDドライブを同時に使って読み込んだにもかかわらず、3週間程度かかってしまった。毎日DVDをちょこちょこ入れ替えるのはなかなかめんどう…。

---

今回読み込んだDVDについて

---

外観: めっちゃ多い。




対象メディア: DVD-RAM 362枚、DVD-R 138枚、合計500枚

書き込み時期: 2004年～2011年 (大半は2009年ごろまで)

保管状態
木製の引き出しに入れていたので、直射日光等の問題はないはず。温度は室温に準ずるわけで、まあ、夏は暑かっただろう。夏の関東地方では理想的な保管状態を維持するのはどう考えても無理っぽい。

書き込んだDVDレコーダ:
Victor DR-MF1
Panasonic DIGA DMR-EX200V ※まだ稼働中

読み込みドライブ
Pioneer BDR-209XJB x2 (BDXL対応、SATA-USB3.0変換で接続)
Buffalo DVSM-XL1218U2 (USB2.0 DVDスーパーマルチ)

---

読み込み結果(読み込みエラー枚数の確認)

---

上に書いた3台の読み込みドライブのうち、一台でもDVDの論理構造を読み込めれば、「読み込めた」ものとし、論理構造すら読み込めなかった(Windowsにファイル構造が認識されかった)もののみを「読み込みエラー」とした。実際には、「読み込めた」もののなかでも、映像データが破綻し、いわゆる「ブロック割れ」することがあったが、今回はそれは考慮していない。

まずは枚数の多いDVD-RAMから。

メディアの種類	メーカー			速度(倍速)	エラー枚数	全枚数	エラー率
DVD-RAM	Maxell	カラー		2倍	1	18	6%
		銀		2倍	16	87	18%
		銀		3倍	6	10	60%
	TDK	カラー		2倍	0	3	0%
		白インクジェット		2倍	0	2	0%
	Mitsubishi	カラー		2倍	1	12	8%
	Victor	カラーインクジェット		2倍	0	14	0%
	Panasonic	白		2倍	10	75	13%
		濃青		2倍	0	31	0%
		白インクジェット		2倍	3	18	17%
		黒		2倍	0	7	0%
		白		3倍	33	42	79%
		北京五輪		3倍	1	12	8%
		金		3倍	0	13	0%
		濃緑		3倍	2	18	11%
DVD-RAM 2倍速 合計					31	267	12%
DVD-RAM 3倍速 合計					42	95	44%
DVD-RAM 合計					73	362	20%

20%死亡…という、なかなか悲しくなってしまう数字。というか泣きたい。

特定のメディアのシリーズに集中してエラーが発生している傾向にある。なかには連続10枚死亡、というのもあって、寿命的に外れロットだったのか、あるいは書き込みドライブの調子が悪かったのか…。

メディアの品質というのも気になるところだが、より速い3倍速のメディアでエラーが多いことから、やはり高速書き込みはリスクが高いみたい。書き込み時間が30分から20分になるので便利だったのだが…。

※そもそも使用していたDVDレコーダでは、あえて遅い速度で書くことはできない。

---

次にDVD-R。

種類	メーカー			速度	エラー枚数	全枚数	エラー率
DVD-R	Victor	カラー		8倍	0	17	0%
	Sony	カラー		8倍	1	24	4%
	Panasonic	カラー		8倍	3	23	13%
	TDK	カラー		8倍	0	2	0%
	不明	カラー		8倍	0	10	0%
	Maxell	カラー		8倍	0	10	0%
	富士フィルム	カラー		8倍	0	40	0%
	富士フィルム	カラー		8倍	0	12	0%
DVD-R 合計					4	138	3%

こちらは比較的優秀で、エラーは3%。昔、有機色素なDVD-Rに比べて、無機色素を使っているDVD-RAMのほうが耐久性が高いようなことを聞いた記憶があるが、そんなことはなさそうな結果だ。

もっとも、DVD-Rといえば、20倍速だの24倍速だのがでてきたわけで、そういうのを使っていれば違った結果になっていたのかもしれない。

---

今後のデータ管理

---

というわけで、DVD-RAMの20%が死亡するという、なかなか悲しい結果になってしまった。ただ、これだけ数を集めると、なんとなく傾向がわかってくると思う。やはりメディアのシリーズによって違いがありそうな気がするし、速度を上げて書き込むのはリスクが高そうだ。

そうはいっても、こういうDVDの寿命とかいうのは、いま年月が経ったからわかるのであって、DVDを買ったときにはわからないのが難しいところだ。(まあ、記録面を見れば品質がわかるプロの人もいるかもしれないが、ちょっとわたしにはそんな技能はない…)

今後のデータの保存という点では、HDDがどんどん大容量化したことで、もう光メディア(BD)での管理はメディアの記録容量の問題と、容量単価的に厳しくなりつつある。場所をとるのもちょっと問題。

HDDは駆動部品の多い機械なので、機械的な故障確率が高いので不安はあるけど、やはり圧倒的な大容量と容量単価の安さは魅力的。とりあえず違うメーカー同じ容量のHDDを1台づつ買って二重にデータを書いておいて、3～5年ぐらいで定期的にHDDを更新していくのがいまはベストなのかなあと思う。

大容量なので、データを移動するときにもDVD/BDのようにちまちま入れ替える必要がなく、1日ほおっておけばコピーが終わるのも手間がかからなくていい。ただ、大容量なぶん、死んでしまうとダメージが大きいので、2台同じものを作っておいてどちらかが壊れてもよいようにするのは重要だと思う。

---

データの移行は繰り返されるが…

---

今回移動したデータの中にはかつて8mm/VHS→DVDに移行したものもあって、今回それをさらにHDDに移行したことになる。

今回痛感したように、メディアには寿命がある。そうすると、時代に合わせてメディアを移動していくことが、データを長期間保存していくには不可欠だと思う。

ところが、それを阻むものがある。むろん、あのコピー10とかいう厄介なやつだ。

うえのほうで、あえてアナログで録画していたと書いたが、どうしても放送時間がかぶってしまい、〇V4 or アナログチューナーが足りずに地デジを録画したことがあった(まあ、優先度は低いのだけど)。これらを保存したDVDは当然CPRMがかかっており、そのまま置いておくしかない。それはつまり、いつか劣化して寿命を迎えるのを待つほかない、ということだ。

今回、かつてVHSにあった大昔のデータもDVDを経由してHDDに移り、圧縮劣化はしたものの今後も当分は保存していけるだろうと思う。その一方で、より最近の地デジのデータがおそらくそれより先に消えることになるんだろうなと思うと、なんだかなあ、と思わずにはいられない。

まあ、最近は動画等のコンテンツも自分で保存する時代ではなく、定額サービスなどに加入して視聴するのが一般的なのだろうが…。

---

謎が深い…

fgo福袋が爆死 & やたら重かったので、バンディング低減のAVX512版を作ってみようとしたのだけど…

VC++2017の出力が謎…。

続きを読む

続きを閉じる

とりあえず、こんなコードがあったとします。

int main(int argc, char **argv) {
    alignas(64) int16_t a[32];
    alignas(64) int16_t b[32];

    //適当に初期化
    for (int i = 0; i < 32; i++) {
        a[i] = rand() % INT16_MAX;
        b[i] = rand() % INT16_MAX;
    }
    //ロード
    __m512i z0 = _mm512_load_si512((__m512i *)(a));
    __m512i z1 = _mm512_load_si512((__m512i *)(b));

    //マスクを作るよ
    __mmask32 mBlend = _mm512_cmpgt_epi16_mask(z0, z1);

    //マスクを使うよ
    __m512i z2 = _mm512_mask_mov_epi16(z0, mBlend, z1);

    _mm512_storeu_si512((__m512i*)a, z2);

    //最適化で全体が消されないようになんか出力しとく
    printf("%d\n", a[0]);

    return 0;
}

まあ、マスクを使いたいだけの簡単なコード…のはず。

これをVC++2017 (15.5.2)で32bitプログラムとしてコンパイルして、逆アセンブラのAVX512部分をみるとこんな感じになる…。

vmovdqa32 zmm0, ZMMWORD PTR _b$[esp+256]
vmovdqa32 zmm1, ZMMWORD PTR _a$[esp+256]

vpcmpw    k1, zmm1, zmm0, 6
kmovd    eax, k1
kmovd    k1, eax
vmovdqu16 zmm1 {k1}, zmm0

vmovdqu32 zmm0, zmm1
vmovd    eax, xmm0

この5行目と6行目はなんぞ? なぜ汎用レジスタに移して戻したし。
あと9行目も何がしたいのやら…。

一応、Function compile flags: /Ogtpyとなっているので、最適化はかかっているはず。

ちなみにg++(7.2.0) -O3 -mavx512f -mavx512bw -S -masm=intelだと、

vmovdqa64    zmm1, ZMMWORD PTR [esp+80]
mov    DWORD PTR [esp], OFFSET FLAT:LC0
vmovdqa64    zmm0, ZMMWORD PTR [esp+16]
vpcmpgtw    k1, zmm0, zmm1
vmovdqu16    zmm0{k1}, zmm1
vpextrw    eax, xmm0, 0

やっぱいらないよねえ…。

決して間違った結果にはならないし、完璧に最適化しろというわけではないけど、さすがにもう少しうまくやってほしい…。それともなにか見落としているのだろうか?

うーん。どうしたものか。あまり気にしなくてもいいのかなあ…。

2017年を振り返る (PC編)

そろそろ2017年も終わりそうなので、今年も振り返ってみる。

PC関係ないとこでは腸炎になってお腹痛かった…(もう治った)。まあ、あれでも細菌性のやつではないらしいので、まだましなほうのようだ。ひえええ。

続きを読む

続きを閉じる

---

CPU ～メニーコア～

---

今年はしばらく続いたCPUの停滞からは打って変わって、すごくCPUが面白い年だった。そのせいで、いまだかつてなくPCを自作しまくった気がする。

そもそもはRyzenからはじまって、その予想以上の性能とコスパで一気にメニーコア競争が進んだ感じがある。さすがにシングルスレッドが辛い(もうなんか体感ではっきりわかるレベル)性能だったBulldozer系列から比べると、ほんとに素晴らしいCPUになってるなあ、と思う。

アキバの2017年10大ニュース投票結果発表 → Ryzenが1位
復活のAMD、Ryzenシリーズが大ヒットしてPCパーツ市場を牽引

Ryzenは当初はBIOSの設定などに癖があって慣れるまで大変だったけど、いまはそんなでもない感じ。ただまあ、R7 1700だとやっぱりどうしてもオーバークロックしにくいので、オーバークロックするならやっぱりR7 1800Xを買うべきで、R7 1700はどちらかというと定格から電圧を少し下げて省電力で使うみたいなのに向いている気がする。

性能はお値段のわりに抜群で、x265はともかく、x264ははやい。

Ryzen7 1700で組んでみた
Ryzen7 1700 ベンチマーク
Ryzenの得意あるいは不得意
Ryzen7 1700 オーバークロック
Asrock AB350 Pro4のBIOS その2
Ryzen7 1700のメモリ速度 (修正・追記)
Ryzen/Haswell/KabylakeでのSMT(HTT)の効果

そのあと、AMDがThreadRipper(16コア)をぶち上げたので、Intelが慌ててSkylake-Xで18コアを投入する、ということになって、さらに面白くなった。いままでやらんかっただけで、やはり本気になれば商品化できるらしい。

というわけで、7980XEを買ってしまったのだが、なかなか勇気のいるお値段だった。ただ、さすがお高いだけはあって、処理性能は抜群で非常に快適。もちろん、(冬は)お部屋もあったかくて快適。夏は…まあ、考えないでおこう。

7900Xが出たときはグリスのせいで熱いというのが結構問題になっていたので、かなり冷却に気を使った装備を用意してみた。ただ、ふたを開けてみると、7980XEはダイが大きいせいか、そこまで警戒しなくてもよかったかなあ、という感じ。

冬に備えて暖房器具を…
i9 7980XE まったり オーバークロック
i9 7980XE 3.6GHz ベンチマーク
i9 7980XE オーバークロック ベンチマーク
7980XEのキャッシュ/メモリ帯域

ただ、x265とかでもいい感じの速度が出るので、これを使っていると「やっぱりHWエンコードなんてやめてCPUをぶん回すのが一番だぜ」などという危険な思想に陥りがち。
　↓
HWエンコ関連の更新のモチベが下がる下がる…。
　↓
ちょっとfgo始める。
　↓
ますます更新しない (いまここ)

---

ハイエンドのほうだけじゃなくて、メインストリームも多コア化が一気に進んだ一年だったのかなと思う。Core2Quad以来、ずっと4コアのままだったのだけど、やっとのことでCoffeelakeでメインストリームでも6コアが出たし、ノート向けCPUも4コア化が進んできている。

Ryzen8コアの投入で、これまで停滞感のあったCPUというジャンルがかなり盛り上がったと思うし、来年もこの調子で性能の向上が続くと期待したい。

まあでもIntelは10nmがよくなるまでいまの感じでやや迷走気味になってしまうんだろうか…。来年、無事Cannonlake/Icelakeが出るとよいのだが…。多コア化の一方で、シングルスレッド性能も確保するためかTurboBoost幅がどんどん広がって、広がりすぎたせいで、もはや「定格ってなんだっけ」…な感じも出てきている。

---

GPU

---

NVIDIA Volta…は出なかった。正確にはV100は出たけど、あれはDeep Learning用で一般向けじゃないでしょう…。GTX20xxはどこへ…。

AMD Vegaはなんか無理にクロックを引き上げた結果、熱いらしく、プロファイルを切り替えるとよい感じになるらしい。

というかPascal系のクロックの高さはこれまでのGPUクロックを考えると異常。高クロックと低消費電力を両立できているのが、Pascalのすごいところだと思う。

変わったところでは、Kraken G12でGPUの簡易水冷化というのを試してみた。意外と大きく温度が下がってさすがにびっくり。リスクも大きめとはいえ、ここまで効果があるとは…。

---

メモリ・ディスク

---

メモリ高すぎでしょう…。以前買ったものの使いまわしでしのぐしか…。

SSDは今年でだいぶNVMeが一般的になってきたのかなあ、という印象。もちろん、PCIe接続だと性能が高くてよいというのもあるのだけど、地味にSATAケーブル引き回さなくていい、というのが便利な気がする。

HDDは順調に安くなっていて、容量も12TBが発売されるなど良い感じで伸びている。

ディスクもあんまり増えすぎたので整理。だいぶ集約して減らすことができた。

HDDの整理

---

その他

---

ちょっと変わったケースを買ってみたり、4Kモニタを買ってみたりとなかなか面白い1年だった。

Phanteks Evolv Shift X レビュー
Phanteks Evolv Shift X レビュー その2

LG 32UD59-B (4Kモニタ)を買った

4Kモニタは、グレアじゃない点を除けば(しつこい…)、かなり満足で、高精細さというのもあるけど、それよりもデュアルモニタと違って中央に枠が入らないこと、なによりも作業領域が広がることが非常に快適。多少視線移動が多いかな、という気もするけど、苦にならないレベルで、買ってよかったかなと思う。

---

2018年は?

---

ざっと思いつくところだとこんな感じ?

でもまあ、ロードマップとかがだいぶ不安定になってきていて、正直もうよくわからん…

・[Intel CPU] モバイル向けにはCannnonlake、デスクトップはCoffeelake Refresh? 8コア化来る? Kabylake-Gにちょっと期待。
・[AMD CPU] Zen2来る? Zen + VegaなAPUにも期待。
・[NV GPU] Volta版GPU(ようはGTX20xx)が見えてこない…さすがに今年は来るんだよね?
・[AMD GPU] Vega10のサイズダウン版、Vega11来る?
・[DRAM] まだまだ値上がり?
・[SSD] 大容量化…するのはいんだけど容量単価が…。
・[HDD] 16TBはよ。

---

あ、ちなみに今年はx265ベンチマークはやりません。

---

2016年
2015年
2014年
2013年

---

AWS c5インスタンス (Skylake Xeon) 姫野ベンチほか

ここ最近は7980XEでベンチマークをして遊んでいたのだけど(↓)、
7980XE メモリ/キャッシュベンチマーク
7980XEベンチマーク

面白そうなAWS情報を耳にした。

どうやらAWSにc5インスタンスなるものが入り、これはSkylake Xeonなのだということなので、ついでに簡単にベンチマークしてみた。

続きを読む

続きを閉じる

---

比較対象 (全部オレゴン)

インスタンス名	c5.9xlarge	c4.8xlarge	c3.8xlarge
CPU	Platinum 8124M x1	E5-2666 v3 x2	E5-2680 v2 x2
CPU Gen	Skylake-EP	Haswell	IvyBridge
コア数	18C/36T x1	9C/18T x2	8C/16T x2
定格クロック	3.0	2.9	2.8
Uncore/Meshクロック	?	?	?
メモリ速度	?	?	?
OS	Ubuntu 17.10

注意しないといけないのは、各インスタンスでコア数はほぼ同じなものの、ソケット数が異なるという点。c5.9xlargeだけは1ソケット、他は2ソケットという構成で、このあたりはメモリ帯域に効いてくると思われる。

ほんとはWindowsでやりたかったのだけど、Linux使ってるのは、WindowsだとAWSの価格が高いため。でもCinebenchもやってみたかった気もする。

使用ソフトウェア
いつものメモリ速度測るやつ (AVX512対応)
y-cruncher 0.7.4 Linux版
himenoベンチ 改造版 (OpenMP/C言語/dynamic alloc/gcc7ビルド/SSE/AVX2/AVX512)

---

y-cruncher 0.7.4 Linux版

---

まず演算速度を見るということでy-cruncher。



AVX-512対応なので、もうc5.9xlarge(SKX)が圧倒的だ。とはいえ、単純にc4.8xlarge(HSW)の2倍にはならない。これは、やはりAVX512に乗せたからと言って2倍にはならないということを意味する。

一方、c3→c4はコア数の増加もあって2倍以上速い。

---

ram_speed

---

じゃあメモリ帯域は? ということでいつものベンチマーク。

まずはシングルスレッド版。



L1の帯域が、各世代で倍増してきたのがはっきりと見て取れる。Skylake-EPでのL2強化を反映して、c5.9xlargeのL2も恐ろしい速さ。

ところが、c5.9xlargeのL3は最下位に沈む…ということでまあ、7980XEでもみたのと同じ傾向が見える。(意外とそれでもベンチマークの性能はよい不思議)

次にマルチスレッド版。



シングルスレッド版とほぼ同じ傾向。c5.9xlargeはL1/L2の帯域は圧倒的だ。

スレッド数を変えた時のメモリ帯域。



c3.8xlrageとc4.8xlargeは階段状になっている。これは、c3の9スレッド目/c4の10スレッド目から、2つ目のソケットが使われ始めるから。一方、c5.9xlargeは1ソケットであるため、こうした階段はない。

c5.9xlargeは1ソケットのため、2ソケット分のメモリ帯域を使えるc3やc4と比べ不利なはずだが、c3 x2ソケットとほぼ同等、c4 x2ソケットと比べてもちょい勝負ができていて、なかなかすさまじい。

ただまあ、DDR4-2666 6chとすると理論帯域は128GB/sで、それと比べると実効帯域は少し低いのかなあ、という気がする。VMのオーバーヘッドもあるのだろうか?

---

姫野ベンチ Lサイズ
改造版 (OpenMP/C言語/dynamic allocation/gcc7ビルド/SSE/AVX2/AVX512)

---

では最後に姫野ベンチ(Lサイズ)。

まあ、これも要するにメモリベンチなんだけど…。



c5.9xlargeは8～9スレッドぐらいまで圧倒的な速度だが、そのあと伸びない。これはメモリ帯域をこのあたりで使い切ってしまったなのだと思う。

一方、c3.8xlargeやc4.8xlargeは8スレッドぐらいまではSkylakeとの差がかなりおいていかれているが、12スレッドぐらいからは2ソケット目を使い始めるので、これにより2ソケット目のメモリ帯域も使用可能になり速度が伸びていき、c5.9xlargeを最終的に上回る結果に。

まあ、多コアCPUはコア当たりのメモリ帯域がどうしても低くなってしまうので、その弱点が見えてくるベンチマークだと思う。

---

というわけで、どちらかとというメモリ系のベンチマークが多くなってしまったけど、c5.9xlargeは1ソケットにもかかわらず、2ソケットのc3.8xlargeやc4.8xlargeと互角に戦えていて、さすがの性能だと思う。

ちょっと使えなかったのだけど、c5.18xlargeとかを使えば、もっと恐ろしい速度に…。(まあお値段もその分…)

にしても、海の向こうのサーバでVMを簡単に立ち上げて、こうしたベンチマークがさくっとできるのは、まあ、なかなかすごい時代になったものだと思う。

---