あけましておめでとうございます。

昨年は仕事関係の事が休日にくい込んだりしていたため、記事が少なめだったようなきがします。またカテゴリー別で見ると、C++が一番多かったでしょうか?C++でもなんでもいいのですが、今年はもっともっと並列プログラミングの記事を書けるように頑張って行きます。

"第1回 Google Go登場の背景" を読んで思ったこと

Google Go登場の背景 (2/2)- @IT

このエントリを読んで気になった事。

Goが、Cのポインタ演算機能を外したこと(*2)は違和感なく受け入れられる人であっても、JavaC++などのオブジェクト指向言語に欠かせない要素と考えられている「クラスの継承」が言語機能から外されたことには驚いたことだろう(ほかにも、Goでは例外処理機能や型を実行時に引数とするジェネリックなどがサポートされていない)。

Google Go登場の背景 (2/2)- @IT

オブジェクト指向言語に欠かせないのはポリモルフィズムですし、クラスの継承が言語機能から外されることに驚かない人も多いのではないでしょうか。GoFデザインパターンでも "継承を使うな委譲をを使え" と強調してたり、ECMAScriptのようなクラスが無い言語もそれなりに普及してますし、オブジェクト指向言語 = 継承という式は成り立たなくても不思議ではないでしょう。
また、 "型を実行時に引数とするジェネリックなどがサポートされていない" は "型をコンパイル時に引数とする" の間違えでしょうか?型を実行時に引数とするってポリモルフィズムとかリフレクションとかそっち側の話のような気がします。(ポリモルフィズムは型を引数にするのとは違う気がするけど。引数に渡してるのはオブジェクトであって型じゃないし)

まず、Goは現在に至るまでCが用いられている分野で、Cに代わって用いられるポテンシャルを有している(今後のマルチコアCPU時代にあっては、Goで記述することによる若干のオーバーヘッドは、容易に並列処理が記述できるなどのメリットが補って余りあるであろう)。

Google Go登場の背景 (2/2)- @IT

cが用いられている分野ってのが何を想定しているかによりますが、組込み(っていうのも幅が広いけど)やらOSまわりやらに取って変われるのかは、ガベージコレクタを持っている時点でかなり現実味がないように感じられます(その辺を上手く扱えるような言語仕様があるのかな?)。lispとかprologとかでOSのカーネル書く人とかもいますので、もちろんいずれはgoで書かれるものもあるかもしれませんが、少なくとも現時点でcを選択している人や分野にとってはあまり興味を引かないのではないかと。

省メモリプログラミング

省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集 (Software patterns series)

省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集 (Software patterns series)

  • 作者: ジェイムズノーブル,チャールズウィアー,James Noble,Charles Weir,安藤慶一
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/06/20
  • メディア: 単行本
  • 購入: 1人 クリック: 100回
  • この商品を含むブログ (33件) を見る

プログラムのメモリ消費量を抑えるためのパターン集です。何しろパターン本なので当然といえば当然ですが基本的な方法を集めていています。
メモリサイズは全然気にしないという富豪プログラミングというか非現実的?(問題に対して潤沢な計算機資源があるという意味で = 普通コスト削減とかで少なくされちゃうでしょという意味で)な場合もあるかもしれませんが、それなりの大きさやそれなりの量を扱う場合にはちょっとでもメモリ消費量を少なくしたいという事は多いかと思います(サーバラック減らしたいとか、基板の実装面積減らしたいとか色々)。
またプロセッサの速度を出したい場合にも、アライメントをそろえないといけないという制約がありつつもキャッシュにデータを乗せたいとか、1レジスタに入れたいというような理由でメモリ消費量を抑えたい場合もあるかもしれません。
そんなこんなで、大量に出回るプログラムや長時間稼働するプログラムでは割と必要な技術と言えると思います。メモリ消費量まで気にしながら開発できる程、潤沢な開発期間があるかというまた別の問題もあるわけですが。

JISになっている言語

JISC 日本工業標準調査会

日本工業規格になっているプログラム言語に現状何があるのか気になって調べてみました。JISにおいて情報処理関係はXに集められていて、言語はそのなかの3000番台に集められているようです。以下はその検索結果から拾い集めた結果です。言語毎に拾ったので、複数の規格になっているもは一つに集約してます。

CLIPOSIXは言語じゃない気もしますが。

量子コンピュータって何だ?

量子コンピュータ―超並列計算のからくり (ブルーバックス)

量子コンピュータ―超並列計算のからくり (ブルーバックス)

量子コンピュータという名前は聞くのですが、実際にどんなものなのか知らなかったので少々お勉強を。いきなり本格的なのを読む前に、ブルーバックスで感じをつかんでみます。

  1. 量子コンピュータでできること
  2. 「量子」とはなにか
  3. 量子の不思議
  4. 「量子」を使った計算機
  5. 量子アルゴリズム
  6. 実現にむけた挑戦
  7. 量子コンピュータの周辺に広がる世界と量子暗号

という構成なのですが、最初は物理的な概念と量子計算の歴史をたどっていき、第4章あたりから実際の量子コンピュータで必要となる量子ビットの話に続いていきます。
量子力学ネタなのに波動関数が出てこないとか、数学的には平易な道具しか使ってないはずなのですが、私の頭が悪すぎなのかちゃんと理解できてる自信がありません。ただ、とりあえず感じをつかむ為に最初に読むには良い本なのではないでしょうか。(あまりにも自分が知らない分野なので、良いのか悪いのかの判断ができないと言う話もありますが)

この本は2005年に出版されているのですが、量子計算関係での実例として、

  • 15の因数分解ができた。
  • 量子暗号で100km先と通信できた。

というのがあるようで、量子コンピュータの実現よりも量子暗号の方が実用化が近いようです。

"計算基礎科学コンソーシアムの声明はお門違い"に対する細かいツッコミ

http://japan.cnet.com/blog/petaflops/2009/11/21/entry_27035472

能澤 徹さんという方が書かれた上のエントリについて細かいツッコミを。途中でNECが撤退しちゃうとかプロジェクトとしてどうなんだと言う点については同意ですので、ここでは技術面で不思議に思った点を書いてみます。

OpteronXeonはパソコン用のCPUからのものであり、PowerXcellもゲーム機用のCellからのものである。計算科学に関係の深いBlue Geneの源流は、コロンビア大学のQCDSPで、この機械は廉価な民生用のDSPを演算器として並列に並べて作ったスパコンであり、次のQCDOCとBG/LはIBMの産業組み込み用CPUであるPPC440を用いたものである。どれをとっても、「民生からスパコンへ」の流れである。

http://japan.cnet.com/blog/petaflops/2009/11/21/entry_27035472
  1. PowerXCellがCell/B.E.という民生品からの流れとするならば、今回仕分けの対象となった次世代スーパーコンピュータに搭載予定だったVinusもSPARCという民生品の流れなのではないでしょうか?Vinusの場合はかなり拡張されているようなのでPowerXCellとCell/B.E.ほど近いのかと言われると困りますが、もろにSPARC64の派生品扱いっぽいですし過去のワークステーションとも一応バイナリ互換があるのではないかと。
  2. QCDOCの事は知りませんが、BG/LはPPC440と互換性のあるコアを搭載した新しいプロセッサであってPPC440自体を使ったわけではないので、産業組込み用CPUを用いたとするのは微妙かと。(参考 http://www-06.ibm.com/jp/provision/no48/pdf/48_article2.pdf)

NECのSXとかをしきりにダメだといってますが実際の所どんなもんなんでしょうね。top500のlinpackモンスターな感じのクラスタ型を引き合いに出されてもなんかピンとこないというか、アプリケーションによってはスパコン専用機のメモリ帯域の広さで勝負するものもあると思うので、一つの石で10GB/s程度しか出なさそうな現行のXeonとかOpteronとかはデータ間に相互作用がある問題に対してどの程度スケールするものなのかはよく分からないです。特にSXの肩を持つつもりはないのですが、比較データがまるっきりなくてどちらとも言えないので、そのうち真面目に調べてみます。ただものがものだけに、仕様は見つかっても実効性能までは見つからないかも。

cudaMemcpyはどこにある?

CUDAのお勉強をしていると必ず出てくるcudaMemcpy()。どこにあるのか、他になにあるのか探してみました。対象としたのはCUDA2.3です。

cudaMemcpy()はcuda_runtime_api.hに定義されていますが、同じくcuda_runtime.hにも定義されています。何が違うかというと、前者がvoid**を引数にとる関数であるのに対して、後者が任意のT**型を引数にとるテンプレート関数になっています。
また、cuda_runtime_api.hにはほとんどコメントがないのに対して、cuda_runtime.hには各関数の頭にコメントがついています。返り値を確認したいときにもcuda_runtime.hでしょう。実際にはほとんどがcudaError_tなのでわざわざ確認する必要はないかもしれませんが。