SkyDriveがどこまで同期しているかをチェックするツールを作りたい

投稿日: 2013/03/09 作成者: masuda

とか思って、ざっと調べてメモ的に。

第48回　SkyDrive API 概要（1）：使ってみよう！ Windows Live SDK/API｜gihyo.jp … 技術評論社 http://bit.ly/15BP39B
SkyDrive API (Live Connect) http://msdn.microsoft.com/ja-jp/library/live/hh826521.aspx …
JSON形式をC#のオブジェクトにシリアライズ・デシリアライズする – かずきのBlog@Hatena http://d.hatena.ne.jp/okazuki/20101217/1292600928 …
.NET FrameworkでJSONデータを処理する （2/4）：CodeZine http://codezine.jp/article/detail/5868?p=2 …

ツール自体は、旧来のフォームアプリで作るのだが、直接のサンプルはない…というか、REST API で ok。どうせなので HttpClient を使って非同期にする。

Twitter のアプリと同じく、アプリケーション設定サイト でアプリを登録する。そうすると、クライアント ID が得られる。

ユーザーにクライアント ID を使ってアクセストークンを得る。アクセストークンは一定期間は使いまわせるらしい。Twitter の場合と違って、しばらく時間が経つと消えてしまっている気がする。

フォルダ、ファイルの情報は、JSON で得られるので、DataContractJsonSerializer を使ってデシリアライズする。

そこで、ここまで動くことを確認済み。

image

こんな感じでファイルとフォルダを取得できる。

■SkyDrive を使って相手にファイルを送る

ローカルのフォルダに置いて、すぐに相手に知らせると、まだ　SkyDrive にあがっていない。なので、しばらく経つと自動的に同期をとるので、そのときにダウンロードして貰えばいいのだが、「いつ同期が完了するのか？」がわからない。なので、

  • ファイルがアップロードされてるか定期的にチェック＆表示

が必要。新規の場合は、SkyDrive にファイルがないので、ローカルのフォルダと比較するとわかる。更新の場合は、ファイルの更新時刻 updated_time がわかるので、これを比較する。削除の場合は、あまり関係ない。

ってのを作れば ok

カテゴリー: ツール | SkyDriveがどこまで同期しているかをチェックするツールを作りたい はコメントを受け付けていません

[C#] UNIX 通算秒を DateTime に直す

投稿日: 2013/03/08 作成者: masuda

と、本ブログのアクセス解析しようと思って WP SlimStat のデータを抜き出している途中で、気が付いたネタをひとつ。

WP SlimStat の日付データは unsigned int で保存されていて、通算秒になっています。なので、日付で集計したいときには、UNIX 通算秒から C# の DateTime に直さないといけないのですが、はて、そんな関数ってあったっけ？と結構 google で検索しました。 

uint ut ; // UNIX 通算秒
DaiteTime dt = new DateTime(1970, 1, 1).AddSeconds((double)ut);

ああ、そうすね。AddSeconds メソッドを使えば一発です。
逆向きもメモ的に書いておきます。DateTime を UNIX 通算秒に変換します。 

DateTime dt ;
uint ut = (uint)(int)(.dt.Ticks - new DateTime(1970, 1, 1).Ticks) / 10000000;

最終的にやりたいことは、WP SlimStat のグラフを iPhone で見ることなので、サーバー系は PHP で書くことになりそうなのですが、手始めに C# を使って解析ということで。


こんな風に Chart を使うと簡単にグラフ化できます。PHP の場合は HTML5 で出力する予定。

カテゴリー: C# | [C#] UNIX 通算秒を DateTime に直す はコメントを受け付けていません

最強.NET開発PCを作るよ（その６）

投稿日: 2013/03/06 作成者: masuda

最強.NET開発PCを作るよ（その１） はじめに
最強.NET開発PCを作るよ（その２） メモリ編
最強.NET開発PCを作るよ（その３） CPU編
最強.NET開発PCを作るよ（その４） ストレージ編
最強.NET開発PCを作るよ（その５） マザーボード編

の続き

image

時代はデュアルモニタ（マルチモニタ）ってことで、グラフィックボードを購入します。3D ゲームを全然やらないので、グラフィックボードに関しても私は素人です。なので、ZOTAC GeForce GTX 650 2GB がどれだけ高速なのか？ってのも猫に小判状態なのですが、 シミュレーターの中でマインスイーパーが動く程度に高速です。シミュレーターが GPU  を使っているかどうかが不明なので、高速な CPU のおかげかもしれないのですが。

image

さて、3D モデリング、CAD 関係、絵師、Web デザイナ、ゲーム制作などなど、とグラフィックボードの性能を引き出す仕事はたくさんあるのですが、ひとまず、Visual Studio 2012 で Windows ストア アプリを組むときに、グラフィックボード、GPU はどこにかかわってくるのか？ということを考えると、

  • Blend で XAML のデザイン環境
  • Visual Studio 2012 の XAML デザイナ？
  • Storyboard を使ったアニメーション
  • C++/CX、DirectX による画面コンポーネント開発

に関わってきます。C++/CX による画像系のコンポーネント開発は、Windows ストア アプリで直接 DirectX を扱うことができるので今後広まると思われる分野です（私的には広まって欲しい分野でもありますね）。DirectX の場合、DirectX 9 から 11 までのバージョンによってコーディングが変わってしまうのですが、Windows ストア アプリの場合、インターフェースが揃えてあるのでWindows ストア アプリの範囲内であればあれこれとバージョンに悩む必要がありません。ってことになっています。なので、今後の Windows 8 PC では、この手の DirectX 関係が入っているのが「当然」になるので、アプリにインストール時にあれこれと悩む必要がなくなるかなと。この話は、また別の機会に。

■Blend での編集

Visual Studio 2012 では、XAML のアニメーションを Flash のように作れます…といいますか、Flash のほうは作ったことがないので、XAML のアニメーション制作環境として Blend がどれだけチープなのか（リッチなのか）はわからないのですが。非力な CPU/GPU の環境だと Blend はかなり重たいです。

image

タスクマネージャで見るとわかるのですが、Blend で XAML をデザインしようとすると、2つのプロセスが動いています。

  • Blend for Visual Studio 2012
  • Blend for Microsoft Visual Studio 2012 XAML UI Designer

image

Blend for Visual Studio 2012 は、Blend 本体のプロセスで、Blend for Microsoft Visual Studio 2012 XAML UI Designer は、XAML をデザインするところのプロセスです。デザイナの部分だけが別プロセスになっているのは、実は Visual Studio 2012 本体でも同じです。

■GPU が働いているか確認する

Process Explorer を使うと、GPU が働いているかどうかを確認できます。

image

確実に GPU 上で動いているであろうマインスイーパーを動かすと、こんな感じで GPU が動いていることがわかります。Comit 量も多いので、グラフィックボードを入れる価値があった、ってところですね。グラフィックがオンボードの場合は、どうなるのか確認していませんが…、ひとまず、GPU がMinesweeper.exe では使われていることが確認できます。ええ、所詮マインスイーパーなんですが（苦笑）。

image

Process Explorer で Blend 本体と XAML デザイナのプロセスを見ていきます。左が Blend 本体（Blend.exe）、右が XAML デザイナ（XDesProc.exe）です。Visual Studio 2012 を動かしていると、XDesProc.exe が複数起動しているので、ここでは Blend から起動されたものを選択します。

image

どちらも GPU をマインスイーパーほどではありませんが、それなりに使っています。画面キャプチャを撮るときに storyboard でアニメーションを開始/終了を繰り返すと、ちょっとだけ XAML デザイナが GPU を使うようになります。ちょっとだけ…なので、あまり GPU の恩恵にあずかっているわけではないのですが。まあ、それなりに。ちなみに、Blend のメニューなどをいじると、今度は Blend 本体の GPU が使われます。

image

Visual Studio 2012 本体と、XAML デザイナの関係も同じで、ぐりぐりと XAML デザイナで編集しているときには GPU を使っています。また、Visual Studio 2012 本体のメニューをいじっているときは、本体側の GPU が使われます。

ちなみに、アニメーションを使った Windows ストア アプリを実行した場合は、ちょっとだけ GPU が使われます。まあ、XAML を使った簡単なアニメーションなので、あまり CPU/GPU に負荷をかけていないからですね。このあたりは、負荷をかけるような storyboard を作って後で確認してみましょう。

image

image

ちなみに、GPU を全く使っていない QX エディタはこんな感じになります。エディタの場合は、GPU を使わなくてもいいので、エディタを使ってプログラミングをしているときは、全くの無駄ってことですね（苦笑）。

image

■XAML デザインにグラフィックボードが効いてくる

グラフィックがオンボードの PC の場合、XAML デザイナが妙に重くて変だなぁと思っていたのですが、これで問題が解消できそうです。ひとまず、安めの PC でもグラフィックボードを入れれば、Windows ストア アプリの XAML デザイナのところで有効活用できそうです。ただ、実際には、Visual Studio 2012 本体や Blend 本体との連携が必要になるので、そこそこの CPU 性能とメモリは必要になってくるでしょうが。

それと、XAML のアニメーションを使ったアプリの場合にも、通常の状態で GPU をきっちり使ってくれています。なので、ターゲットの PC にそれなりのグラフィックボードが入っていれば、C++/CX で DirectX を弄らなくても、C#/VB の範囲で XAML の storyboard を使えばそこそこの性能がでるのでは？という予想が立ちます。そのあたりは、別途ベンチマーク用のツールを作って確認していきましょう。

カテゴリー: パフォーマンス, 最強.NET開発PC | 1件のコメント

最強.NET開発PCを作るよ（その５）

投稿日: 2013/03/05 作成者: masuda

最強.NET開発PCを作るよ（その１） はじめに
最強.NET開発PCを作るよ（その２） メモリ編
最強.NET開発PCを作るよ（その３） CPU編
最強.NET開発PCを作るよ（その４） ストレージ編

の続き

image

メモリ 64GB、CPU Intel i7-3820、SSD 512GB、HDD 2TBx2 の構成で組むことを決定した後は、それを乗せるマザーボードの選定です。

正直、私自身はマザーボードには詳しくなくて（他のパーツも詳しい訳ではないのですが）、どのマザーボードが適しているかどうか、逆に言えば適していないかどうかは、両氏に考えていただきました。オーバークロックをやるわけではなく、ハードな3Dゲームをやりたいわけでもないので、オーソドックスな感じで上記の、メモリ、CPU、ストレージが乗せられれば ok なので、買ってきた X79 Extreame 9 の性能がどのくらいのものなのか、さっぱりわかりません（苦笑）。なので、選定基準はあとから詳しく聞いて記事にするということで、ここではざっと私の視点から見たものを挙げておきます。

メモリスロットルが8つということで、X79 のほうを購入した訳ですが、他のポイントとしては、SATA3 が 8 本あること、BIOS インターフェースが UEFI であることですかね。

UEFI を使って起動時を高速化する方法は、

UEFI ファームウェアへの Windows の展開の概要
http://technet.microsoft.com/ja-jp/library/hh825095.aspx
【清水理史の「イニシャルB」】 Windows 8を覚醒させるUEFIチューニング～電源オンから5秒以内に起動するPCを実現する -INTERNET Watch
http://internet.watch.impress.co.jp/docs/column/shimizu/20121002_563382.html

あたりを参考にすればよいでしょう。私の場合、それほど起動時間を気にしないほうなので（普段はスリープからの復帰）、これはこのままにしておきます。

SATA3 の本数のほうは、開発機とはいえ HDD を拡張することが前提（ユーザー領域、データベース領域、VM 領域など）なので、できるだけ拡張性が高いほうが良かろうというところです。PCI は、グラフィックボードを乗せるぐらいなので、あまり多くなくて大丈夫です。

今気づいたのですが、LAN ボードをデュアルで乗せることができるので、LAN ケーブルを２本差して転送を高速化することができるんですね。なるほど。このあたりはあとで試してみます。

■グラフィック BIOS, UEFI

グラフィック BIOS は、こんな画面が立ち上がります。やれることは、普通の BIOS と同じ（なのかな？）なのですが、マウスが使えるので設定が簡単にできます。

image

再起動の直後で、CPU 温度が 45.0 度なので水冷クーラーが効いているのかと思います。

image

ちなみに、このボードはファンのスピードが変えられて（最近のマザーボードって、こんなに高機能なんですね…昔の DOS/V の頃のものしか知らないもので）、Full On で最高スピードでファンが回っていて結構うるさかった（それでも慣れましたが）のでうが、ファンのレベルを Level 4 に落としてかなり静音になりました。cpu の温度をチェックすると、40 度前後なのでまあ良いかと。

image

がりがり VMWare とか SQL Server とかを使ったときにまた確認してみます。

お次は、グラフィックボードを選定してみましょう。

カテゴリー: 最強.NET開発PC | 最強.NET開発PCを作るよ（その５） はコメントを受け付けていません

HDDのアクセススピードは VMWare に影響するのか？

投稿日: 2013/03/03 作成者: masuda

最強.NET開発PCを作るよ（その４） ストレージ編

の番外編として、CrystalDiskMark で HDD, SSD のアクセススピードを比較してみます。

VMWare が仮想 HDD にアクセスすると、それはそのまま物理 HDD のスピードに影響される訳で、遅い HDD 上に VM のディスクを作るとか、複数の VM が同じ HDD にアクセスしに行くと VM のスピードが落ちるのではないか？という仮説を確認します。

■まずは基本性能のチェック

CrystalDiskMark_SSDCrystalDiskMark_HDD1CrystalDiskMark_HDD2

左から

  • C ドライブの SSD
  • D ドライブの 新しい HDD
  • G ドライブの古い HDD

です。シーケンシャルアクセス（Seq）が、SSD が HDD の約3倍ぐらい。しかし、Visual Studio を使ったコンパイルの場合や SQL Server によるデータの更新には、20K ぐらいの小さなファイルアクセスが頻繁に発生します。となると、512K の 10 倍ぐらいから 4K の 30倍ぐらいの違いの間ぐらい、SSD は HDD よりもディスクアクセスのスピードが違うのではないか？という予想が立てられます。

■VMWare 上でベンチマークする

SSD 上の場合（左がホスト、右がVMWare上）

CrystalDiskMark_SSDCrystal_VMware_SSD

HDD 上の場合（左がホスト、右がVMWare上）

CrystalDiskMark_HDD1Clystal_VMWare_HDD1

VMWare 上だと、小さなファイル（4Kぐらいのファイル）で効率化されてるかと思ったら、そうではないみたいですね。逆にシーケンシャルのほうも、さほど VMWare 上だからといって、遅くなるものではないみたいです。

■同じ物理ドライブでベンチマークを動かす

VMWare 上で試す前に、同じ物理ドライブ（C ドライブの SSD上）で、2つのベンチマークを動かしてみます。そうすると、シーケンシャルのRead/Writeががくんと落ちて、1/2 になっています。同じ物理ドライブに対して R/W が発生するので、2 倍の負荷がかかります。当然ですが、スピードが 1/2 に落ちますよね。

image

ただし、よく見ると 512K や 4K は、それほど落ちていないことがわかります。もともとランダムアクセスで遅くなっているところがあるので、HDD のシーク速度を補う形でパフォーマンスが出ているかと。

異なる物理ドライブ（SSD と HDD）で動かすと次のように、それぞれのドライブだけでテストしたものと同じ結果が得られます。

image

■同じ物理ドライブで VMWare を動かす

VM の仮想ディスクを、同じ物理ドライブした状態で、それぞれの VM でベンチマークを起動します。VM 自体が別々なので、別々のパフォーマンスになるように見えますが、当然同じ物理ドライブを共有してしまっているので、パフォーマンスは 1/2 になってしまいます。

imageimage

こんな風に SSD の C ドライブだけが使われている状態になります。

image

逆に VM の仮想ディスクを異なる物理ドライブにした状態では、VM のパフォーマンスが良いことがわかります。左が SSD に配置している VM、右が HDD に配置している VM になります。単体で動かしたときと同じ程度のパフォーマンスが得られていますよね。

imageimage

また、ホストのタスクマネージャーをみると、C ドライブ(SSD) と E ドライブ(HDD)の両方が使われていることがわかります。

image

■同時に動かす VM は別の物理ドライブに配置する

そんなわけで、同時に動かす VM の仮想ドライブは、異なる物理ドライブに配置するとパフォーマンスが良くなるという実験結果が得られました。今回の場合は、ベンチマークを使って HDD, SSD に直接アクセスした訳ですが、VM に振り分けられるメモリが少ない場合はスワップが発生するので、この時点で、同じ物理ドライブに配置している場合はパフォーマンスが大きく低下することになると考えられます。

開発機の場合は VM をいくつも立ち上げることは稀なんでしょうが、仮想専用のサーバー機で VMWare や Hyper-V を使っている場合には、注意したいところかと。

カテゴリー: パフォーマンス, 最強.NET開発PC | 1件のコメント

最強.NET開発PCを作るよ（その４）

投稿日: 2013/03/02 作成者: masuda

最強.NET開発PCを作るよ（その１） はじめに
最強.NET開発PCを作るよ（その２） メモリ編
最強.NET開発PCを作るよ（その３） CPU編

の続き

image

ストレージ(HDD, SSD)を選定するときに、巷では 「Windows 8 の起動スピードを速くするために、SSD を使うのがよい」という話が多いのですが、私の場合、Windows 7 の頃からスリープを使っているので、起動に関しては通常の HDD で問題がありません。確かに瞬時に立ち上がるのは「心のストレス」的に良いには良いのですが、シャットダウンした後に、再び Outlook やら Visual Studio やらアウトラインエディタやらを立ち上げなおして、同じファイルを開いて、再び昨日の仕事の環境を整えるよりは、スリープから一発で立ち上げたほうが「仕事のストレス」的に良いのです。節電としては休止状態でもいいわけで、昨日の仕事場と今日の仕事場は連続した状態でありたいですよね。

なので、HDD, SSD を選定するときに、開発PCとしての視点では、

  • OS 領域とワーク領域を物理的に分ける
  • SQL Server などのデータベース領域を物理的に分ける
  • できれば、VMWare が使う仮想領域も分ける

という分け方で HDD/SSD の選定をします。

■OS 領域とワーク領域を分ける

OS 領域である C ドライブには Windows 8 を入れます。マイドキュメントなどのユーザー領域は他のドライブに逃がすこともできますが、開発時の安全性（さまざまなツールを使うことが多いので、デフォルトのドライブを変えないほうが、トラブルが少ないのです）を優先させます。なので、Visual Studio 2012 や Office 2013 などのインストール付きアプリも C ドライブに突っ込みます。

この C ドライブには基本「手順書」を使うようなバッチ付きインストーラーを使ってもインストールできるような状態にしておきます。HDD がクラッシュした時にもできるだけ早く復活できるようにすためです。

なので、HDD の物理的なクラッシュに備えて、プログラムやドキュメントなどのワーク領域は、D ドライブに入れます。私の場合、マイドキュメント配下に、ソースや設計書を置くことはありません。よく C ドライブと D ドライブが、ひとつの物理 HDD に乗っている場合もあるのですが（OS 入れ込みの BTO パソコンの場合は、そういうパターンが多いです）、HDD を追加して、データ領域を逃がすようにします。

サーバー系の場合は、データ復旧のために RAID を組むことが普通なのですが、開発用 PC の場合はソースや設計書などは別途 VSS や TFS などを使うために RAID を組みません。むしろ、RAID を組むとコンパイルスピードなどが遅くなってしまうので避けます。

物理的に C ドライブと D ドライブが別の HDD になっていると、OS がクラッシュしたときは、D ドライブの HDD をそっくりそのまま別の PC に移し替えて作業ができます。また、OS がクラッシュしても D ドライブに影響がないのがよいのです。ノートブックの場合は、このパターンができないので、定期的にデータ領域を PC にバックアップさせています。ノートブックの場合は、据え置きの PC とは違い、落下や盗難、水没などのリスクがあるので、ノートブックにしかないデータというのが存在しない状態になっています。

■SQL Server が使う領域を別 HDD にする

SQL Server を激しく使う場合には、別の HDD にデータベース領域を取ります。これはサーバー機でも同じなのですが、SQL Server がデータベースにアクセスしようとすると、できるだけ HDD のシークピンがそれ専用になるほうが早く動作します。たとえば、SQL Server でデータ解析をしているときに、Visual Studio でプログラミングなどをすると（あまりやらないだろうけど）、データ解析が遅くなります。その他、諸々あって、データベースの領域は別々のほうがいいんですよね。極端な話、2倍ぐらいのスピードが違います。これはあとで実測しましょう。

ちなみに、データベース管理者（DBA）的な視点で言えば、master 領域は別にするとか、同時アクセスする領域は別の HDD にしたほうが早くなるとか、クエリのチューニング以前の基本的な問題がいくつかあります。開発 PC の場合には、そこまでは必要がないので、数台の HDD を入れることは稀ですが。

■VMWare などで使う仮想領域を別 HDD にする

VMWare などの仮想 PC の場合には、データベースよりも更に影響が多いと思います。思います、というのは、この部分だけ経験則なので実測はしていないのです。vaio のノートブックに vmware を乗せて vc++ を使ってコンパイルをしているのですが、実に遅いのです。現在、最強PCに移してみると、それなりに早くコンパイルができます。CPU が早くなったというのもあるのですが、ちらちらとタスクマネージャを見ていたのですが、実は思ったよりも VMWare が HDD に掛ける負荷は大きいのかもしれません。

image

Twitter / kkamegawa: メモリ8GBで3台のVMまではやったことがあるけど、ディスク …

image

という話もあるし、確かに私も VMWare 3台の場合は妙な動きをする（いきなり、リモートデスクトップでつないでいる仮想 PC が重たくなる）ので、それかもしれません。同時に使う VM の場合は、別々の HDD に分散させるといのかも。となると、巷で言われる古いサーバーを VMWare に乗せたり、Hyper-V に乗せたりしている場合はどうなるのか？という話がありますよね。そういう記事はあるのかな？

■そんなわけで SSD, HDD を構成する

  • SSD – OS 領域
  • HDD – ワーク領域
  • HDD – SQL Server 領域
  • HDD – VMWare 領域

という具合にします。VMWare 領域は、以前の PC から引っ越ししたので、購入分は SSD と HDD ２台です。

image

SSD は、256 GB 程度でも良かったのですが、データベースを SSD で試すとか、VMWare を SSD で試してみたいとか、という目的もあったので、かなり多めのものを用意しています。

  • C ドライブ SSD 512 GB
  • D ドライブ HDD 2 TB
  • E ドライブ HDD 2 TB
  • G ドライブ HDD 1 TB

という構成。SSD は、Plextor PX-512M5P を使い、HDD は好みの関係から W.D WD20EZRX SATA3 2TB を 2 台。G ドライブは、日立のものです（まあ、今となっては一緒なんですが）。

image

VMWare のほうは、こんな風に Linux やら、Windows XP やらいくつかのバージョンを用意しておきます。いくつか容量が足りなくて処分してしまったのですが、Windows XP の SP1 などを残して検証用に使います。あとは、開発環境（Visual Studio 2008）とソースコードを入れ込んで、いつでも復活できるようにするとか、そういう使い方をします。これも HDD を別にしておくことで、新しい PC に即換装ができるということです。まあ、コピーしても１昼夜かければ、大丈夫ですが。これもクラッシュに備えるとうことで。

つぎは、CPU, メモリ, HDD を積むということで、マザーボードの選定の話を。

カテゴリー: 最強.NET開発PC | 最強.NET開発PCを作るよ（その４） はコメントを受け付けていません

最強.NET開発PCを作るよ（その３）

投稿日: 2013/03/01 作成者: masuda

最強.NET開発PCを作るよ（その１） はじめに
最強.NET開発PCを作るよ（その２） メモリ編

の続き

CPU を選定する前に考えたのが、用途です。早い CPU にすればそれに越したことはないのでしょうが、予算の関係やそもそもその CPU の性能を使い切れるのか？という問題もあって、それなりに適切なものにしたいと。

候補に挙がっていたのが

  • Core i7 3930K
  • Core i7 3770K
  • Core i5 3570K

なところです。価格.com などの掲示板で見ると、3930K のほうはオーバークロッカーが使っていたり動画のエンコードで使っていたり。3770K のほうは現状のスタンダードというところで、動画のエンコードには十分という話が書いてあります。

Intel core i7-3820

動画のエンコードの場合には、CPU を使いっぱなしになる高速運転状態が特徴です。ですが、Visual Studio などを使った開発 PC の場合には、最大瞬間風速はそれほどいらないのですよ。確かに、OpneCV で顔認証の解析をするとか、テンプレートマッチングをがっつりと書くとか、というのならば動画のエンコード並に CPU 速度が効いてくるのですが、ソフトウェア開発をしているときには、ほとんどがキーボードを打っている時間なので、さほど瞬間風速は高くなくてもよいのです。

結果的に i7-3820 という CPU に落ち着いたのですが、実は i7-3930K と i7-3820 の間にはコア数が異なるという壁があります。6コアと4コアの違いなのです。価格的に2万円も違うので、オーバースペック＆オーバー予算ということで、4コアに落ち着いたのですが、ちょっと6コアというのは、プログラマにとって魅力的なんですよね。

■なぜコアが多いほうがいいのか？

ちょっと、このタスクマネージャを見てください。VMWare 上で、２プロセッサを振り分けて VC++ のビルドをしているところです。Windows 7 のタスクマネージャでは、Visual Studio が2プロセッサを使ってビルドをしています。

image

ホストしている Windows 8 のほうで、ちょうど波があっているところが、この２プロセッサですね。動画のエンコードや Windows 8 上で Visual Studio だけを動かしてる場合は、プロセッサに均等に負荷が割り当てられるので、こういう風にはなりません。

image

実はプロセッサにプロセスを割り当てるほうが、タスクの切り替えなどが発生しないのでプログラムの実行は早くなるし、プログラムは簡単になるんですよね。C++ AMP などが出てきているので、パラレルのプログラミングも難しくはなくなってきていますが。まあ、そこまで本格的にプログラムで制御しなくても、開発パターンとして、Windows 8 で２枚のモニタを使って開発していれば、

  • ひとつのモニタで Visual Studio で組む
  • もうひとつのモニタで、Windows ストア アプリを常時稼働
  • VMWare でサーバー割り当て
  • SQL Server などのデータベース処理

を同時に実行することになります。まあ、さらに私の場合には雑音を消すために、動画が表示されているという GPU を使うパターンも多いのですが、データベース処理と開発環境（Visual Studio）をバッディングさせないというのが CPU のコアを求める理由のひとつです。

なので、２万円ほど予算を積んで、コアを1.5倍（4から6へ）にしたほうが良かったのでは？と思ったりもしますが、まあ、そのあたりは予算的なものもあるし。

そんなわけで i7-3820 に落ち着いたというところです。

ARK | Intel® Core™ i7-3820 Processor (10M Cache, up to 3.80 GHz)
ARK | Intel® Core™ i7-3930K Processor (12M Cache, up to 3.80 GHz)

■AMD はどうなのか？

今回は、無難に Intel を求めましたが、AMD という選択もあります。AMD だと同一の価格帯で8コアいうものもあるので、先の並列で動かすという条件を軽くクリアできます。

その場合には、マザーボードはどれを選べばいいの？ってことになるので、ちょっと私の知識では追いつかないので…そのあたりの選定は両氏に任せるということで。後で聞いてみますか。

お次は、ストレージ関係で SSD, HDD ということで。

カテゴリー: 最強.NET開発PC | 最強.NET開発PCを作るよ（その３） はコメントを受け付けていません

[C++/CLI] モニタの解像度をプログラムから変更する

投稿日: 2013/02/28 作成者: masuda

たまに C++/CLI の記事などを。Visual Studio 2012 からは C++/CLI もインテリセンスが使えるようになったので、C# と win api を媒介する C++/CLI のプログラミングもばっちりですね…って、2010 の時に出してほしかったよなぁ。ちなみに、2012 では C++/CLI でフォームアプリケーションが作れない（ことはないけど、テンプレートに入っていない）ので、そのままフェイドアウト…なのか？ それとも C++/CX と融合するのかは謎なところです。

■解像度とモニタを指定する

解像度自体は、ChangeDisplaySettingsEx 関数を使いますが、複数のモニタがある場合はデバイス名が必要にあんるので、あらかじめ EnumDisplayDevices で取得しておきます。
本来は、モニタのリストとかを取ればいいのですが、画面キャプチャ用のツールなので、モニタ数などは決め打ちで。 

#include <windows.h>
#include <WinUser.h>

public ref class GDI
{
public:
	static void ChangeDisplay( int width, int height, int moniter )
	{
		// デバイス名の取得
		DISPLAY_DEVICE disp;
		EnumDisplayDevices( NULL, moniter, &disp, NULL );
		// 解像度を設定
		DEVMODE mode = {0};
		mode.dmSize = sizeof(mode);
		mode.dmPelsWidth = width ;
		mode.dmPelsHeight = height ;
		mode.dmFields = DM_PELSWIDTH|DM_PELSHEIGHT;
		// 解像度を変更
		long ret = ChangeDisplaySettingsEx( disp.DeviceName, &mode, NULL, 0, NULL );
	}
};

■C# から呼び出す

画面自体は、C# で作ります。
解像度自体は、コントローパネルから調べて決め打ちです。ボタン一発で切り替えることができます。 

/// <summary>
/// 解像度変更
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void button10_Click(object sender, EventArgs e)
{
    scrcaplib.GDI.ChangeDisplay(1024, 768, 1);
}
/// <summary>
/// 解像度変更
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void button11_Click(object sender, EventArgs e)
{
    scrcaplib.GDI.ChangeDisplay(1280, 1024, 1);
}

これを C# だけでやろうとすると、構造体やら定数定義やらがややこしいんですよね。なので、win api を直接叩くのではなく、C++/CLI を媒介にすると簡単になるよ、という実例です。

カテゴリー: C#, C++ | [C++/CLI] モニタの解像度をプログラムから変更する はコメントを受け付けていません

最強.NET開発PCを作るよ（その２）

投稿日: 2013/02/28 作成者: masuda

最強.NET開発PCを作るよ（その１）
http://www.moonmile.net/blog/archives/4116

の続き。

開発用 PC を構築したいと思ったときに、各氏に相談した条件として「メモリは 64GB」にしたい、というのが筆頭でした。円安になって、輸入もののメモリとか HDD とかがバンバンと高くなる折だったのですが、ここでケチってしかたがないし。かといって、どのくらいのメモリが「開発にとって快適になる程度なのか」はいまいちわからなかったのです。
BTO パソコンの場合は、ブラウザで見ながらポチポチとメモリの容量を挙げて「ああ、これだと全体が高くなるから、この程度でいいか」ってな具合に、価格比で計算してしまいがち。あるいは、マザーボードなどの制限から、積めるメモリはこれが限度、ってな具合に当時買うときの限界いっぱいまで、ってのが普通です。

image

で、今回の場合は、Windows 8 を入れるのは必須だから、最低でも 2GB 以上、最大は 128 GB までいけるそうで、その間の選定になるのは確かです。開発マシンの場合、客先の実行環境と揃えるためにあえて 32 bit環境を揃えないといけない場合もあるのですが、今回は自分のメイン開発マシンになるので 64 bit 環境にして、メモリ枠を外していきます。

そして、手元にある PC で Windows 8 を試している体感として、

  • メモリ 4GB では、Windows 8 そのものが重い。
  • メモリ 8GB は、Windows 8 は軽いのだが、Visual Studio 2012 の XAML デザイナが重い。

という感触を得ています。メモリ 4 GB のほうは、CPU が Dual core という古いマシンなので、i5 あたりの CPU であれば、もうちょっと快適でしょう。実際、acer w500 では、メモリが 2GB しかない状態ですが自作の Windows ストア アプリなどは、さくさくと動きます。ただ、GPU が非力なので、Windows ストア アプリのゲーム関係はほとんどダメですが。

メモリ 8GB のほうは、vaio のノートブックで、当時（２年前？）にメモリをいっぱいまで積んだものです。このノートパソコンだと、Windows 8 はさくさく動くのですが、微妙に Office 2013 が重かったり、Visual Studio 2012 のデザイナのところで倒れたりしています。たぶん、HDD 関係が重たいので、バランスの悪いマシンなのでしょう。

image

image

ビジネス仕様かつノートブックなので、グラフィック関係はあまり関係ありません。Windows 8 では HDD のアクセススピードが推奨環境に入っているので、これが足を引っ張っているような気がします。

これらの経験からすると開発機としては、最低 16GB のメモリを積んでないと「快適な環境」は望めないのでは？と考えました。Visual Studio 2012 自体は、100 MB と以前とあまり変わらないのですが、XAML デザイナが同じく 100 MB、シミュレータを動作させると、こんな風に自分自身にリモートログインをするために、利用メモリががんがん増えていきます。

image

なので、シミュレーター自体を快適に動かすためには、ホストのマシン（Visual Studio が動いているマシン）に、タブレット PC 並の余力が必要になるのでは？と考えています。このあたりは、時間を取って検証したいところですね。

プラス、サーバー系との接続をするため、執筆の関係や顧客環境の関係から、いくつかの Widows のバージョンを用意しておく必要があります。私の場合、VMWare を昔から愛用しているのでこれを使うと、最低でも 2GB は取られてしまうのです。所詮、仮想環境ですから（サーバー機ではないという意味で）接続できれば ok という考え方もあるのですが、逆に言えば仮想環境としてパフォーマンスを利用して、高速な LAMP 環境とか IIS/ASP.NET 環境として利用してもよいわけです。こうなると、仮想環境であってもメモリを 8 GB 取れれば、結構なことができそうです。

そういう経緯で考えて、

  • Windows 8 + Visual Studio 2012 + Blend + シミュレーター で 8GB
  • VMWare の仮想環境で 8GB

というパターンは最低おさえておきたい。なので、16 GB は最低ほしいメモリなのかなというところです。仮想環境を使わない場合は、8GB に抑えておいてもよいのですが、体感として16GB はないと足りないところでしょう。

これに、動作としては、

  • ブラウザ Firefox
  • Office 2013

が加味されます。ブラウザは、ie でも chrome でもなんでもよいのですが、Visual Studio で開発しているときにブラウジングが重いと、開発効率に影響します。google を使って検索しますからね。ええ、私の場合、家での開発なので「社内セキュリティでブラウジングできない」っていう縛りはありません。

Office 製品は、Excel/Word/Outlook を使っています。メーラー関係は、電八でもいいのですが、あんまりこだわりがなくなって、しばらく前から Outlook にしてしまいました。
プリントアウトをほとんどしなくなってから、モニタで仕様書の確認をしています。あと、進捗管理用に Excel は必須なのです。このあたりを数枚開いた状態で、Visual Studio を使って開発をするので、さらにプラスして 32 GB ってのがあれば、大丈夫かなと考えていました。

■メモリスロットの問題

32 GB の場合は、8GB のメモリを4枚ってことになります。マザーボードの関係から、メモリのスロットが 4 枚ということが多いので、この構成がベターなところかなと。同期とか相性の関係から、本来ならば 2枚セットを1つだけで済ませたいところですが、そうすると 16 GB x 2 とか、高い構成になりそうな感じ。

さて、当日、各氏と秋葉原を巡ったわけですが、各店舗で 16 GB のメモリが売り切れていました。32 GB のメモリにしてもよかったのですが、ここを必須としたのは、

  • 先の環境に加えて、SQL Server などの DB を乗せて実験する
  • VMWare を同時に2以上動かして、C/S のパフォーマンスチェック
  • 普通に出回っていそうな 32 GB では男が廃る

ってのを考えて（ええ、多少見栄もあってw） 64 GB になっています。「安心料」って感じですかね。あと、自分へのモチベーション燃料とか。

そんなわけで、メモリ購入の当日、16 GB のメモリがないので手詰まりか…と思ってみたものの、実は、各氏に選定してもらったマザーボードのメモリスロットルが 8 枚であることがわかりました。これならば、8 GB を 8 枚（2セットを4個）で差し込めるわけで、メモリの価格も抑えられます。

■で、実際どうなのか？

軽く Visual Studio 2012 を立ち上げて、Outlook を動かしてという具合で、現在こんな感じです。メモリ的には、5.4 GB なので、8 GB あれば十分かと思えるのですが、実体験からいうと Visual Studio + Office だけの組み合わせでも 16 GB は必要です。なんやかやと動かし続けると、8 GB ぎりぎりになってスワップが発生し続けて、Visual Studio が重すぎる感じになります。

image

なので、現状、Intel i5, i7 ぐらいの CPU であれば、16 GB ぐらいに増設すれば、そこそこ開発に快適な環境が得られるのではないかと。実売的には、1万円ぐらいの追加投資ですかね？

次は、CPU についてみていきます。

カテゴリー: 最強.NET開発PC | 3件のコメント

最強.NET開発PCを作るよ（その１）

投稿日: 2013/02/25 作成者: masuda

去年の pp-club のイベント絡みの飲み会で「プログラマ用の開発PCとはなどんなスペックか？」という話があって、作ってみたい～と年末年始ごろに夢にまで見ていたのですが、リンクスインターナショナル社の阪口さんと、デザインラボの加藤さんのご協力もあって、晴れて最強.NET開発PCの自作にこぎつけました。

.NET 開発専用パソコンを考える（´・ω・）ｽ その１ 全体とメモリ｜WEB系技術電脳日記
http://ameblo.jp/konica/entry-11476853250.html

あたりも参照にしてください。

私の場合、自作PCってのはDOS/Vの頃ぐらいしかなくて、そのあとはちょっとしたメモリ増設とHDDの追加ぐらい。当時、オーバークロックが流行っていたのですが、手を出したことがありませんでした。１年前ぐらいから、duck さん のようなオーバークロッカーという方もいて、まさしく最近の自作PCの主流は OC ってことなのか…ってことで、ここ数年買うのは、BTO パソコンっていうお仕着せパソコンを買っていた訳ですが。

去年の 12/1 にリンクスインターナショナルさんからデモ機を持ち込んでもらって、その場で Windows 8 + Visual Studio 2012 + Office 2013 Preview あたりを軽く試してみました。詳しくは忘れてしまったのですが、CPU もメモリもそれなりに豪華版であったということで、サクサクと動いて密かに感激しておりました。私の PC が、3年ぐらい前の BTO PC だったこともあって、Windows 7 ではそれなりに動くのですが、Windows 8 だとちょっときつい、更に言うと、Visual Studio 2012 の動き重くなり、さらに XAML デザイナーの部分がかなり重たいので、「いったい、推奨スペックはどのくらいなのか？」と疑問を持っていました。実際、Windows 8 のパッケージにはそれなりに推奨スペックは書いてあるものの、実運用で Windows 8 + Visual Studio 2012 + Office 関連 + VMware 関連を動かしたときに「快適に仕事ができる程度の PC」ってのが、どのくらいのものなのか？をここ２か月ほど考えていたわけです。

■お仕事の前提条件

プログラマにしたって、いろいろな仕事があるわけで、そこそこのパソコンでいい場合と、高速なパソコンがほしい場合と、サーバーと組み合わせないとダメな場合とか、社内だとかフリーだとか、いろいろと条件があります。

普段使いで同時にうごいているのが、

  • Windows 8
  • Visual Studio 2012 が 2,3枚
  • シミュレーター
  • Word/Excel が 2,3枚
  • PDF が 2,3 枚
  • Firefox が 10タブぐらい

ってところが普通に稼働している範囲です。これに、別件の VMWare + 英語版 Windows 7 + Fortraun + VC++ があって、これは別にマシンで動かして、リモートデスクトップで接続させています。

このあたりをベースにして、ちょっと構成を考えたのが、以下なところです。

  • CPU は、それなりにコアが多いほうがいいと思う。
  • メモリは、64 GB 積んでみる（仮想環境も含めてみる）。
  • GPU はどのくらい必須のなのか？
  • C ドライブは SSD のほうが早いのか？コンパイル速度は速くなるのか？
  • HDD は、作業領域とデータベース用に 2 台用意する
  • モニタは 2 台必須

■購入と組立て

このあたりを、ざっくりと、加藤さんと阪口さんに相談して、パーツを選定して貰い、2/23(土) に秋葉原で購入＆組立てました。組み立てました…とはいえ、実際に組立てたのは阪口さん。私は財布係です（苦笑）。

image

メモリチェックをして貰ったのですが、64GB だと 1時間経っても 30% を超えたぐらいなので断念（笑）。メモリは、CMX16GX3M2A1600C11 という 8GB x 2 を 4 つ購入しました。メモリの場合、型番なりロットを合わせないと同期の問題があって、動かないパターンってのが出てきます。また、最初の頃は大丈夫でも、使っているうちになんかおかしくてブルースクリーンになる、ってのはメモリ同期がおかしいパターンが多いんですよね。

image

あれこと２時間弱かかって（半分はメモリチェックです）。ここまで組んでもらいました。配線は、裏側に隠してあるという美しい仕様。これを自分が作るとなると大変…といいますか面倒なので、マザーボードの上をうにょうにょと配置する形になってしまうのですが。

image

一応、その場でチェック用に、

  1. Windows 8 Pro をインストール
  2. Visual Studio 2012 をインストール
  3. Office 2013 をインストール
  4. VMWare Workstation 8 をインストール
  5. VMWare 上に Windows 8 をインストール（メモリは 8 GB 割り当てる）
  6. VMWAre 上に、Visual Studio 2012 をインストール

な感じにして、ホスト側で、Visual Studio 2012 + Office 2013 + VMWare を同時に動かすというパターンを試してみましたが、全然大丈夫、びくともしませんね。この「びくともしないところ」が、メモリなのかCPUなのかGPUなのかSSDなのかを、ぼちぼちと検証していきたいと思っています。どう考えても 64 GB のメモリは積みすぎ、という感じがしないでもないのですが、VMWare 上に仮想的なサーバーを組み立てて、IIS + ASP.NET + SQL Server でテストをするとか、Apache + PHP + MySQLのパターンを使うとか、いろいろあるので開発＆検証用としては、これぐらいあったほうがよいのか、どのくらいあったらいいのか、ってのを調べていきます。

予算をいくらでもつぎ込んでいけば、CPUなりメモリを積むことができるものですが、費用効果とか原価償却とか本当につぎ込まないとダメなところ、逆にいえば「ここをケチってしまうと、開発効率が格段に落ちて、できあがるものもできあがらない」っていう悪い要素を消していきたいですね。

カテゴリー: 最強.NET開発PC | 最強.NET開発PCを作るよ（その１） はコメントを受け付けていません