いよいよ3日後にPh.D defenceが迫っています。
友人が審査に通ったという報告が続々でてきて、ようやく緊張感が出てきました。
博士論文を提出してから1ヶ月近くの間、他の研究を進めていたので、うまくプレッシャーからくるストレスを回避できていたのかもしれないですね。
というわけで、今日の昼から発表スライドを修正して練習することにします。既に、研究室内で話したり、審査の先生方に直接会って研究紹介をしていたりするので、たくさん本番を経験しているのですが、そこでの経験を踏まえて、話がスムーズになるように調整するのです。
もちろん、何年も研究生活を続けているので、1時間でも2時間でも話し続ける自信はあります。研究の内容も自分で作り上げてきたものばかりなので。
こういう審査って誰にとっても初めてで、得体の知れないものだから緊張するんですよね。きっと、ポイントは、
・過去の研究と比較したときの、自分のmethodの利点
・学位に値する十分な仕事をしてきたこと
・本格的に研究するための素養を身につけていること
の3つを、審査の先生方にはっきりと伝えること。最後の1つは、話し方とか、内容にどれだけ自信を持っているか、など間接的に伝わるもの。
後で、いい報告をこのブログに書けますように。
2007年1月30日火曜日
2007年1月28日日曜日
[Mac] Macを使っていて…
開発者として一番がっかりしているのは、EclipseのMac版がどうにも洗練されていないこと。フォントも思ったように指定できないし、半透明色が使えなくてMacらしさがでなかったり…。なにより、動作がやや重い。Boot Campで、別パーティションのWindowsからEclipseを使っている分には、そのような不快さは感じないので、まだEclipseのコミュニティがMac版の開発に力をいれていないのかと思います。
逆にすごいと感じたのは、OS自体の言語環境切り換えがスムーズなこと。普段英語圏のアプリケーションを使用することが多いので、OSのインターフェースを英語に切り替えたくなったりするのですが、 Windowsでは英語版をインストールしなくてはいけないのと違って、Macでは設定一つで瞬時に使用言語を切り替えることができます。過去の遺産をあまり引きずっていないから、最初から他言語に対応できるようにするなど、柔軟な設計ができているのかもしれませんね。
逆にすごいと感じたのは、OS自体の言語環境切り換えがスムーズなこと。普段英語圏のアプリケーションを使用することが多いので、OSのインターフェースを英語に切り替えたくなったりするのですが、 Windowsでは英語版をインストールしなくてはいけないのと違って、Macでは設定一つで瞬時に使用言語を切り替えることができます。過去の遺産をあまり引きずっていないから、最初から他言語に対応できるようにするなど、柔軟な設計ができているのかもしれませんね。
Bloggerのupdate
このブログに使っているBlogger がupdateされました。更新が反映されるまで時間がかかったりと、やや不安定なのですが、レイアウトの変更などCSS を触らずにできるようになったので便利になりました。ようやくブログにタグもつけられるようになりました。これで、一通りの機能はそろったのかな。
2007年1月25日木曜日
[Research] MonetDB/XQuery
ここ2日で論文をたくさん読みました。 今年に入ってから37本PDFをダウンロードしたようです。さすがに全部は読みこなせないですが、一応目を通して、知りたいことがあれば深く読んで。。と。現代人だからこそできる手法。昔の人はどう研究してたんだろう。不思議で仕方がないです。
内容は、Compressed Index, Data Modeling, MonetDB/XQueryに関して。圧縮索引は、うまくブロック化すれば結構XMLに使えるんじゃないかと思うのです。去年の最新の結果だと、括弧木やその変形構造上でのrank/select操作で、木の探索とか、簡単なpathの探索をやってしまおうというもので、コンパクトで検索も速いし十分実用的。ただ、XMLのデータを表現するときに、0/1で表現された括弧以外の情報(タグ名とか、node id, pre, post order, levelなど)もディスク上の近い位置に保持されていてほしいわけで…。うまく使うのがとっても難しい。下手にそういう情報をまとめてしまうと、今度は圧縮しやすい構造ではなくなってしまうので。
というわけで、圧縮索引はおいておいて、おとなしく、普通にXML DBのsurveryに戻りました。最近やけに話題になっているMonetDB/XQuery。SIGMOD2006で発表を聞いてきたときは、relational algebraにXQueryを落とし込んで、最適化するとスケジュールも小さくなって、速くなりました!と、詳細を省いた発表だったので、インパクトが伝わらなかったのだけれど、論文をみると、過去数年の研究の集大成論文になってたんですね。これ。
面白い点は、
- for loopなど各iterationの状態をtableに押し込んで、relational algebraで表現できるようにした
なるほどねぇ。これは確かに新しい。loopをまたがった最適化も表現しやすくなるし、納得。TAXのようなパターンツリーベースのXML algebraだと、こういうところまでoperationを分解できないような気がします。
- purely relational: このアプローチ、当初は、既存のRDBにXMLエンジンを埋め込みたいというところから始まっていたと思うのだけれど、合理的な部分が見えてきました。ノードとかテキストに特殊な索引をつけてXMLの問い合わせを速くするなんて方法と、algebraを分離できるんですね。特殊なindex structureが使えるなら、それにあわせてalgebraを組みなおすこともできるので、relational algebraの枠組みで全部表現できる。ここはelegantですね。
逆に、主張しているほどすごくなさそうな部分。Stair-case joinは、単に一度触ったページ部分には二度触れないというだけなので、最初の論文からあまりインパクトはなかったと思います。
- updateができる: うーん。たしかにノードの挿入に対処するのにlogical number使いたいのは、みんなわかってるのだけれど、(挿入に強いordpathはラベルが長くなりがちだし)、挿入した位置以降のpage ID -> logical offsetのmapは全部書き換え。このオーバーヘッドって大きいんじゃないのかな。。。 あと、やっぱり木の移動は削除、挿入になってしまうし。。。
- ancestoreの問い合わせ、結局、候補のノードのpost = pre + size - levelを計算するまでancestorだと判定できないから、context nodeの位置によって影響を受けやすいのかも。まぁ、preだけのindexから、順々に親をたどってもさほど遅くはないのですが。
あと思ったのは、問い合わせ方法がnavigationが中心で、pre-orderの順で近くの位置にデータが格納されていることを想定したものになってますね。でも、C-Storeのようにcolumn-orientedで、データを格納したいという需要とは逆行している?XMLだと同じpathに属するノードを近くに置いておくと、データも圧縮しやすくなるし、ディスクI/Oを抑えるのにもつながるから、ツリーを辿らなくてすむならそちらの方がいいのだけれど。XMLの圧縮の論文はほぼ全部この事実に基づいて構築されていますし。row & columnをうまく分解する必要がありそう。まぁ、それだからXMLのindexingの研究が濫立しているのですが。
そもそも、navigation queryというのは、Webが広まって需要がでてきたXMLデータ特有のもの。でも、XQueryのようにnavigationで問い合わせや更新をするのはわりと直感に反することもあります。データの持つ関係(ER-diagramとかUMLであらわされるもの)だけでなく、データの意味とはあまり関係のない木構造のことまで考えなきゃいけないので。データの順番とかは大事なことも多いのですが、木構造の指定を間違えると答えを得られなかったりするなど、階層関係を正確に与えるべきかどうかは疑問が残るところです。
確かに木でデータを表現するのは便利だけれど、木構造を使って問い合わせするのは行き過ぎのような気がして、最近は違ったアプローチを取るようにしています。この研究成果が、うまく形に残るといいけれど。
内容は、Compressed Index, Data Modeling, MonetDB/XQueryに関して。圧縮索引は、うまくブロック化すれば結構XMLに使えるんじゃないかと思うのです。去年の最新の結果だと、括弧木やその変形構造上でのrank/select操作で、木の探索とか、簡単なpathの探索をやってしまおうというもので、コンパクトで検索も速いし十分実用的。ただ、XMLのデータを表現するときに、0/1で表現された括弧以外の情報(タグ名とか、node id, pre, post order, levelなど)もディスク上の近い位置に保持されていてほしいわけで…。うまく使うのがとっても難しい。下手にそういう情報をまとめてしまうと、今度は圧縮しやすい構造ではなくなってしまうので。
というわけで、圧縮索引はおいておいて、おとなしく、普通にXML DBのsurveryに戻りました。最近やけに話題になっているMonetDB/XQuery。SIGMOD2006で発表を聞いてきたときは、relational algebraにXQueryを落とし込んで、最適化するとスケジュールも小さくなって、速くなりました!と、詳細を省いた発表だったので、インパクトが伝わらなかったのだけれど、論文をみると、過去数年の研究の集大成論文になってたんですね。これ。
面白い点は、
- for loopなど各iterationの状態をtableに押し込んで、relational algebraで表現できるようにした
なるほどねぇ。これは確かに新しい。loopをまたがった最適化も表現しやすくなるし、納得。TAXのようなパターンツリーベースのXML algebraだと、こういうところまでoperationを分解できないような気がします。
- purely relational: このアプローチ、当初は、既存のRDBにXMLエンジンを埋め込みたいというところから始まっていたと思うのだけれど、合理的な部分が見えてきました。ノードとかテキストに特殊な索引をつけてXMLの問い合わせを速くするなんて方法と、algebraを分離できるんですね。特殊なindex structureが使えるなら、それにあわせてalgebraを組みなおすこともできるので、relational algebraの枠組みで全部表現できる。ここはelegantですね。
逆に、主張しているほどすごくなさそうな部分。Stair-case joinは、単に一度触ったページ部分には二度触れないというだけなので、最初の論文からあまりインパクトはなかったと思います。
- updateができる: うーん。たしかにノードの挿入に対処するのにlogical number使いたいのは、みんなわかってるのだけれど、(挿入に強いordpathはラベルが長くなりがちだし)、挿入した位置以降のpage ID -> logical offsetのmapは全部書き換え。このオーバーヘッドって大きいんじゃないのかな。。。 あと、やっぱり木の移動は削除、挿入になってしまうし。。。
- ancestoreの問い合わせ、結局、候補のノードのpost = pre + size - levelを計算するまでancestorだと判定できないから、context nodeの位置によって影響を受けやすいのかも。まぁ、preだけのindexから、順々に親をたどってもさほど遅くはないのですが。
あと思ったのは、問い合わせ方法がnavigationが中心で、pre-orderの順で近くの位置にデータが格納されていることを想定したものになってますね。でも、C-Storeのようにcolumn-orientedで、データを格納したいという需要とは逆行している?XMLだと同じpathに属するノードを近くに置いておくと、データも圧縮しやすくなるし、ディスクI/Oを抑えるのにもつながるから、ツリーを辿らなくてすむならそちらの方がいいのだけれど。XMLの圧縮の論文はほぼ全部この事実に基づいて構築されていますし。row & columnをうまく分解する必要がありそう。まぁ、それだからXMLのindexingの研究が濫立しているのですが。
そもそも、navigation queryというのは、Webが広まって需要がでてきたXMLデータ特有のもの。でも、XQueryのようにnavigationで問い合わせや更新をするのはわりと直感に反することもあります。データの持つ関係(ER-diagramとかUMLであらわされるもの)だけでなく、データの意味とはあまり関係のない木構造のことまで考えなきゃいけないので。データの順番とかは大事なことも多いのですが、木構造の指定を間違えると答えを得られなかったりするなど、階層関係を正確に与えるべきかどうかは疑問が残るところです。
確かに木でデータを表現するのは便利だけれど、木構造を使って問い合わせするのは行き過ぎのような気がして、最近は違ったアプローチを取るようにしています。この研究成果が、うまく形に残るといいけれど。
2007年1月5日金曜日
2007年1月4日木曜日
[Research] 今後
ふと、同じ学科の五十嵐先生の日記をながめていると、ちょうど今の僕と同じ、博士審査の頃の日記がありました。
僕自身の博士審査に関しては、事前に審査の先生方とお話して、感触はつかめてきたので、今は、今後どう研究をしていくかの方が気になるところです。五十嵐先生は年に何本も論文を出しているので、どうしたらそんなにパフォーマンスを発揮できるんだろう、とか。
まぁ、そういうコツみたいなものは書いてないのですが、逆に、論文が落ちてがっかりしたという記述も多くて、あれほどすごい業績を上げている先生でもそういうものなのかぁと。
他にも、日記の中に、いくつか共感できることがありました。引用しつつ、僕の感じたことを挙げてみます。
・ACMの学会のようにTop Conferenceになると、査読する方は気合が入っています。馬鹿なことを書くと恥だという風潮があるんですよね。だから、出した論文が通らなくてがっかりしたとしても、読んでしっかり査読してくれた跡がうかがえるので、次に頑張ろうという気になります。コミュニティの質は、ここで決まるのかなと。 研究室に入ってから、日本語の論文って1回しか書いたことがありません。人生初の論文で、最初の1回、それきりです。論文は通ったのだけれど、あまりに読む人がsurveyをしていないのが感じられて、とてもがっかりしたのです。国際会議でも、中堅かそれ以下のものになるとそういう傾向が見られます。明らかに結果だけ見てコメントしてる、とか。日本の学会を軽視しているわけではないのですが、新しい知見とか、するどい指摘が得られない場所ではやりがいが見出せません。
・「研究のコミュニティは素晴らしいところ」。お金のためでなく、同じ興味をもった人達が集まってきて、情報交換したり、議論したり、で最先端の知識や技術を発展させていく。そういう場があるというのは素晴らしい。 なるほど。同じ興味を持つ人って、実は同じ研究室内という狭い場所よりも、世界中から集まってきた方が、実は良い話ができるんですよね。 日本の学界だと、論文を通すことを目的としすぎて、「悪いところを隠し」て論文を書くように指導する教授もいるようで。。。皆の共有知識を増やしていくという雰囲気が日本にないことを嘆いています。僕も、学会って、日本中の叡智が集まったすごいところだという幻想を持っていたのですが、どうやら、必ずしも、皆が、世界の最先端とか、人に役立つ技術の開発を目指しているわけではないのです。困ったことに、予算をとったから一応成果を発表しないといけない人とか、卒業のために論文を書く人、生活のために、など、研究を続けるインセンティブは、いろいろです。
「世の中で必要とされているものを地道に探して、もしよいアイデアがでてきたらみんなに共有してもらう。」 確かに理想論なのですが、こういう気持ちを常に持ち続けていたいものです。
・プログラミングの量と研究成果が直結しない。これは、よく体感することです。頑張って書いたコードも、結局使わないことはよくありました。「最小の努力で最大限の成果」、なんて例ができるといいのだけれど…。
・「締め切りまで3ヶ月。時間がな~い!」 成果を出してちゃんと論文をまとめようとすると、3ヶ月ってあっという間です。いつも締め切りぎりぎりになってテンパってしまうので、この感覚を身に着けないと。今まで一番余裕があったのは、博士論文を締め切り1日前に提出できたことくらいです(涙)1年に5本論文を書くのが目標なんだけれど、達成できていないなぁ。
・試行錯誤して性能を試すようなプログラムは人目に触れることのないものだけど、そういう開発は楽しい。けれど、一般の人が使えるように、バグをとったり使いやすくする開発は、辛い。 世の中、日銭を稼ぐのに必要なプログラムって、後者なんです。 でも、研究していると、前者に偏らざるを得なくて、論文としてはかけるけれど、実際に一般の人が使えるものに仕上がっていない(そういう研究って、たくさんあります。プログラムを公開しているけれども、使いにくいものとかね)。 でも、僕は、ちゃんと使えるものを作りたい。でも、それは時間もかかるし、ちゃんとビジネスまで持っていかないと続けられないから大変。夢と現実のジレンマがあります。昔は、両方を追い求めて開発ばかりしていて、できたプログラムを元に論文を書いていたのですが、そういうものだと、結局、論文には、実装の詳細までは書ききれないし、その上、作ったものが持つglobal impactは何かよくわからない論文しか書けていなかったなぁと、反省しています。論文が落とされても、大きく見直すのではなく、実装の細かいところとか局所的なところに目がいって、大きな成果を残そうとあせって泥沼に陥っていました…(遠い目) でも、細かいところは大事です。そういう小さな試行錯誤による裏づけがあって初めて、本当に重要な部分について言及できることがあります。研究で論文を引用するのと似てますね。違いは、全部の仕事を自分がやっているから、細かいところに引きずられやすいということ。そこに気付くのに時間がかかりました。
論文が通っても、使ってもらえないと意味がないです。世の中に貢献した感触が得られないというのが第一。人から評価してもらえることは、社会で生きていく上で、必要なことだと思います。Top conferenceに論文が通ると、それだけでよく引用されるのものですが、かといって論文を通すことそのものが目的になってはいけない。ただ、発表の場が、共通の目的を持っていなかったり、意欲の低いコミュニティになってしまうと、知の向上を図ることもできず、辛いものになってしまいます。いい論文であっても、そういう場での発表だと、まったく引用されていない、なんてこともあります。
研究を続けるからにはいい仕事をしたいです。でも、自分が時間を費やした成果が埋没してしまわないためには、きちんと戦略を練る必要があります。ここ数年、ビジネス関連の書籍を読むことが多いのですが、それというのも、研究も、企業のビジネスと多分に重なるところがあるからなんです。コンピュータの能力って、まだまだ引き出されていないところがたくさんあります。人件費以外の予算もそれほど必要としないので、少ない費用で大きな成果を残せる可能性を多分に秘めたものなんですよね。ただ、人の能力と時間は限られている。そういう制約がある中で、限られた資本(予算)から、できるだけ大きな成果を挙げることが目的という面で、研究とビジネスは同じです。
映画とかアニメでは、パソコンを使いこなすキャラクターってよく出てきますよね。コンピュータの計算力としてはそういう作品に出てくるようなことは大体できるようになっているのだけれど、まだ、人間はそこまでコンピュータを使いこなせないし、そのためのアプリケーションも発展途上です。そのギャップを埋める仕事ができればいいなと、常に思っています。これは、僕の小さいときからの憧れ。まさか、自分が研究の道に入るとは思ってもいなかったですが。
僕自身の博士審査に関しては、事前に審査の先生方とお話して、感触はつかめてきたので、今は、今後どう研究をしていくかの方が気になるところです。五十嵐先生は年に何本も論文を出しているので、どうしたらそんなにパフォーマンスを発揮できるんだろう、とか。
まぁ、そういうコツみたいなものは書いてないのですが、逆に、論文が落ちてがっかりしたという記述も多くて、あれほどすごい業績を上げている先生でもそういうものなのかぁと。
他にも、日記の中に、いくつか共感できることがありました。引用しつつ、僕の感じたことを挙げてみます。
・ACMの学会のようにTop Conferenceになると、査読する方は気合が入っています。馬鹿なことを書くと恥だという風潮があるんですよね。だから、出した論文が通らなくてがっかりしたとしても、読んでしっかり査読してくれた跡がうかがえるので、次に頑張ろうという気になります。コミュニティの質は、ここで決まるのかなと。 研究室に入ってから、日本語の論文って1回しか書いたことがありません。人生初の論文で、最初の1回、それきりです。論文は通ったのだけれど、あまりに読む人がsurveyをしていないのが感じられて、とてもがっかりしたのです。国際会議でも、中堅かそれ以下のものになるとそういう傾向が見られます。明らかに結果だけ見てコメントしてる、とか。日本の学会を軽視しているわけではないのですが、新しい知見とか、するどい指摘が得られない場所ではやりがいが見出せません。
・「研究のコミュニティは素晴らしいところ」。お金のためでなく、同じ興味をもった人達が集まってきて、情報交換したり、議論したり、で最先端の知識や技術を発展させていく。そういう場があるというのは素晴らしい。 なるほど。同じ興味を持つ人って、実は同じ研究室内という狭い場所よりも、世界中から集まってきた方が、実は良い話ができるんですよね。 日本の学界だと、論文を通すことを目的としすぎて、「悪いところを隠し」て論文を書くように指導する教授もいるようで。。。皆の共有知識を増やしていくという雰囲気が日本にないことを嘆いています。僕も、学会って、日本中の叡智が集まったすごいところだという幻想を持っていたのですが、どうやら、必ずしも、皆が、世界の最先端とか、人に役立つ技術の開発を目指しているわけではないのです。困ったことに、予算をとったから一応成果を発表しないといけない人とか、卒業のために論文を書く人、生活のために、など、研究を続けるインセンティブは、いろいろです。
「世の中で必要とされているものを地道に探して、もしよいアイデアがでてきたらみんなに共有してもらう。」 確かに理想論なのですが、こういう気持ちを常に持ち続けていたいものです。
・プログラミングの量と研究成果が直結しない。これは、よく体感することです。頑張って書いたコードも、結局使わないことはよくありました。「最小の努力で最大限の成果」、なんて例ができるといいのだけれど…。
・「締め切りまで3ヶ月。時間がな~い!」 成果を出してちゃんと論文をまとめようとすると、3ヶ月ってあっという間です。いつも締め切りぎりぎりになってテンパってしまうので、この感覚を身に着けないと。今まで一番余裕があったのは、博士論文を締め切り1日前に提出できたことくらいです(涙)1年に5本論文を書くのが目標なんだけれど、達成できていないなぁ。
・試行錯誤して性能を試すようなプログラムは人目に触れることのないものだけど、そういう開発は楽しい。けれど、一般の人が使えるように、バグをとったり使いやすくする開発は、辛い。 世の中、日銭を稼ぐのに必要なプログラムって、後者なんです。 でも、研究していると、前者に偏らざるを得なくて、論文としてはかけるけれど、実際に一般の人が使えるものに仕上がっていない(そういう研究って、たくさんあります。プログラムを公開しているけれども、使いにくいものとかね)。 でも、僕は、ちゃんと使えるものを作りたい。でも、それは時間もかかるし、ちゃんとビジネスまで持っていかないと続けられないから大変。夢と現実のジレンマがあります。昔は、両方を追い求めて開発ばかりしていて、できたプログラムを元に論文を書いていたのですが、そういうものだと、結局、論文には、実装の詳細までは書ききれないし、その上、作ったものが持つglobal impactは何かよくわからない論文しか書けていなかったなぁと、反省しています。論文が落とされても、大きく見直すのではなく、実装の細かいところとか局所的なところに目がいって、大きな成果を残そうとあせって泥沼に陥っていました…(遠い目) でも、細かいところは大事です。そういう小さな試行錯誤による裏づけがあって初めて、本当に重要な部分について言及できることがあります。研究で論文を引用するのと似てますね。違いは、全部の仕事を自分がやっているから、細かいところに引きずられやすいということ。そこに気付くのに時間がかかりました。
論文が通っても、使ってもらえないと意味がないです。世の中に貢献した感触が得られないというのが第一。人から評価してもらえることは、社会で生きていく上で、必要なことだと思います。Top conferenceに論文が通ると、それだけでよく引用されるのものですが、かといって論文を通すことそのものが目的になってはいけない。ただ、発表の場が、共通の目的を持っていなかったり、意欲の低いコミュニティになってしまうと、知の向上を図ることもできず、辛いものになってしまいます。いい論文であっても、そういう場での発表だと、まったく引用されていない、なんてこともあります。
研究を続けるからにはいい仕事をしたいです。でも、自分が時間を費やした成果が埋没してしまわないためには、きちんと戦略を練る必要があります。ここ数年、ビジネス関連の書籍を読むことが多いのですが、それというのも、研究も、企業のビジネスと多分に重なるところがあるからなんです。コンピュータの能力って、まだまだ引き出されていないところがたくさんあります。人件費以外の予算もそれほど必要としないので、少ない費用で大きな成果を残せる可能性を多分に秘めたものなんですよね。ただ、人の能力と時間は限られている。そういう制約がある中で、限られた資本(予算)から、できるだけ大きな成果を挙げることが目的という面で、研究とビジネスは同じです。
映画とかアニメでは、パソコンを使いこなすキャラクターってよく出てきますよね。コンピュータの計算力としてはそういう作品に出てくるようなことは大体できるようになっているのだけれど、まだ、人間はそこまでコンピュータを使いこなせないし、そのためのアプリケーションも発展途上です。そのギャップを埋める仕事ができればいいなと、常に思っています。これは、僕の小さいときからの憧れ。まさか、自分が研究の道に入るとは思ってもいなかったですが。
2007年1月2日火曜日
[Mac] Parallelsの性能測定
Parallelsでどれくらいの性能がでるのかをHDBENCHというプログラムで測定してみました。
結果は、上がBoot Campでnativeに起動したWindows XP, 下が、Parallels上で起動している別パーティション上のWindows XPでの結果。
結果としては、性能は半減。けれど、Randam Disk Readだとキャッシュが効くせいかParallelsの方が速くなってますね。CPUやメモリアクセスの性能よりも、Video周りや、Diskアクセスのスピードはもっとも体感される速度の違いなので、この辺りが向上されるといいなぁ。特に書き込み性能が遅いのは痛い。
Paralellsで別パーティション上のディスク領域に直接読み書きしているといっても、デバイスドライバはParallelsがMac OSの上に仮想的にかぶせているものなので、その中間処理の分、速度が落ちているのでしょうね。それでも、ちょっとしたノートPCよりは十分速い性能です。Mac mini & Parallels恐るべし。
結果は、上がBoot Campでnativeに起動したWindows XP, 下が、Parallels上で起動している別パーティション上のWindows XPでの結果。
結果としては、性能は半減。けれど、Randam Disk Readだとキャッシュが効くせいかParallelsの方が速くなってますね。CPUやメモリアクセスの性能よりも、Video周りや、Diskアクセスのスピードはもっとも体感される速度の違いなので、この辺りが向上されるといいなぁ。特に書き込み性能が遅いのは痛い。
Paralellsで別パーティション上のディスク領域に直接読み書きしているといっても、デバイスドライバはParallelsがMac OSの上に仮想的にかぶせているものなので、その中間処理の分、速度が落ちているのでしょうね。それでも、ちょっとしたノートPCよりは十分速い性能です。Mac mini & Parallels恐るべし。
湯島天神に初詣
あけましておめでとうございます。
今年のお正月は、妻子が実家に帰って過ごしているので、一人で元旦を迎えました。つかの間ですが、子育てから解放されたこの機会に、近所にあるけれど一度も初詣にいったことがなかった湯島天神にお参りにいきました。
天神さまには15分前ほどに行ったのですが(近所なので歩いていきます)、既に100mほどの長打の列ができていました。ここまでは例年混雑している様子を傍目で見て知っていることなので、ちゃんと防寒具と暇つぶし用のウォークマンを持参して、対策はばっちりです。寒い夜なので、子連れだと風邪を引かせてしまいそうで、子供が小さいうちは難しそうですね。
40分くらいしてようやく境内に。杓子で手・口をすすいでから祈祷することを期待していたのですが、どうも混雑回避のために、お賽銭を投じればそれでよしと考えているらしいお巡りさん(警備員?)が多数。口をすすぐ場所は閉鎖されており、お巡りさんも「左右の方が開いてますよ!」と、祭壇がまったく見えない位置のお賽銭箱の前に人を誘導する始末。
ああ、これはもう初詣というより、なにか違うイベントになのだと感じました。そもそも、湯島天神に祭られているのは菅原道真様なのに、みんながみんな本当に学問成就をお願いしにきているというわけではなく、新年のイベントだからということで来ている様子。「恋みくじ」とかあるし。
近所に住んでいると、祭日と普段とのギャップに驚かされるものです。巫女さんが大増員されているし、破魔矢売り場も普段より相当増えていました。冷めているつもりはないのですが、こういう場所で売られているおみくじや縁起物って、ちゃんと作っている会社があるんですよね。念力をこめたわけでもなく、普通の働き手さんが大量生産しているのです。品物の上でわさわさと棒を振って、厄払いくらいはしているかもしれませんが。
そんなことを考えながら、いざお賽銭を投げて、お祈り。ただ、困ったことに、何をお祈りしていいのかわからなくて、冷や汗。道真様なので、学問成就かなと思いましたが、自分の学業の成果を人様にお願いしても仕方がなさそう。では、学問を続けられる環境維持をお願いするかと思いましたが、それも神様に頼むことではない気がしました。そういう場所を整えるのも研究者としては、自分でやるべきことなんですよね。
ろくにお祈りもできず、後がつかえているので、とりあえずその場は離れましたが、よくよく考えると、自分のことではなく、家族のことをお祈りすればよかったのかなと思いました。何かしてと頼むのではなく、皆を暖かく見守ってください、とかね。
子供にお土産でも、と思ったのですが、商業主義が隠せないところで千円札を費やすよりは、おいしいものでも食べようという気分に。破魔矢を買っても、ちゃんと飾って置く場所がないだろうし、きっと原価は1割程度でしょう。
東京天神うどんさんで、このときだけメニューに現れる期間限定のおそばを頂いて、満足できた元旦でした。初詣に来る人も、たくさんお賽銭やお布施を払う人も、形はどうであれ、充実した気持ちで新年を迎えられればいいのだと思います。とりあえず、お金持ちでもない今の僕には、千円でおいしいおそばが食べられる方が価値は高いです(笑)
そのときどきの満足も大切にしつつ、長い期間の満足も考えて、一歩一歩進むことができる一年でありますように。
今年のお正月は、妻子が実家に帰って過ごしているので、一人で元旦を迎えました。つかの間ですが、子育てから解放されたこの機会に、近所にあるけれど一度も初詣にいったことがなかった湯島天神にお参りにいきました。
天神さまには15分前ほどに行ったのですが(近所なので歩いていきます)、既に100mほどの長打の列ができていました。ここまでは例年混雑している様子を傍目で見て知っていることなので、ちゃんと防寒具と暇つぶし用のウォークマンを持参して、対策はばっちりです。寒い夜なので、子連れだと風邪を引かせてしまいそうで、子供が小さいうちは難しそうですね。
40分くらいしてようやく境内に。杓子で手・口をすすいでから祈祷することを期待していたのですが、どうも混雑回避のために、お賽銭を投じればそれでよしと考えているらしいお巡りさん(警備員?)が多数。口をすすぐ場所は閉鎖されており、お巡りさんも「左右の方が開いてますよ!」と、祭壇がまったく見えない位置のお賽銭箱の前に人を誘導する始末。
ああ、これはもう初詣というより、なにか違うイベントになのだと感じました。そもそも、湯島天神に祭られているのは菅原道真様なのに、みんながみんな本当に学問成就をお願いしにきているというわけではなく、新年のイベントだからということで来ている様子。「恋みくじ」とかあるし。
近所に住んでいると、祭日と普段とのギャップに驚かされるものです。巫女さんが大増員されているし、破魔矢売り場も普段より相当増えていました。冷めているつもりはないのですが、こういう場所で売られているおみくじや縁起物って、ちゃんと作っている会社があるんですよね。念力をこめたわけでもなく、普通の働き手さんが大量生産しているのです。品物の上でわさわさと棒を振って、厄払いくらいはしているかもしれませんが。
そんなことを考えながら、いざお賽銭を投げて、お祈り。ただ、困ったことに、何をお祈りしていいのかわからなくて、冷や汗。道真様なので、学問成就かなと思いましたが、自分の学業の成果を人様にお願いしても仕方がなさそう。では、学問を続けられる環境維持をお願いするかと思いましたが、それも神様に頼むことではない気がしました。そういう場所を整えるのも研究者としては、自分でやるべきことなんですよね。
ろくにお祈りもできず、後がつかえているので、とりあえずその場は離れましたが、よくよく考えると、自分のことではなく、家族のことをお祈りすればよかったのかなと思いました。何かしてと頼むのではなく、皆を暖かく見守ってください、とかね。
子供にお土産でも、と思ったのですが、商業主義が隠せないところで千円札を費やすよりは、おいしいものでも食べようという気分に。破魔矢を買っても、ちゃんと飾って置く場所がないだろうし、きっと原価は1割程度でしょう。
東京天神うどんさんで、このときだけメニューに現れる期間限定のおそばを頂いて、満足できた元旦でした。初詣に来る人も、たくさんお賽銭やお布施を払う人も、形はどうであれ、充実した気持ちで新年を迎えられればいいのだと思います。とりあえず、お金持ちでもない今の僕には、千円でおいしいおそばが食べられる方が価値は高いです(笑)
そのときどきの満足も大切にしつつ、長い期間の満足も考えて、一歩一歩進むことができる一年でありますように。
登録:
投稿 (Atom)
License
Leo's Chronicle by Taro L. Saito is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.1 Japan License. |