Intel & AMD CPU コア数別ラインナップ比較

CPU のコア数が増えすぎて訳が分からなくなってきたので、デスクトップ向け CPU について少し整理してみたメモ。8 コア以上の CPU を整理。サーバー向け(Xeon/EPYC)や数量限定品(9900KS)は除外している。

価格については、相場月報 2019/10 版を参照している(記載の無いものは初出価格)。

HEDT(ハイエンドデスクトップ)向け

HEDT


HEDT 向けは AMD の圧勝。

24 コア以上は Intel のラインナップが無い。14 コア以下は AMD はメインストリーム向けで十分にカバーできてしまっている。

HEDT 向けで Intel の唯一の存在感は、AMD のラインナップの隙間となっている 18 コア品。

メインストリーム向け

Main


メインストリーム向けのうち、上位の布陣も AMD の勝利。

12 コア以上について AMD がしっかりラインナップしているのに対し、Intel は HEDT 向けのラインナップになってしまっているので、マザーボード等を含め価格がかなり高く付く。

メインストリーム向けのうち、8 コアは良い勝負。

8 コア 16 スレッド品は、価格の絶対値では AMD が安いが、Intel はオンボードグラフィックスを搭載している。Intel のオンボードグラフィックスに相当する外付けグラフィックスは数千円程度のため、グラフィックス込みでも価格面では AMD が優位だが、Intel のほうが TDP を抑えられる。

また、どうせグラフィックスを外付けするならある程度の性能を持つものを、と考えると、価格が 1 万円以上上乗せとなるので(もちろん性能も圧倒的だが)、悩ましい選択となる。

8 コア 8 スレッドについては Intel のみのラインナップとなる。AMD は、6 コア 12 スレッドの Ryzen 5 がカバーする領域となる。

ニコカラメーカー 2 の開発に着手

カラオケ用の字幕を動画に焼き付けるソフト「ニコカラメーカー」の後継ソフトの開発に着手。名称はシンプルに「ニコカラメーカー 2」となる予定。

初代ニコカラメーカーの特徴としては
  • プレビューで出来映えを確認しながらビジュアルに字幕を作成
  • 字幕自動配置で簡単作成
  • 多段グラデーションなど多彩な文字飾り
  • パート分け時などに分かりやすい絵文字(アイコン)機能
などが挙げられる。ニコカラメーカー 2 も引き続きこれらの特徴を受け継ぎつつ、さらに以下を目指す予定。
  • 字幕アクション機能(フェードや走り込みなど)
  • 文字飾りの強化(ブラーや画像ブラシなど)
  • 文字単位でのフォント指定における利便性向上
  • レイアウト指定における利便性向上
  • 最新の環境での動作性向上
  • 処理の高速化
字幕に動きを与える字幕アクション機能はリクエストを多く頂いていた機能。中でも、フェードイン・フェードアウトは要望の多かったため、優先的に実現したい。今までどうしてもフェードさせたい場合は、ニコカラメーカーで連番 PNG で出力した後に、動画編集ソフトでフェードさせる必要があったが、ニコカラメーカー 2 のみで作業が完結するようになる。

文字飾りのうち、ブラーもリクエストを多く頂いていた機能。こちらも優先的に実現したい。

文字単位でのフォント指定(行の途中での色替えなど)はニコカラメーカーでも行えるが、やや手順が煩雑であった。ニコカラメーカー 2 では簡単にフォント指定ができるようにしたい。

レイアウト指定では、これまでよりもさらに手軽にバリエーション豊かなレイアウトを提供する他、パート分けも今までよりも簡単にしたい。

最新の環境での動作性向上は、Windows 10 での動作可能性を高める。Windows 10 でニコカラメーカーを使うと、2 つ起動しないとプレビューできない場合があるなど、新しめの環境での動作可能性が少し低かったが、ニコカラメーカー 2 では改善したい。

処理の高速化は、マルチスレッドに対応する。ニコカラメーカーは動画出力などをシングルスレッドで行っていたため、最近の CPU の性能を活かし切れていないが、ニコカラメーカー 2 では改善したい。

いずれも難易度が高いため、すべてを実現できるかはまだ分からないが、一歩ずつ開発を進めていきたい。来年中にはある程度のリリースをしたいと考えている。

C# 8.0 の null 安全はいろんな意味で革命だった

null 安全とは

「イマドキのプログラミングは null 安全がトレンドらしい」(参考記事:null 安全でない言語は、もはやレガシー言語だ)ということで、null 安全初心者が null 安全なコードを書いてみた。

そもそも null 安全とは、「null 参照例外(NullReferenceException)が発生しえるコードをコンパイル時にエラーにしてくれる」仕組み。つまり、コンパイルが通った時点で null 参照例外は起こりえないということになる。革命的に素晴らしいのでは?

C# においては、最新の言語バージョン 8.0 で「null 許容参照型」が導入され、これを使うと null 安全になる。

「null 許容参照型」という名前を聞いて、「参照型なんだから null が許容されるのは当たり前じゃないか」と思ったのだが、その常識が覆る。null 許容参照型を導入することにより、「普通の参照型には null を代入できなくなる」。つまり、C# という言語レベルで過去との互換性が失われる! 革命的に影響が大きい。

あまりにも影響が大きいので C# 8.0 では null 許容参照型はオプション扱いとなり、かなり限定的な環境でないと有効にならない。Visual Studio 16.3 の時点では、プラットフォームを .NET Core にしたうえで(.NET Framework でも一部機能は使えるらしい)、プロジェクトファイルを直接編集して null 許容参照型(Nullable)を有効にして、かつ、関連する警告をエラー扱いにする(参考記事:null 許容参照型)。

コード例

今までの C# のコード
String str = null;
String low = str.ToLower();
があったとして、ここまでシンプルであれば NullReferenceException を予見してコードを修正できるが、str の初期化がどこでされてるか分かりづらい場合は見逃してしまって NullReferenceException が発生するという事態に陥る。

しかし、null 許容参照型を有効にすると「普通の参照型には null を代入できなくなる」ので、str = null の時点でコンパイルエラーとなる。従って、
String str = "HOGE";
String low = str.ToLower();
のようなコードに修正せざるを得なくなり、NullReferenceException が発生しない安全なコードになる。これが null 安全か!

とはいえ、「str が null になることもある」という場合に、null 許容参照型を使う。型名の後ろに「?」を付けるだけだ(null 許容値型と使い勝手は似ている)。
String? str = null;
String? low = str?.ToLower();
str?.ToLower() の部分は、str が null であれば null が返り、null でない場合のみ ToLower() が実行されるので、NullReferenceException が発生しない。str が null の時は low も null になるので、low も null 許容参照型にする必要がある。? を忘れるコンパイルエラーになるので、やはり NullReferenceException は発生しない。null 安全すごい。

いくつかコードを書いてみた感想

null 許容参照型を有効にすると、変数が null になり得るのか否かを常に意識するようになる(というか、不適切なコードはコンパイルエラーになるので意識せざるを得ない)。

特にクラスメンバーを null 許容にしなかった場合は、コンストラクターでの初期化が必要となるので、「null 許容があるべき姿なのかどうか」をしっかり考えて選択するようになった。

関数の書き方も変わってくる。

Boolean TryParse (String s, out Hoge? result) のような関数は、返値が true の場合は result は null にはならず、それをコンパイラに教えるためには [NotNullWhen(true)] のように属性を指定する。が、そんな面倒なことをするくらいなら Hoge? TryParse(String s) のような形式に変更するほうがいいと思う。

また、型キャストの際に as 演算子を使うとキャストできなかった場合に null が返ってきてしまうので、if 文の中で is 演算子を使うスタイルに変わってきた。
private void Func(Object? sender)
{
    if (sender is UIElement element)
    {
        element.AllowDrop = true;
    }
}
sender が null ではなく、かつキャストできる場合のみ element に代入されるため、element は null 非許容となり、element のプロパティーにアクセスする際に ? は不要。

一方で、NullReferenceException にならない安全な世界ではあるものの、使い方を間違えるとエラーが埋もれるだけのより深刻な状況にもなりかねない。

呼ばれること自体に意味があるような関数、例えばユーザーへの警告表示で、null 安全ではない世界であれば、
hoge.ShowWarning();
で hoge が null の場合は例外が発生してマズいことになったのが表面化するが、null 安全な世界だと
hoge?.ShowWarning();
のようなコードとなり、例外は発生しないが、ユーザーに警告が表示されず、しかも表示されないままスルーされて問題が埋もれてしまう。

革命は 1 日にして成らず

null 安全は C# にとってあまりにも影響が大きく、ライブラリやコンパイラの対応もまだ発展途上のようだ。

例えば、メンバー変数をコンストラクターで初期化する際、コンストラクターから関数を呼びだしてそこで初期化していても、初期化していないと判定されてしまう。

また、
String[] strs = new String[3];
はコンパイルが通ってしまうが、実際には String[0] などは null であり、本来であればコンパイルエラーにしなければならないコードだ。

環境が整うまでにはまだまだ時間がかかりそうである。

とはいえ、null 安全は非常に素晴らしい仕組みだと思うので、少なくとも今後新規作成するプロジェクトでは積極的に使っていきたいと思う。

気になったこと

マルチスレッドで null 許容参照型にアクセスするとどうなるんだろうか。

想像だが、str?.ToLower() のようなコードはコンパイル時に

if (str != null)
{
    str.ToLower();
}
のように解釈されるのではないだろうか。だとすると、str が null ではないと判定した直後に別のスレッドが str を null にしたら、ToLower() 呼出の際に NullReferenceException が発生してしまわないだろうか。

ところで、Nullable の読み方って「ぬらぶる」?

1 ヶ月時点の SSD 書き込み量

新パソコンを使い始めて 1 ヶ月。各 SSD の現時点での総書込量を記録しておく。

cdm_c_presentC ドライブは 1644 GB。

300 TBW のディスクなので、15 年使える計算。

cdm_d_nanatunatuD ドライブは 1795 GB。

400 TBW のディスクなので、18 年使える計算。

cdm_e_bikiniE ドライブは 1752 GB。

400 TBW のディスクなので、19 年使える計算。

いずれもパソコン買い換えサイクルよりも長かったので一安心。

ついでに、USB 外付け HDD も CrystalDiskInfo しておく。

cdm_f_maruF ドライブは RAID ユニットで、ディスク交換したため使用時間が 14 時間に戻っている。元々は 36,222 時間だったので、ユニット全体の使用時間はプラス 36,000 時間程度。

cdm_u_kimonoU ドライブはポータブル HDD。9846 時間使用。


My Book Duo の HDD を交換

異常発生

hdd_death24 年ほど前に購入した USB 3.0 外付け HDD ユニット「My Book Duo」(型番:WDBLWE0080JCH-JESN、4TB+4TB = 8TB)に不穏な赤ランプが点灯。電源ランプが赤く点滅するととともに、HDD 1 のランプも赤い。

led付属のマニュアルを確認するとやはり、残念ながら 1 つ目の HDD がお亡くなりになっているとのこと。

degrade専用ユーティリティ(WD Drive Utilities)を起動して確認すると、明確に故障と表示された。

crystaldiskinfoRAID 1 で運用しているため、片方の HDD が死んでもユニット全体としては問題なく使用できるからか、CrystalDiskInfo では正常と表示される。

また、ユニットの電源をいったんオフにしたところ、赤ランプの表示は出なくなってしまったが、専用ユーティリティで簡易チェックすると不合格となった。

HDD 調達

wdredMy Book Duo で使用されている HDD は WD Red シリーズなので、順当に行くなら交換用の新 HDD も WD Red で揃えるのが良さそう。

ところが Western Digital の公式サイトを確認すると、WD Red に 4TB のラインナップが無い(WD Red Pro にはあるが)。しかも「NAS 向け」の位置づけになっているのでターゲットがちょっと違う。

秋葉原にはまだ WD Red の 4TB は売っていて(恐らく少し古いモデル?)、価格は税込で約 15,000 円。

wdblue正統な後継が無いことや、そのうち HDD ユニット自体を(もっと容量の多いものに)買い換える可能性も考慮し、かつ、価格面も加味して、デスクトップ向けモデルの WD Blue を購入。ドスパラにて、4TB で税込 7,810 円。キャッシュレス支払い(クレジットカード)で即時割り引き 5% となり、7,420 円まで下がった。



HDD 交換

マニュアルに従って HDD を交換。

上部カバーを開いた後、手で回せるネジで留められている内側の網を外す。

open2マニュアルで「タブ」と表記されているペラペラの持ち手を使って HDD を引き上げる。

新しい HDD にタブを取り付けてからユニットに差し込む。

RAID 再構築

新品の HDD1 と、生き残っていてデータもある HDD2 の内容が不整合になっているので、PC に接続するとその旨の警告が表示される(この状態でも PC からは正常な HDD として利用可能)。

fukugen専用ユーティリティで RAID の状況を確認すると、HDD1 が新品であることをきちんと認識してくれている。

fukugen2復元ボタンをクリックすると、生き残っている HDD2 から新品の HDD1 へのデータコピーが始まる。

RAID の再構築にはかなり時間がかかり、6 時間半経過時点で進捗は 74%。完了までに 9 時間近くかかる計算。

fukugen6翌日起床した際には、無事に再構築が完了し、RAID 1 本来の状態での稼働となっていた。

cdm_f_maruCrystalDiskInfo では HDD 1 の情報が表示されるようで、交換後は電源投入回数・使用時間が新品のデータになっている(交換前は電源投入 256 回、使用時間 36,222 時間)。











カウンター


カンパのお願い
Amazon でお買い物の際は、下記で検索して頂けたら幸いです。
記事検索
最新コメント
  • ライブドアブログ