授業の準備
今日は授業の準備をしました。
2012年前期は、情報工学実験II・プログラミング演習１・プログラミング演習３の三つを担当。
今年度は基本的には先人の作った資料をそのままトレースする方針ですが、良く理解しておく必要があると思います。
情報工学実験IIは、学部3年生の実験で、ネットワークの担当。pingでの通信速度測定と、雑音重畳時の誤り率測定が主な内容。去年まではアナログオシロでEthernetの電圧を見ていたみたいですが、この前の引き継ぎでディジタルオシロでパケットの直接観測が出来ることが分かりました（10Base-Tなので、実験室のオシロ(40MHzのやつ）でも十分パケットが見えます。（流石にビット単位では見えないが））。その辺のことを踏まえて、実験資料を修正してみました。コピペ対策のために、去年とは違う課題を考えなければ。
参考）アジレントとのApplication Note 1600で、綺麗な波形が見えてます。
http://cp.literature.agilent.com/litweb/pdf/5989-7528JAJP.pdf
10Base-Tでも100Base-TXと同様に+1/-1Vの信号電圧が使われているのでしょうか？波形を見るともっと大きい気もします。仕様を見たらよいのでしょうが、まだ調べきれていません。
情報工学科の学生が相手なので、あまり電気的なことで立ち入りすぎると引かれるかもしれないが、、、興味を持ってくれたらよいなと思います。
プログラミング演習１は、学部2年生の演習、C言語。ソートが担当です。ITをやっている人にとっての基礎教養なので、頑張って身に着けてもらいたいと思います。既存の資料が秀逸なので、そのままで引き継げば良いかと思います。車輪の再発明はしないのです。
プログラミング演習３は、学部3年生の演習、C++言語。その中の【中級編】（入出力ストリーム・名前空間・参照およびコピーコンストラクタ・フレンド・演算子オーバーロード）が担当です。フレンドはオブジェクト指向の設計からしたら存在意義を疑われるようなものですが、世の中のコードには多く含まれているわけですから、学生に教えないわけにもいきません。
試しにC++のヘッダの中（/usr/include/c++/4.4.4）を調べてみましたが、friend結構います。
現状のカリキュラムがC/C++中心の演習なのですが、今後は卒論の研究に直接役立つように＋社会の要請に併せていく必要があるな、とは思います。
スキー
初めてスキーをしたのは中学二年生の時に行った菅平学園のスキー旅行だったと記憶しています。杉並区の中学校はほぼみんな菅平学園にスキーに行くのだと、当時聞いた覚えがあります。杉並区の施設だったんですね。そんな菅平学園は平成15年に廃止になったそうです。
今日はハンターマウンテンに家族でスキーに行ってきました。
５歳の娘が本日２回目のスキーだったのですが、滑り終えて駐車場まで歩く時になって歩きたくない、と言い出して泣き出しました。いつも甘えているので、少しは歩かせようと思って「歩きなさい」ときつく叱ったのですが、大号泣。車についてから聞いたら足が痛かったとのこと。
そういえばスキーを始めた頃はスキーの靴を履くのが不慣れで、一日滑ったり歩いたりした後は、足が痛くなっていたことを、後になって思い出しました。反省しています。
GarbageCollection
以前の職場にいた同僚(Postdoc・外国人)が言っていた言葉を思い出しました。
「DoctorはGarbageCollection(GC)されるんだよ。Doctorオブジェクトは生まれて、Tenureになったものは生き残るけど、そうでないものはGCされてJunkになる。」
ここでいうDoctorといのはお医者さんではなく我々のような博士なのですが、特に印象に残っているのは「Junkになる」の部分です・・・
これの元ネタはJavaVM1.3以降に搭載されている世代別GC(Generational Garbage Collection）という、ガベージコレクションの一手法です。ガベージコレクションは、もう使われていない（参照のリンクが切れた）オブジェクトのメモリ領域を解放する処理ですが、処理中はStopTheWorldといって基本的にはプログラムの動作の一切を止める必要があります。
で、GCにかかる時間を少なくするために、オブジェクト置場のメモリ領域を2つに分けて、すぐ使われなくなる短命なオブジェクトの領域と、ずっと存在し続けるオブジェクトの領域を作ります。前者をYoungGeneration、後者をOldGenerationといいます。YoungGenerationは積極的に回収を行い、OldGenerationはメモリ領域が不足するようだったら回収する、というのが基本方針です。また、YoungGenerationでの回収を一定回数生き延びたオブジェクトは、OldGenerationに移されます(Tenured領域といいます)。
なんか、Doctorと一緒ですよね。
GCによる回収を逃れる方法というのがあるのですが、それはObjectPoolというやつです。参照のリンクが切れないように、親玉のObjectに常に参照していてもらうようにする、という方法ですね。（本来は、オブジェクト生成のコストを削減する目的で使う。）
若い世代だけで参照し合っていてもバッサリ切られてしまう可能性は消えないので、やはり親玉が必要なのです。もちろん、OldGenerationの親玉もGCされてしまう可能性がないわけではないのですが。
参考：
ITPro Java技術最前線「メモリーを意識してみよう」 第2回 GCの仕組みを理解する
http://itpro.nikkeibp.co.jp/article/COLUMN/20060612/240657/
ThinkIT 連載：GoF以外のデザインパターン 第2回 Object Poolパターン
http://thinkit.co.jp/article/934/1
Xilinx EDKについて雑感
FPGAを使い始めたのはいつからだったかと思い返してみると、産総研に入所してからでした。それまでは東北大学でFPGAみたいなLSIとしてフレキシブルプロセッサというものを研究開発していたわけだけど、FPGA自体をユーザーとして使った経験には乏しかったわけです。もっともその頃のFPGAはvirtex初代が出たぐらいの時代だったわけで、FPGA用のソフトコアプロセッサもようやく一般的になってきた頃だったように思います。
XilinxのEDKは、ソフトコアプロセッサであるmicroblazeと、メモリやペリフェラルを含むシステムをIPベースでハードウェアを設計できるツールです。そしてもう一つの側面が、gccをベースとしたソフトウェアの統合開発環境です。
ハードウェアを設計した際に、各IPにアドレスを割り付けて、その構成をもとにC言語のヘッダファイルを自動生成してくれる、という形でハードウェア設計とソフトウェアが結びついています。
難点は操作が重い事でしょうか。最新バージョン13では大分改善されているような気がしますが、バージョン8から10で使っていた時は、何かと待ち時間が生じていたように思います。その点、ライバルのALTERAの同様のツールSOPC builderは、軽快な動作でした。余計な機能を削ぎ落としてスッキリと作ってあるツールという印象です。
それからedkは、用意されているIPを使っている間はまだ良いのですが、自作のIPを入れてシステムを生成しようとすると、本当に良く異常終了しました。自作のIPが不完全なためなので、自業自得なのですが。
といったEDKなのですが、気になるのはどの位ユーザーがいるのか、という事です。FPGAがターゲットの場合、IPベースのシステム設計というのはとても有効だと思うのですが、日本ではあまり流行っていないように思います。上手く使っているのは、アットマークテクノのSUZAKUだとおもいますが、それ以外あまりネット上に日本語の情報がないですよね。EDKを使っていてエラーが出て検索すると、大体英語の情報が見つかります。
2008年ごろ、EDKユーザーwikiという日本語のユーザー情報交換のサイトを企画したのですが、上手く続ける事が出来ませんでした。再度、トライしてみましょうかね…？
いまさらORB？
私は2011年12月から宇都宮大学の情報工学科で助教をやっていて、4月からは色々と授業の担当がある予定ですが、それまでは研究のみをしていればよろしい、ということになっています。それで、今まで産総研でやったORBエンジンの仕事を論文にしていなかったので、この機会に論文にしようとしています。
ORBエンジンは、2007-2009年にNEDOの若手研究者向けの研究助成プロジェクトで作った、FPGA上で動作するCORBA（分散オブジェクト）プラットフォームで、日本版バイドール法により、現在は産総研の知財となっています。ORBエンジンのプロジェクトは、プロジェクトの途中で産総研での任期が切れることが決まったため中断しました。その後就職したベンチャー企業では、やはり会社の目標に直結する仕事を優先せざるを得ないため、ORBエンジンを活用する機会がありませんでした。
2009年に産総研を離れる際にORBエンジンはApacheライセンスにしたので、現時点ではオープンソースでありつつもGPLのように未来永劫オープンソースでなければならないものではありません。産総研が著作権を持つという表示を維持すれば、改造や再配布について制限はありません。ということで、先週やっと産総研からORBエンジンのソースコードの情報開示をしてもらいましたので、これから活用して研究開発していこう、と思っています。
で、「いまさらORB？」なのですが、ORBというのはObject Request Brokerの略で、オブジェクト指向の要求(リクエスト)すなわちメソッド呼び出しを、離れたプロセス間でやってくれるものです。プロセスというのは、メモリ空間が独立した処理のことです。簡単に言うと、離れたプロセッサ間でのメソッド呼び出しをする仕掛けなのです。
90年代にCORBA(Common Object Request Broker Architecture)というORBの共通規格が出来、分散システムを作る際に活用されてきました。95年頃からはインターネットの時代となり、00年代には、いわゆるエンタープライズ系の分散処理はWebServiceや.NETフレームワーク等にとってかわられました。実はCORBAはあまりインターネットと相性が良くなく、CORBA用のTCP/IPポートが複数必要なためファイアウォールを超えられないという問題があります。より本質的には、サーバントが1024番以上の高位ポートを開けてメッセージを待つというつくりになっているため、ポートを全開放しないといけないという問題です。そのため、クローズドなシステムの方が適していると言えます。
CORBAには非常の多くのプログラミング言語で相互に使用可能である、というメリットがあります。Java、C、C++、Python、COBOLなどなど・・・更にはErlangまで。また、CORBAそのものの仕様は膨大となっていますが、この先、更にCORBAを発展させようという機運よりも、CORBAの考え方でドメインスペシフィックなサブ仕様をつくるという動きが目立っているように思われます。例えば、自動車向けにはAUTOSAR、組込みシステム向けにCORBA/eという感じです。
そんな中で私がやろうとしている（いた）のは、ハードウェアをソフトウェアから駆動する際のインターフェイスの抽象度をORBの考え方でオブジェクトレベルに上げることで、情報システムの品質と設計生産性を上げよう、ということです。つまりプロセッサから、ハードウェア回路を駆動するのをオブジェクト操作メッセージの単位でやる、という試みです。
現在の普通のシステム開発ではデバイスドライバやAPIを用意して、C言語でハードウェアのレジスタやメモリを操作するというデバイスドライバの開発をするのですが、基本的にOS依存となります。つまり、Linux用とWindows用のデバイスドライバが必要ということです。
ハードウェアがORBの通信プロトコルを解釈できれば、OSに依存せずにハードウェアを駆動するソフトウェアを書くことが出来ます。ハードウェアが解釈すべき通信プロトコルは何だろう、と考えた時に、「オブジェクト指向ソフトウェアのメソッド呼び出し」というのは中立的で理想的なのではないかな、と思うのですが、いかがでしょう？
さて、分散ORBが威力を発揮するのは、「離れたソフトウェアプロセス間で、複雑なデータ構造を共有したい場合であったり、複雑な手順の操作を行いたい場合」です。つまり、「デバイスドライバが複雑で長大な場合」に、ハードウェアをORBで駆動するプラットフォームの有用性が発揮できます。
普通のAPI（プロセス間通信API）では、二つのプロセス間のデータの転送は、生データ転送（C言語であればchar、Javaであればbyte）にせざるを得ません。そうすると、アプリケーションに応じて、受信側プロセスが受信データを解釈可能な通信プロトコルを定め、送信側プロセスが送信データを作成して受信側プロセスが受信データを解釈する機能を設計し実装する必要があります。
アプリ（もしくはハードウェアデバイス）を作成するたびに通信プロトコルを定めて通信機能を実装するのは、通信を最適化できるので良いのですが、その分開発工数がかかります。
そこを解決するのがORBですが、通信プログラムを生成するプログラムを書く、という一段抽象度の高いプログラミングをする必要があり、余計に開発時間はかかります。なかなかバグフリーにすることも難しいです。
はじめました
少し長い文章を書く練習をするために、ブログを始めました。
FacebookやTwitterでさえあまり書けないのに、続くかどうかわかりませんが、とりあえず毎日1記事を目標に、ぼちぼち書いていきます。
ところでスタスタとは昔（95年ごろ）飼っていたハムスターの名前です。
ハムスターの名前として、「ハムハム」は良く聞きますが、「スタスタ」は余り聞きません。
試しに先ほどGoogleで、「ハムスター スタスタ」と検索してみましたが、ハムスターの名前として用いている様子はなさそうです。意外と独自性のあるネーミングが出来ていたことに驚きです。
産総研時代に、ファシリテーション研究会というのがあって色々と人間関係・組織運営のマインドやスキルを勉強しました。おいおいそのことも書いていこうと思うのですが、そこで学んだこととして、「やる気が出ないとき」「いやになってしまったとき」は、「原点に還ると良い」というフレーズが記憶に残っています。
私の原点はどこにあるのだろう、ということを考えるとき、やはり大学生時代というのが楽しかった記憶として残っているのです。それより以前の小学校・中学校・高校はどちらかというと少しあいまいな記憶のような気がします。スタスタというハムスターを飼っていた頃、それは私の原点となる時代の一つなのでしょう。この時代のことも、おいおい書いてみようと思います。
前の職場では２年半務めたのですが、ベンチャー企業ということもあり慢性的に忙しく人数が少ないため責任も大きい職場でした。１年ぐらい前、激務が３か月ぐらい続いた上に研究開発の仕事がうまくいかなかったことがありました。それでどうやら燃え尽きてしまったらしく、不安な気持ちで夜寝られなくなりました。妻に勧められて、会社のOさんに紹介してもらった精神科にかかると、先生は私の経歴を記入したカウンセリングシートを見ながら「素晴らしいじゃない」と、大学時代のことを思い出させるようなことをお話しされて、私は涙が止まらなくなりました。そして、先生の「人は壁にぶつかるんだよ」という言葉で、私は挫折したのだな、と認識したのです。
学生時代の研究室では日本の半導体産業を強くするための半導体プロセスとデバイスを研究するのだという夢を持って、その勢いのまま産総研では分散並行処理のためのハードウェア・ソフトウェア基盤をつくるのだというプライドを持って、マイクロプロセッサ開発のベンチャー企業に飛び込んで一人で何でもできるから何でもやってやるという自信を持って、突き進んできた気持ちを一度方向転換する必要に迫られました。
壁にぶつかった時は、やはり一度原点に返る必要があるのだと思いました。コンピュータやプログラミングが好きで大学の学部は工学部を選んだこと、学部生時代に友達とOSやゲームを徹夜で作ったこと、中学生時代にPC-88のマシン語でサウンドドライバやゲームを作って友達に見せて楽しかったこと、小学生5年生のときに図書館で「論理演算の仕組み」についての絵本に出会ったこと。
2011年12月からは宇都宮大学の情報工学科で助教をやっています。研究に関しては、自分が貢献できることは何なのかよく考えてテーマを設定していくつもりです。もう３か月になるので、そろそろ決めないといけないのですが。
