FPGAマガジンNo.12の誤記/誤植一覧

2016年3月31日木曜日

FPGAマガジンは毎号技術的にエッジーな記事が多く勉強になる、本当にありがたい存在です。しかし誤植が割とコンスタントに多いです。技術専門誌としての本分は「他で得難い情報」にあるので、限られた執筆・編集時間をそちらへ割くのは当然なのですが、利用者の裾野を広げる意味ではちょっと悲しいです。
No.12もけっこう誤植多いな…と思いつつ読んでいたのですが、毎回「誤植多いぽよ～～」と言っているだけでも改善しない気がします。著者の方々に誤植一覧が届けば次以降の原稿で気をつけるヒントになるかもしれない、という期待も持ちつつ精読して洗い出しました。66箇所ありました。
多くは細かな表記上のミスや写植上のミスです。脳内で補正しながら読めば良いので大した問題ではなく、放っておいても良いようにも感じられます。自分の慣れているエリアの文章は脳内での読み替えが効きます。しかし当然スピードが落ちます。バイナリトランスレーション大変でしょ。とりわけ私の場合、記事の序盤で複数のミスを見つけると不安になってじっくり読むフェーズに入り、1/5ぐらいのスピードでしか読めなくなってしまいます。
また私は、初心者向けの技術記事では写経可能性もかなり大事だと思っています。ここでは特に間違いを減らしたいものです。写経で経典が間違ってるとかそもそもやばいし、当該環境に慣れていないと自力で誤りを見つけて乗り越えるのが難しいから。近年は雑誌でキーワードを拾い、その後にネットで調べて深めるフローも多用されます。キーワードが間違っていたら先を調べていくのも一苦労します(Googleのキーワード補正に期待することもできますが、著者側がこれをいうと開き直りにしかなりません)。
そういうわけで、この一覧が誰かの学習の役に立てば幸いです。

特集 第1章 Cyclone V SoCとZynqの比較とFPGA開発フロー

p.10
  • 右段なかほど All Programable → All Programmable
  • 右段下 PowePC → PowerPC
p.12
  • 表3 Contoller → Controller
p.15
  • 左段下見出し Quatrus → Quartus
  • 右段下箇条書き Impliment → Implement
p.17
  • 表6 Programing → Programming
  • 表6 PomGen → PromGen
計7箇所

特集 第2章 VGA表示回路を例にしたMy回路のIPコア開発とライブラリ化

p.20
  • 図3右 Cyclone V Soc → Cyclone V SoC
p.22
  • リスト2冒頭 `define XILIXN → `define XILINX
p.24
  • 右段上 Memoris & → Memories &
計3箇所

特集 第3章 ビルディング・ブロック開発によるMy回路IPコアのFPGAへの実装

p.35
  • 図5 QSys → Qsys
  • 図5 モージュル → モジュール
p.43
  • 左段上 Ummapped → Unmapped (2箇所)
計4箇所

特集 第4章 共通カスタムLinuxディストリビューションの開発

p.46
  • 左段上 Suppor → Support
p.47
  • 図1右上 Yocoto → Yocto
p.49
  • 左段 Ubutnu → Ubuntu (2箇所)
  • 右段下見出し bblayes.conf → bblayers.conf
p.53
  • 左段中 SPLのコンパイルgmakeを → SPLのコンパイルはgmakeを
  • 左段中 ubuntu → Ubuntu
p.54
  • 左段中 Cyclne → Cyclone
  • DTB(Device Tree Bomb) → DTB(Device Tree Binary)*
  • DTS(Device Tree Script) → DTS(Device Tree Source)
DTBが何の略かについては、Linuxのドキュメント(https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt)とDevice Treeのドキュメント(http://www.devicetree.org/Device_Tree_Compiler)で確認しました。
計10箇所

特集 第5章 ついに起動！デュアル・ブートSDカードの作り方

p.61
  • 表4 DTB(Device Tree Bomb) → DTB(Device Tree Binary) (2箇所)
計2箇所

特集 第6章 Linuxデバドラ＆アプリケーションの作成と性能評価

p.66
  • 左段上(5行目) ./memwrite 40010000 1 → ./memdump 40010000 1
計1箇所

特集関連(1) Atlas-SoCでアルテラSoC環境を手軽に楽しもう

p.74
  • 左段 SysFs → Sysfs
    • p.80のリスト3キャプション部分表記に揃え。この場合、p.81の4箇所も変更
    • あるいは逆でp.80のリスト3キャプションをSysFsへ揃え
      • 一般的表記はSysfsあるいはsysfsだと思うけれど、一貫性を重視する意味ではp.80のリスト3側を変えるほうが手っ取り早い
  • 右段中 Cyclon → Cyclone
p.76
  • 右段見出し Cyclon-SoC → Cyclone-SoC
p.77
  • Liteweight → Lightweight (11箇所、うちリスト1のコメント中に2箇所)
  • 右段中 LiteWeight → Lightweight
  • リスト1キャプション Liteweigth → Lightweight
p.80
  • 右段中 Liteweight → Lightweight
p.81
  • Liteweight → Lightweight(4箇所、うち本文に2箇所、図5中に2箇所)
p.84
  • リスト7コメント Liteweight → Lightweight
計22箇所

特集関連(2) 使いやすいXillinux＆XillybusをTerasic社SoCKit上に導入する

p.85
  • Ubuntsu → Ubuntu(2箇所)
  • 図1絵解き Xilliux → Xillinux
  • 図2 Row Binary File → Raw Binary File
  • 図2 Xilinux → Xillinux
p.86
  • 右段中 Xilliux → Xillinux
p.91
  • 写真4 キャプション Xilliux → Xillinux
計7箇所

USBコミュニケーション・デバイス・クラス対応のUSBターゲット機器の実装

p.94
  • 表1 最上段 「転送速度 フルスピード」がヘッダとして網掛けになっているのはおかしい
    • 仕様表記なので最上段はヘッダ無しでも成立する。網掛けのみが不要
    • あるいは「名称 仕様」などが無難
p.98
  • 右段上 usbCdcDeice → usbCdcDevice
  • 図9 EPOCdc → EP0Cdc
p.99
  • 右段下見出し ディスクリプタの要求動作例 → デスクリプタ～
    • 章内でずっと"デスクリプタ"表記なので、表記ゆれ
p.105
  • 左段中 監視するたけでも → 監視するだけでも
計5箇所

プログラミング言語PythonではじめるFPGA開発入門

p.108
  • 表1 Flase → False
計1箇所

SDKを使ったMicroBlazeのソフトウェア開発手順詳細

p.119
  • 図2(b) Local Project → Local to Project
  • 図3(b) Local Project → Local to Project
p.120
  • 図5(a) "File → New-Application Project" → "File → New → Application Project"
    • 本文での表記にあわせる
p.125
  • 図10(a) 右部分の丸囲みが1段上についている
    • PDF版のみかもしれない
計4箇所

Cyclone V SoCで試す無償版純正PCI Expressコアの使いこなし

なし!

微妙なもの

  • P.15 iSimとISimあたりの表記が揺れている
    • そもそもVivadoではISim使わない? Vivado Simulatorへ変わったような気もする
  • p.53 右段の日本語ぐちゃぐちゃ
  • p.74 右段 Helio → Sodiaかなぁ
    • 本号の執筆段階でHelioを終売してSodiaへ向かうという流れはそれなりに明確だったので
  • p.85 図2 XillyBus IP → Xillybus IP
    • これはどちらの表記でも良いのかもしれない。判断つかず
  • p.101 リスト2(usbCdcROMの定義部分) usbCcdROM.v → usbCdcROM.vではないか。同usbCcdDevice_define.v → usbCdcDevice_define.vではないか
    • この記事は解説とコード抜粋紹介のみで実コードのダウンロード先を記載していないので正しいところは分からない
  • p.127 EPROMの接続例です → EEPROMの接続例です
    • EEPROMもEPROMのうちなので"EPROM表記でも"間違ってはいなさそう。しかし図14キャプションの表記を見ると、ここもEEPROMと記載するのが適切そう
  • p.129 Basysボードに → Basys3ボードに
    • ここまで一貫してBasys3と表記しているので、ここも揃えるべき。しかしBasysシリーズには違いないので、まあ良いのかも
なお、今回のまとめにおいて
OpenEmbedded Projectとは,組み込み機器用の Linux ディストリビューションを作るためのソフトウェア・フレームワークを提供しています(図 3). - p.50
こういう、日本語として(???)な記述はすべて無視しました。技術用語が間違っていたり、明らかに意味が通らないものだけを書きました。
投稿者 Unknown 時刻: 11:06 0 コメント
ラベル: , ,

DockerコンテナがフリーズするLinuxカーネル+AUFS起因の問題

2016年3月25日金曜日

.NET Core環境用の操作ツールであるdotnetコマンドをDocker環境上で動作させようと試みたものの、.NET Coreのdotnetコマンドを試そうとしたら試せなかったの通りハングアップしました。一旦issueを立てて置いていたのですが、その後の話を書きます*1。
[*1] 少々タイトルの範囲が大きいですね。Docker環境での.NET Core公式イメージ実行時に発生した問題ですが、もっと一般的な問題だとわかったのでこうしました。

現象の概要(おさらい)

  • microsoft/dotnet:latestを実行すると、mkdirやcdは通るがdotnet newという.NET Core用のプログラムを実行した時点でコンテナがフリーズする
  • フリーズしたコンテナはdocker kill ...で強制終了できない
  • topコマンドでホストマシン状態を見ると、DockerデーモンがひたすらCPUを食いつぶしている
  • 結局Dockerデーモンを再起動するか、ホストマシンを丸ごと再起動するしかなくなる
この現象はMac OS X上に作ったBoot2Docker環境(VMWare Fusionベース)でも、手持ちのDebianサーバ上に作ったDocker環境でも同じように発生しました。
これを受けて前回は、`latest` image freezes immediately after running `dotnet new` #26というissueを立てましたよという話で終えていました。

その後

issueを立てた時点で一番疑っていたのはDocker自体です。ホストとのコミュニケーションを多用するメモリ管理かI/Oのどこかでミスっているのだろうという読みでした。
その後の手元テストにより、この問題はBoot2Docker(b2d)を新しいバージョン(1.10系)へ上げると発生しなくなることがわかっていました。このためひとまずb2d環境でdotnetコマンド群のテストをおこなっておけば良いか、と考えていました。
しかしissueに対してDocker 1.9.1 hanging at build step "Setting up ca-certificates-java" #18180関連の問題では?というコメントをもらいました。

本当の原因(Dockerコミュニティの阿鼻叫喚)

このissueは私が見た時点でクローズ済みでしたが、なかなか壮絶で壮大な戦闘録が残っていました。
結論をまとめると、これはLinuxカーネル内のmm/filemap.cに対する改善(sendfileシステムコールを利用したデータの書き込み処理で、停止シグナルを受けて途中終了できるようにしたもの)と、Dockerが利用するレイヤードファイルシステムのひとつであるAUFSのデータ書き込み部分の一部に従来のカーネル実装へ依存するコードが存在したことで発生した問題でした。2016年2月末時点で主要ディストリビューションでの対応は終わっており、OSアップデートにより解消します。
この問題の解決までを時系列でざっと見てみます。
  • 最初の問題報告が11/24
  • Linuxカーネル4.1.13での変更が関わっているらしいと判明したのが12/4
  • --virtualbox-cpu-countなどによりDockerデーモン稼働VMへ割り当てるCPU数を増やすワークアラウンドが発見されたのが12/5
    • その後、これはあくまでも発生頻度を下げるだけで根本対応とならないこともコメントにて指摘されています
    • この少し前から、Boot2Dockerで利用しているAUFSのバージョン依存の問題では、という推測(ほぼ確信)がいくつか出てきました
      • 「だっから！AUFSなんて！使うのやめろ！!」勢もぽちぽちと出ていました
  • 時間経過と共に影響を受ける人が増えた分か、しばらく再現報告や+1が続き(そう、当時GitHubにはリアクション機能がなかったのです)、12/8にはDockerチームメンバーから「新情報無いのにコメントするのやめーや」というお達しがありつつもしばし事態は硬直
  • 事態は12/21にAUFS内で動作停止に至る具体的な箇所が特定されたのをきっかけに再び動き始め
  • ワークアラウンド版の実装、カーネルバージョンを下げる緊急回避策の確立、AUFSの新版を取り込んだカーネルビルド策での対応を経て
  • b2dを含む各ディストリで徐々に新版AUFSの取り込み作業がおこなわれ
  • Debianが2/29に3.16.7-ckt20-1+deb8u4を出したことで主要ディストリでの問題対応が収束
3ヶ月に及ぶ、長く苦しい戦いだったようです。
まず、https://github.com/docker/docker/issues/18180#issuecomment-161843456にてAUFSとmm/filemap.cへの変更によるものだと突き止めているのすごいなと思いました(小並感)。
そしてこの問題へ取り組み、さっそうとトラブルシュートしつつ更に広い視点からの解決策を模索してAUFSへ潜って本家とやりとりをし、更に主要ディストリ(Ubuntu、Debian)へfix取り込みの働きかけをおこない、それらの状況をトラッキングしissueへ追記していくAkihiroSuda氏まじぱねぇという感想でした。手練というか、なんかNINJA感がありました。
そういうわけで、私が試した環境2つがたまたま該当してDocker本体の問題と思い込んだのが敗因(?)でしたね。

その後、dotnetコマンドは

普通にうごきました。
立てたissueも先ほどcloseされました。
投稿者 Unknown 時刻: 9:17 0 コメント
ラベル: , ,

日経ソフトウエア 2016年5月号に寄稿しました。そして記事の補足

2016年3月24日木曜日

日経BP刊の日経ソフトウエア誌 2016年5月号(3/24発売。今日です!→Amazonで買えます)に「Windowsアプリはなぜ動く ～そのとき、PC上では何が起こっているのか？～」という特集記事を寄稿しました。

  • Windows上でC系の言語から素直に書きだした.exeファイルとC#などの.NET系言語から書きだした.exeファイルの中身の差
  • これらを実行した際のOS側での処理差やランタイム差
  • Universalなアプリ(8.1 Universal, UWP)の登場背景と基本構造
という話を広く書きました*1。
[*1] ところどころコラムでMonoへの言及や.NET Nativeの話なども挟まっていますが、いずれも概要のみです。

背景とねらい

話の基盤には同誌2015年9月号に掲載された「特集1　言語はなぜ動く」というものがあります。これは、Windowsプログラムを含めて様々な言語(JSなど)で書いたプログラムが実際に実行されるまでの流れを解説した、なかなかクールなものでした(私が書いたものではありません)。
この流れを一定汲みつつ、よりWindows上そして主にC#で書かれたプログラムへと振ったのが今回の特集です。
もちろん、各分野を専門的にやっている人からするとイントロぐらいの話です。なるべくすらすら読めて、初心者の方でもなんとなく分かる(そして、更に興味を持って書籍やネットで調べたくなる)というのを狙いにしました。
パラッと読んでみて「これざっくり把握するのに良いから読んでみて」と後輩へ渡すようなシーンが生まれると最高に嬉しいです。
内容は分かりやすい範囲で正確性を失わないよう心がけたつもりですが、不正確な点など気付かれましたらmuo [at] muo.jp宛に指摘を頂けると幸いです。
本エントリでは、書いた原稿の中でボツになったものを中心に、記事の補足を記載します。

参考文献

編集過程でなくなっていましたが、実は一番書きたかったのがこれです。
今回の特集では、.NET Frameworkの内部やWindowsの内部処理に関する紹介をおこないました。これらのトピックについては、次に挙げる書籍が大変参考になります。
なかには入手しにくい本も存在しますが、興味が湧いたらぜひ読んでみてください。
  • インサイドWindows 第6版 上巻および下巻 (著: Mark E. Russinovich, David A. Solomon, Alex Ionescu, 訳: 株式会社クイープ)
    • 今回の特集での関連トピック: Windows上でのプログラム実行の仕組みやOSの内部構造について
    • この筋の定番本です
    • 紙版は結構値が張るので、Kindle版をおすすめします
  • プログラミング.NET Framework 第4版 (著: Jeffrey Richter, 訳: 藤原 雄介)
    • 今回の特集での関連トピック: .NETの型システムやメタデータ、セキュリティに関する構造などについて
    • .NETについてより良く知りたい、と感じたらこの本を開くと大体良いトピックが見つかります
  • The Root of .NET Framework (著: 荒井 省三)
    • 今回の特集での関連トピック: .NET Frameworkの構造やCILからネイティブコードへの変換などについて
    • 今回の特集では扱いませんでしたが、SOSを利用してJITコンパイル後のx86コードを追いかけるくだりはシビれます。Windows 10世代では多少事情が異なるポイントもありますが、原則の部分はほとんど通用します
    • 残念ながら絶版本なので、古本在庫が尽きたら異常に値段が上がりそうです。早めに買うことをおすすめします

クラスライブラリのソースコードに迫ってみる

内容の割に長かったためかボツになったのがこれです。
特集の本文で紹介したように、.NET FrameworkではCLRとクラスライブラリの組み合わせによって実行環境で要求される機能を実現しています。
これらの中身にもっと迫ってみることはできないのでしょうか。
Microsoftは2014年の暮れに.NET Frameworkのソースコードを一部MITライセンスという非常に制限の少ない(利用者側の自由度が高い)ライセンスで一般公開しました。この中をたどっていくことで、CLRの実装詳細やクラスライブラリの中身を追いかけることができます。ここでは、.NET Frameworkが提供する機能のソースコードを追いかける例を紹介します。
C#でプログラムを書いていて、プログラムの状態をデバッグ出力することがしばしばあります。Cプログラミングでいうところのprintfデバッグの類です。多く利用される方法はSystem.Diagnosticsパッケージに含まれるDebug.WriteLineメソッドの利用です。この部分はオープンソースで公開されているので、コードを完全に追いかけることができます。
試しに追いかけてみましょう。
以下の説明でのソースコードはMicrosoft社がMITライセンスにてGitHubで公開しているreferencesourceの抜粋です*2。
まず、.NET Frameworkが提供するDebug.WriteLineメソッドにはいくつかのオーバーロードがありますが、ここでは
 Debug.WriteLine("Help me!");
というコードを書いた場合のクラスライブラリ側コードを追いかけてみます。
まず、Debug.WriteLineメソッドはSystem/compmod/system/diagnostics/ディレクトリ以下のDebug.csを起点として呼び出されます。この中でstringを受け取るオーバーロードを探すと
 [System.Diagnostics.Conditional("DEBUG")]
 public static void WriteLine(string message) {
     TraceInternal.WriteLine(message);
 }
が見つかります。
TraceInternalクラスは同ディレクトリにあるTraceInternal.csで定義されています。その中で、呼びだされているWriteLineメソッドは次のとおりです。
 public static void WriteLine(string message) {
   if (UseGlobalLock) {
     lock (critSec) {
       foreach (TraceListener listener in Listeners) {
         listener.WriteLine(message);
         if (AutoFlush) listener.Flush();
       }
     }
   }
   else {
     foreach (TraceListener listener in Listeners) {
       if (!listener.IsThreadSafe) {
         lock (listener) {
           listener.WriteLine(message);
           if (AutoFlush) listener.Flush();
         }
       }
       else {
         listener.WriteLine(message);
         if (AutoFlush) listener.Flush();
       }
     }
   }
 }
ここではロックの取得方法によって処理が2パターンありますが、いずれもListenersからTraceListenerを取り出してそれぞれに対する出力処理をしていることがわかります。
同じファイル内を読むと、Listenersはプロパティとして宣言されており、このプロパティを最初に取得するタイミングでデフォルトの内容が作成されることがわかります。ここで実際に生成されるのはDefaultTraceListenerのインスタンスです。
DefaultTraceListenerのコードはDefaultTraceListener.csにあります。WriteLineメソッドの中でWriteメソッドを呼び、その中でinternalWriteメソッドを呼び出しています。
internalWriteメソッドの記述は次のとおりです。
 void internalWrite(string message) {
   if (Debugger.IsLogging()) {
     Debugger.Log(0, null, message);
   } else {
     if (message == null)
       SafeNativeMethods.OutputDebugString(String.Empty);
     else
       SafeNativeMethods.OutputDebugString(message);
   }
 }
デバッガでのログ出力が有効であればメッセージをデバッガへ流し、そうでなければSafeNativeMethodsOutputDebugStringメソッドを呼び出しています。
この実体はSystem/compmod/microsoft/win32/SafeNativeMethods.csファイルの次の部分です。
 [DllImport(ExternDll.Kernel32, CharSet = System.Runtime.InteropServices.CharSet.Auto, BestFitMapping = true)]
 [ResourceExposure(ResourceScope.None)]
 public static extern void OutputDebugString(String message);
ここでWindows用のDLLへのバインドをおこなう処理が登場しました。これで、あとはWindows APIの領域です。OutputDebugString APIのリファレンスはhttps://msdn.microsoft.com/ja-jp/library/cc428973.aspxにあります。
なお、GitHubのreferencesourceリポジトリに存在しないコードでも、.NET Frameworkのライブラリは2008年から閲覧専用のライセンスで公開されています*3。原稿執筆時点では、最新の.NET Frameworkである4.6.1のソースコードが公開されています。
たとえば本文のPart 1で作成した.NET Frameworkでメッセージボックスを表示するプログラムについて、挙動がおかしいとします。その問題を調査したり、フレームワークとの適合度を高めるための用途であれば、ここのソースを読むことができます。しかしコードをコピー&ペーストして利用したり再配布するような行為は禁止されている(GitHubのreferencesourceリポジトリにあるものと違って、ライセンス上の制限がかなり厳しい)ので注意が必要です。
[*2] ライセンスの全文はhttps://github.com/Microsoft/referencesource/blob/master/LICENSE.txtで公開されています。

サブシステムの概念を簡単に補足

特集の中では細かな事情として省くことになったのですが、Windowsの構造について話をしていくと避けて通れないのがサブシステムです。
Windowsはもともと多様なアーキテクチャの実行ファイルを実行できるように設計されています。Windows向けのexeファイルは素直に実行されますが、たとえばUNIXの仕様に基づくPOSIXサブシステム(以前SFUと呼ばれていたもので、最近のWindowsではSUAと呼ばれます)を利用するものはposix.exeというプロセスがホストする形で実行し、psxdll.dllをライブラリとして利用します。
WindowsなのになぜUNIX標準にもとづくプログラムを?と思うかもしれません。これには歴史的な事情があり、1980年代の米国政府が業務に利用するOSの調達要件としてPOSIX.1というUNIX標準への準拠を必須としていたためです。Windows 8の時代まで、Enterprise版のWindowsはSUAをサポートしていました。Windows Server 2012 R2およびWindows 8.1ではSUAが削除されました。代わりにUNIX系の機能をWindows上で利用したい場合にはHyper-Vで仮想化されたUNIX系OSを利用したりCygwinのような仕組みを利用することを推奨するようになりました。
また、Microsoftが2015年の4月に発表した「AndroidアプリをWindows上で動作させる」仕組みであったProject Astoriaは、Windows上にAndroidサブシステムを実装してプログラムを実行するという構造をとっていました。これも残念ながら2016年2月にプロジェクトの終了が発表されました。
このように、Windowsはシステムコンポーネント次第でさまざまな役割を果たすことができるように設計・実装されてきました(ビジネス的に成功しているかとは別に、このような拡張をおこないやすい内部アーキテクチャというのが肝要です)。

補足やセルフツッコミ

以下では、もう少し書きたかったけれど紙面の都合上削ることになったものや、少々蛇足で雑誌媒体には合わずカットとなったものなどを挙げていきます。
原則的に紙面の各文言へセルフツッコミを入れていく形で書いてみます。

p.9 テキストかバイナリか的な話

でも、テキストエディターで記述したソースコードは、あくまでテキスト形式です。このままでは、コンピュータは実行できません。
EICARテストファイルというものがあります(http://www.eicar.org/86-0-Intended-use.html)。これは完全にASCIIの範囲のテキストのみで書かれた、アンチウィルスソフトの動作確認用ファイルです。
COMという(Component Object Modelでないほう)実行形式として正当なものであり、32-bit版のWindowsでは実行可能です(64-bit版のWindowsではCOMファイルを実行できないので、残念ながら最近の多くの環境では実行して試せないのですが)。こういう変わり種もありますが、バイナリ芸のエリアですね。

p.13 フレームワークのくだり

Webアプリを作成できるようなライブラリ群を指します。
もちろんWebアプリに用途を限定しているわけではありません。文の収まりの都合です。

p.13 コラム コンパイルして実行か逐次実行かというくだり

ただし、現在のスクリプト言語では、すべてを逐次実行しているわけではありません。プログラムの起動の高速化や、実行速度の改善のために様々な処理を実行前に施しています。
そういうわけで、JSがJITコンパイルの領域で世界の先端エリアまで行っていたり、PyPyがCPythonより(コード種にもよりますが)何倍も速くコードを実行できる現代に我々は住んでいます。ASP.NET Coreなどでは原則的に事前のCIL生成・アセンブリ生成を捨てて「実行時コンパイルでいいよね?」と来ているわけですし、扱い方の容易さでいうともはやほぼJSです。
個人的には、事前コンパイルをおこなって中間言語コード・アセンブリを出力しておく言語群とそれ以外との切り分けは近年ほぼ意味を成さなくなってきていると思っています。実行までにかかる計算資源をどのフェーズへ押し付けるかという判断にすぎないので(例示するとGolangにはすばらしいgo runというサブコマンドがあり、実行時に一時ディレクトリでバイナリをビルドしてから実行するスタイルもとれるわけです)。

p.13 フレームワークについて

本文のどの場所というわけではないのですが、フレームワークというフレーズは本当に界隈と人によって持つイメージが違うものです。
たとえばiOSだとずいぶん小さめの粒度でフレームワーク(framework)という言葉を使います。インポート可能なパッケージの、パッケージングフォーマットというレベルでの利用です。いわゆるシステムフレームワークはかなり大きな規模で切り分けられたものですが、ユーザが好きに作って配布できるフレームワーク(*.framework)はnpmやgemのパッケージレベルです。

p.15 コラム

「corflags.exe」です
結局本文では使いませんでしたね。dumpbin.exeで事足りるケースも多いのです。書き換えをしたい時にはcorflags.exeを利用します。

p.16 バイナリを読むのはむりという話


こういう人も居るので、世の中面白いのです。

p.18 CILディレクティブとCILオペコードのくだり

CILディレクティブは、コンパイラやランタイムによるコードの最適化に利用されます。処理内容ではありません。
最適化だけではなくてもちろん.entrypointとか、実行するコードパスを決定するのにも利用されます。

p.20 SxSマニフェストのくだり

.NETアプリのプログラムでは、後述するマニフェスト（SxSマニフェスト）もこのセクションに格納します。
SxSマニフェストは.NET固有事情によるものではないのですが、確認した限りはVSからの標準ビルドで常時出力されているのでこのように記載しました。

p.21 マニフェストたち

ややこしい話ですが、マニフェストには2種類あります。
実際は、まだあります。.NETとWindows界隈、便利な言葉ゆえ「マニフェスト」というのを多用します。

p.22 DLLへ処理を切り出す動機のくだり

DLLが多用される理由は、ライブラリによって勝手に再配布することが許されないものがあるからです。
アプリの配布サイズが増えることを許容すればバージョン差異による問題を避けられるのになんで、という話を先回りした話です。たとえばPhotoshopの内部DLLとかを勝手に同梱して配布したら猛烈に怒られますからね…。

p.22 DLLにコードを切り出す恩恵

つまり、メモリーの節約につながるのです
これは主にシステムコンポーネントの話ですね。ユーザコンポーネントだと、Chromeのように大量のプロセスを生成するプログラムでは恩恵大きいはずですが、普通はせいぜい2-3しかプロセスを立ち上げないのでメリットそこまで大きくありません(無理に切り分けるほどでもないの意)。

p.24 カーネルというかntoskrnl.exeの話

「ntoskrnl.exe」 または「ntkrnlpa.exe」
ほかにもntkrnlmp.exeやntkrpamp.exeがあります。なんと、このあたりはWikipediaに分かりやすいサポート特性リストがあります(Ntoskrnl.exe)。
ちなみに手元の64-bit Windows 10環境では ntkrnlmp.exeです。PAE不要ですしね。

p.28 CILコードからWindowsのAPI呼び出しまでの話

この処理は、CLRの内部でWindowsのMessageBoxWというAPIの呼び出しに変換されています。
CLRの内部というのは嘘ではないですが、実際にこの変換をしているのはFX側ですね。
このことはソースを参照するとわかります。この部分のコードは残念ながらGitHubのreferencesourceリポジトリには含まれないので、制限付きのほう(前述の、ソースコードを探っていくくだりを参照してください)で読むことになります。

p.31 なんでWinRTが出てきたのかという話

これらの処理を実装するために、従来のWin32 APIとは異なる新しいAPIセットが必要だったのです（図1）。そこで登場したのが、Windows 8 で導～
アプリライフサイクルが大きく違うというのもありますね。なにぶんモバイルではバッテリ消費をおさえやすい構造にする必要があったのだし。
タブレットでは、うん。その後にWinRT専用タブレットが消滅したのを見ると、WinRT専用へ振り切るのが早すぎたのは間違いありません。Win32APIの重要度というか、「デスクトップが今まで通りにあってOfficeがこれまで通りウィンドウ状態で動く」というあって然るべきUXを激変させるのがキツかったという話かなと。

p.31 2種類のWindows

と、Windows Phone向けの「Windows Phone 8」という2 種類のWindows系OSが存在しました。
もちろんCEというかWEC(Windows Embededed Compact)もね!

p.33 UWPのパッケージングの話

つまり、2 種類のバイナリファイルを生成してパッケージ内に含めることになります。
もっとも、だいたいx64も別にするので3種類ですけれどね!MIPS増えないかなー(増えない)。
投稿者 Unknown 時刻: 10:28 0 コメント
ラベル: ,

Project Oxfordに話者識別APIが追加されていた (Technet ML blogメモ)

2016年3月23日水曜日

Oxford?

Project Oxfordは、簡単にいうと「Microsoft(Research)のすごい研究成果をAPIで提供するもの」です。CV(Computer Vision、画像認識)や音声認識など、多彩なAPIを提供しています。
サービス概要と音声認識APIの簡単な使い方はWindows & Microsoft技術 基礎 Advent Calendar 2015枠で書いた誰も知らない凄いヤツ はじめようProject Oxfordのエントリで簡単に紹介したので、よければ参照してください。
実はこのエントリとタイミングが被っていたのですが、2015/12/15に音声認識APIが強化されていました。今回はその話です。
TechnetのMachine Learning blog内のhttps://blogs.technet.microsoft.com/machinelearning/2015/12/14/now-available-speaker-video-apis-from-microsoft-project-oxford/という記事(Ryan Galgon氏によるもの)のメモです。
一般的な認証の話は端折って、話者識別API(Speaker Recognition APIs)の話へ行きます。

話者識別APIの概要

話者識別APIは、「話者登録」と「話者識別」という2つのフェーズに分解できます。

話者登録

話者登録段階では、話者の音声を記録して個人を特定するのに必要な声紋(voiceprint)を抽出します。これらは話者の口や喉の物理的な構造に由来するもので、数式であらわせます。
話者識別時には、この声紋情報を利用して識別をおこないます。

話者識別

話者識別はさらに「話者検証(speaker verification)」と「話者特定(speaker identification)」のコンポーネントにわけられます。
話者検証は認証向けのシナリオで利用されるものです。話者登録と話者識別の際に特定のパスフレーズを唱えて認証するイメージです。この精度は実験上90%以上、拒否率5%*1とありました。
話者特定は、入力音声の話者を複数人の候補者の中から特定するものです。これは話者検証と違って、話している文章に依存しません。
※原文にはi-vector話者識別モデルの構造概要が書かれているので、興味があれば読んでみてください。
[*1] 原文にrejection rateとあるのですが、false rejection rateつまり本人拒否率の意味だと解釈しました。

その後

Project Oxfordプロジェクトサイト上でのAPI紹介はhttps://msdn.microsoft.com/en-us/library/mt612813.aspxにあります。
APIリファレンスはhttps://dev.projectoxford.ai/docs/services/563309b6778daf02acc0a508/operations/5645c3271984551c84ec6797ですね。
話者検証(speaker verification)APIでは確度情報をHigh/Middle/Lowで返してくれるので、使い方によっては便利そうです。認識対象の音声は1秒以上15秒以下という制限があるので、事前に沈黙部分をカットしておくのがよさそうです。
話者特定(speaker identification)APIでは事前に登録した話者候補情報を渡すのですが、ここで渡せる最大数は今のところ10です。また、複数人の会話から部分ごとに話者を識別するようなことはできないのに加えて、沈黙状態を除いて60秒以上のサンプルが必要という制限が書かれています。
まずは自分で使ってみないと。使ったらまた書きます。

about

このエントリは、TechnetのML(Machine Learning) blogから面白そうなエントリを掘り出してポイントをまとめるシリーズのものです。
前回: AzureにデータサイエンスVMなるものが増えていた (Azure ML blogメモ)
次回: 未定
投稿者 Unknown 時刻: 9:00 0 コメント
ラベル:

AzureにデータサイエンスVMなるものが増えていた (Azure ML blogメモ)

2016年3月22日火曜日

Azureでササッと立ち上げられるVMとしてデータサイエンス向けのものが増えていたという話です。
TechnetのMachine Learning blog内のhttps://blogs.technet.microsoft.com/machinelearning/2015/11/23/announcing-the-availability-of-the-microsoft-data-science-virtual-machine/という記事(Gopi Kumar氏によるもの)を読んだメモです。
2015年の暮れに公開されていたのですが、全然気付いていませんでした。

データサイエンスVM、なにそれ

AzureのMarketplace(公式やサードパーティのさまざまなVMイメージを探して利用できる仕組み)で作れる、Windowsベースのデータサイエンティスト向けのもろもろ入りVMイメージです。めっちゃすごいもの、というわけではないのですが、環境構築の手間を減らしてくれるえらいやつです。

入っているもの

リストは前述のblogからほぼそのまま抜粋し、コメントをそれぞれにつけていきます。
ここまでは「え、それ普通にUbuntuベースのDockerイメージあたりでよくね?」という感じですが、ここからがWindowsベースのイメージであるうれしみを感じるところです。
  • Visual Studio Community Edition
  • Power BI Desktop
    • 比較的手軽なビジュアライズではやはり強いですしね
  • SQL Server Express Edition
    • これは正直なところいまひとつピンと来ませんでした。本当に規模の小さなデータを扱うとか、お試し利用というタイミング以外はおそらくリモートのSQL Serverインスタンスを利用するだろうなーと思うので
    • まあしかしローカル実行(クラウド上ですが)というのはどの環境でもあるに越したことはないので、全部入りパックに入れておくのは妥当とも思います
  • Azure SDK
    • データを読み込んでくるにも、加工して書き出すにも、何かと使いますからね。大事ですね
しかしカジュアルにVS Community版を入れてくるのは、ライセンス的に企業内利用は微妙なところがありますね。21世紀は個人の時代だ!万歳!!(なんか違う)。
実際に使う際の注意はhttps://azure.microsoft.com/en-us/documentation/articles/machine-learning-data-science-provision-vm/に事細かく書かれているので読んでスタートするのがよさそうです。

about

このエントリは、Azure ML(Machine Learning)のblogから面白そうなエントリを掘り出してポイントをまとめるシリーズです。
前回: Visual StudioのRサポートで出来ること (Azure ML blogメモ)
次回: Project Oxfordに話者識別APIが追加されていた (Technet ML blogメモ)
投稿者 Unknown 時刻: 9:00 0 コメント
ラベル: ,

.NET Coreのdotnetコマンドを試そうとしたら試せなかった

2016年3月19日土曜日

ASP.NET 5(現ASP.NET Core)を追っている方々には旧聞ですが、Kコマンド群がdnvmやら何やらになった(C#でのクロスプラットフォームなコマンドラインツール開発に良いかもと考えながら最近のASP.NET 5事情を調べた)と思ったら半年も経たないうち(2015年のうち)にまた変わりました。
公式の導入手順を見ると、従来通りのコマンド群だけでなくdotnet newなる環境新規作成コマンドが増えたようです。
ひとまずさっと試してみましょうか。

Docker環境でサクッと試・・・せない

さっそく公式Dockerイメージを利用して簡単に使ってみます。環境はいつもどおり、MacBook 12"上のdocker-machine(+VMware Fusion)です。
$ docker run -it microsoft/dotnet:latest
Unable to find image 'microsoft/dotnet:latest' locally
latest: Pulling from microsoft/dotnet
33f2093de5ed: Pull complete
e9e1e0eafa26: Pull complete
9b3cff7cff0e: Pull complete
3bf9da1b9bd0: Pull complete
0944fb75f38c: Pull complete
e81712b127cd: Pull complete
93e08f996847: Pull complete
86a4030bdcde: Pull complete
Digest: sha256:5128c18cc89d9bb8b3619f3ad3437d173d1d311ea317268a8398be140bf48096
Status: Downloaded newer image for microsoft/dotnet:latest
しばし待って完了です。
root@2afc10bf759a:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@2afc10bf759a:/# mkdir hello
root@2afc10bf759a:/# cd hello/
root@2afc10bf759a:/hello# ls
root@2afc10bf759a:/hello# dotnet new
Created new C# project in /hello.
コンテナ環境内でチュートリアルに従ってnewをおこないますが、なかなか終わりません。気持ち的には一瞬で終わってほしいコマンドで、特にprogressが表示されるわけでもないので不安になります。

状況

15分ぐらい待ち、諦めてコンテナごとdocker killを試みるも反応なし。結局docker-machine stopコマンドでホストVMごと停止して再起動しました。
dotnet restoreなどを叩いても同様(VMware FusionのVMがシステム時間を食い尽くして応答しなくなる)なので、何かおかしそうです。
ひとまず環境情報を書いておきましょう。
$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.1
 Git commit:   a34a1d5
 Built:        Sat Nov 21 00:49:19 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Linuxホスト上で実行してみる

原因を切り分けるために適当なコンテナホスト上で作業をしてみます。
なお、対象のビルドは現時点でlatestタグの打たれているhttps://hub.docker.com/r/microsoft/dotnet/builds/btl9c2jpeyehe89ivzdvfcr/です。
unameの結果は
3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 12:59:02 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 12:59:02 UTC 2015
 OS/Arch:      linux/amd64
はい。
$ docker run -it microsoft/dotnet:latest
Unable to find image 'microsoft/dotnet:latest' locally
latest: Pulling from microsoft/dotnet
33f2093de5ed: Pull complete
e9e1e0eafa26: Pull complete
9b3cff7cff0e: Pull complete
3bf9da1b9bd0: Pull complete
0944fb75f38c: Pull complete
e81712b127cd: Pull complete
93e08f996847: Pull complete
86a4030bdcde: Pull complete
Digest: sha256:5128c18cc89d9bb8b3619f3ad3437d173d1d311ea317268a8398be140bf48096
Status: Downloaded newer image for microsoft/dotnet:latest
root@880ccf5e3177:/# mkdir hello_world
root@880ccf5e3177:/# ls
bin   dev  hello_world  lib    media  opt   root  sbin  sys  usr
boot  etc  home         lib64  mnt    proc  run   srv   tmp  var
root@880ccf5e3177:/# cd hello_world/
root@880ccf5e3177:/hello_world# dotnet new
Created new C# project in /hello_world.
固まりました。
docker killでも殺せません。

結果

issue作りました。Docker 1.10系を使えばよさそうな雰囲気ですね。

雑感

せっかく関連コマンド群を1つに集約したのだから、Docker環境内へdotnetコマンドを隔離しつつホスト側環境のファイルをいじるのをデフォにしたいところですね。本来はこっちの話を書きたかったのですが、存外まともに動いていなかったので1回休みの格好です。
あと、チュートリアルとしてはDockerコンテナ作成時に--rmオプションを付けて終了即削除にしておいたほうが何かと楽(Dockerをよく知らない状態だと、大量にたまってきたコンテナの残骸に気付かず厄介事になりやすい)かなと思いました。感想ですが。
投稿者 Unknown 時刻: 15:39 0 コメント
ラベル: ,

MacBook 12"の電源用USB-Cケーブルのリコール代替品が届いた

2016年3月14日月曜日

2016/02/12にAppleの公式サイトでApple USB-C 充電ケーブル交換プログラムというページが公開されました。
これは、MacBook 12"(Retina MacBook)で採用されている電源用のUSB-Cケーブル(2m)の設計上の不具合により充電できなくなるケースがあるという問題への対応とされています。
実はこの問題には私も心当たりがあり、2015/08/04の時点で


とぼやいていました。
ケーブルの値段が高いので、本格的に使えなくなったらかなり凹んでいたところですが、修理で持ち込むのも相応に面倒だったので逆側を挿して問題なく使っていました。
MacBook をお持ちのお客様のうち、製品登録時または Apple Online Store でのご購入時に有効な住所をご記載いただいた方に対しては、2016 年 2 月末までに新しい充電ケーブルを Apple からお送りさせていただきます。
と前述のページにある通り、私の手元にも早速2/17に代替品が届きました(図1)。
図1 USB-Cケーブルの代替品
配送はヤマトのメール便あらためクロネコDM便でした(図2)。
図2 ヤマトDM便
DM便の中には、製品のパッケージが二重になっていました(図3)。
図3 梱包内のパッケージ
DM便の中には交換に関するお便りが入っていたのですが、「勝手に文書アップするなよ!」(意訳)という文言が含まれていたのでチキンな私は載せないことにしました。
予備用に購入した追加ケーブルも(まだ確認していませんが)おそらく交換対象品なので、気が向いた時に交換手続きをしようと思います。
投稿者 Unknown 時刻: 23:45 0 コメント
ラベル: ,

Visual StudioのRサポートで出来ること (Azure ML blogメモ)

Azure ML blogを眺めていて、最近少し話題になっていたVSでのRサポートの記事を見かけました。Announcing R Tools for Visual Studio(Shahrokh Mortazavi氏によるもの)
今回はこの記事についてざっとメモしてみます。
といっても統計は専門ではないので、気の利いた突っ込みは入れられないのですが。Rが強力な統計処理言語というのは知っていて、元々はSインスパイア系だったこと、最近ではSよりもRのほうが一部界隈で支配的ということ、あたりを前提にはします。

Visual StudioでのRサポート

R Tools for VS(RTVS)のプレビュー版はR Tools for Visual Studioから入手できます。RTVSはOSSであり、GitHubのRTVSリポジトリにて公開されています。
スクリプトや関数の編集、IntelliSense、書いたコードの即時実行結果確認などの基本的～近代的な諸々の機能を持つ旨が記載されています。VSらしく、デバッグ系の機能としてブレークポイントの設置やステップ実行、コールスタック出力などが充実していると記載されています(が、プレビューはプレビューなので、Android NDKの時の初期版を思い出し、広い心が求められそうという感覚で居ます)。
一方、パッケージマネージャのGUIやVSCでの動作サポートは将来のバージョンでおこなうとあります。
Azure MLとの親和性の良さをアピールしていて、CRANに登録されているAzureMLパッケージを入れておけばクラウド対応の分析コードをサクサク書けるとしています。

気持ち

今のところ、Rを使う場面がほとんどないのですが、Azure MLでRを書きたくなったらきっと利用する拡張機能だろうなという感想です。Azure ML自体の機能強化についても半年近く見ていないのでそろそろ確認しないと。

about

このエントリは、Azure ML(Machine Learning)のblogから面白そうなエントリを掘り出してポイントをまとめるシリーズです。
前回: 「7日間で集まった5,000万人のユーザから学べるビッグデータの話」 (Azure ML blogメモ)
次回: 未定
投稿者 Unknown 時刻: 23:34 0 コメント
ラベル: ,
登録: 投稿 (Atom)