3. BoostCon 2011

最終更新日時:
が更新

履歴 編集

BoostCon 2011

http://boostcon.boost.org/program/sessions/

セッション資料

翻訳プロジェクト

BoostCon 2011の資料を翻訳しています。

翻訳したデータは各自でどこかに公開(たとえばGoogle Docs、slideshareなど)し、リンクを貼ってください。

参加者は常時募集しています。

セッションリスト

IPv6の準備はできてる？

それはニュースの中にあった：IPv4アドレス空間が枯渇する。
その解決策は新たなインターネット・プロトコル、IPv6である。IPv6は長い間存在していたが、その使用を命じた政府機関のためのコードを開発しない限り、それについて今まで心配する必要がなかった。

これは一夜の変更では済まないだろう。
IPv4はまだ数年は使われるだろうし、ネットワークアプリケーションは両方のプロトコルをサポートしなければならないだろう。

この発表は、ネットワーク開発者が知る必要のあるIPv6の基本をカバーする。

Boost.AsioのIPv6のサポートを見て回り、独立したBoost.Asioベースのネットワークアプリケーションプロトコルを独立させること、およびIPv6を用意するためのいくつかの設計戦略について議論する。

万能ツリーによるAST構築

Boost.Spiritのコードベースに最近追加されたutreeは、抽象構文木を表現するための設計されたジェネリックなデータ構造である。QiとKarmaへのバインディングは、Boost.Spiritによるパーサー、ジェネレータ開発の強力なツールとなる。この発表では、抽象構文木を構築、操作するための、パース／ジェネレートの4つのユースケースを示す：XML、シンボル式(S式)、JSONとCライクなソースコード。

Spiritによるutreeの統合の詳細、およびutree中心のSpiritパーサー／ジェネレータの記述について議論する。さらに、他の内部表現(XMLのためのDOMツリー、JSONオブジェクトのための連想配列、小さなCソースコードのシンプルなVMバイトコード)に、utree ASTをコンパイルする設計手本をカバーする。

自動ハイブリッドMPI+OpenMPコード生成

マルチプロセッサー市場の出現は、大規模並列コンピュータのアーキテクチャを根本的に変えた。何千ものスレッドによるハイパフォーマンスコンピューティングプラットフォームが展開されている。このコンテキストでは、ハイブリッドなMPI + OpenMPアプローチの使用はそのようなアーキテクチャにふさわしいプログラミングモデルと見なされる。しかし、パフォーマンスの改善が示される場合もあれば、示されない場合もある。ハイブリッドなMPIおよびOpenMPアプリケーションのパフォーマンスに影響している要因は多く、複雑で、相互の関係にある。

  • MPI通信効率 ： アプリケーションは、MPI通信の種類(一対一、集団)、メッセージサイズ、接続や帯域といったネットワークの問題に関係がある。
  • OpenMP並列効率 ： クリティカルセクションプリミティブを使用すると、OpenMPスレッド管理のオーバーヘッドやfalse sharingによってパフォーマンスが悪化する。
  • MPIとOpenMPの相互作用 ： MPI通信部分の内部のロードバランシング、および使用されていないスレッドの問題は、並列度を低下させる。

両方のコードを書くことは、普通のHPCアプリケーションよりも専門技術の高いレベルを必要とするかもしれない。

したがって、これらの新しいシステムへの効率的な利用は、重要な挑戦である。また、アプリケーションに責任を負う科学者およびエンジニアは、一般に、あまりHPCの専門家ではなく、通常、彼らはコードに新しい変化を持ち出すことや新たなプログラミングパラダイムを学ぶことはしたがらない。彼らは、効果的な自動並列化ツールとライブラリといった点での解決策を必要としている。

この発表では、我々は2つの、相互関係のある異なるレベルの問題を解決を試みる。

まず我々はバルク同期並列(Bulk Synchronous Parallelism ： BSP)パラダイムをすぐに導入し、それがいつ、そしてなぜ、ハイブリッドシステムの適当なプログラミングモデルと見なすことができるかを解説する。

その後、我々はBSP++を紹介する。これは、BSPモデルに基づいた並列アプリケーションの迅速で容易な設計を可能にするBoostを用いたC++ライブラリである。我々は、BSP API、Lambda、PhoenixやMPIを含む、一般的に用いられるBoostライブラリに対するその相互作用、いくつかの実装詳細について記述し、いくつかの例を示す。

最後に我々は、BSP++、Boost.Spirit、および Clang/LLVMによって構築された並列のプログラミングフレームワークであるBSPGenを紹介する。BSPGenは、XMLで書かれた小さなアプリケーションの記述と、並列化されていないCもしくはC++の関数から、実行時コストの先行評価とほぼ最適なOpenMPとMPIの間のバランスを決定するための配置空間の小さな探索に基づく、完全はハイブリッド並列のアプリケーションを生成することができる。実装詳細と例を提供する。

Boost.Generic: コンセプトを使用しないコンセプト

コンセプトはおそらく、C++0xの中で最も望ましい機能のうちの一つだった。それによってプログラマはとくに、コメントではなくコードによるコンセプトの直接指定、コンセプトベースオーバーロード、テンプレートエラーメッセージの改善を含む、ジェネリックプログラミングの直接的な言語サポートを約束された。2009年のworking paperからのコンセプトの削除で、多くのプログラマが、将来のC++標準に、かなりの失望を残すことになった。

しかし、10年以上の間、直接の言語サポートなしでC++プログラマは、Boost Graph Libraryを含む非常に強力なジェネリックライブラリをなんとか作ることができた。Boost Concept Check Libraryは、コンセプトの必要条件を検証するプロセスを実現可能にした。しかし、C++0xでコンセプトを削除したまま、事態をさらに1ステップ進めることは可能である。努力し、ライブラリはよりシンプルな、より特定のコンパイル時アサート、コンセプト要件を表現し、チェックするより強力な方法、ユーザー指定された自動で明示的なコンセプトマップのための設備と、ユーザーがコンセプトを書くためのコンセプトベースな関数テンプレートのオーバーロードを書く方法、人々が言語機能に期待するかもしれないものに驚くほど近いユーザビリティなども全てを提供することができ、提供する。

この話は(レビュー前の)Boost.Genericへの入門である。

コンセプト、コンセプトマップ、コンセプトベース関数テンプレートオーバーロードを作成するためのC++0xライブラリであり、Boost Concept Check Libraryを潜在的に置き換える、もしくは賞賛することを意図する。発表は、ライブラリの歴史、および短い入門に続き、パラダイムに慣れていない人々のためのジェネリックプログラミングの基本を最初に簡潔にカバーし、ライブラリを可能にするための根底にあるトリックへの導入に続く。その後、聴衆はBoost.Genericの基本的な使用法を示され、すでに提供されているコンセプトの要件チェックのためのコンパイル時アサートを指定する方法、それらのコンセプトに単純なコンセプトマップを作成する方法と、それら自身のアルゴリズムのためにコンセプトベースのオーバーロードを書く方法を示す。最後に、聴衆はBoost.Genericによる標準コンセプトの実装を通じて、標準との比較を見て回るだろう。

「Boost.Generic ： コンセプトのないコンセプト」は、ライブラリ開発者、ユーザーの両方のためを意図する。それはC++の任意の合理的な量の経験を持ったプログラマにアクセス可能であるに違いない。基本アイデアは話の最初の数分でカバーされるが、ジェネリックプログラミングについての熟知が高く推奨される。

Boostインフラストラクチャ ワークショップ

  • Boost Infrastructure Workshop
  • スピーカー ： Dave Abrahams
  • 形式 ： ワークショップ
  • トラック ： Track I 2011

Boostのコードとコミュニティがあったこと、あり続けたことで大成功した。しかし、操作性において我々のcode baseと同じ割合では発展していない。テストはより速くなりえる、インストールはより容易になりえる、ドキュメントの生成はより賢くなりえる、レビューはより多くの参加を得ることができ、そしてライブラリの維持はより楽しくなりえる。何年もの間、我々はこれらの問題に対処する方法について話したが、しかし我々は実際に変化をもたらすために合意と推進力を発生させられなかった。このワークショップは、これらに正面から何かをするチャンスだ。

我々は方針を作成するために毎日90分間会合し、ツールを作成し、次の10年を通じてBoostの進化をサポートすることができるWebサービスを準備した。具体的なゴールは、カンファレンス参加者との間でのプロトタイプと有用な改善の実装で、より広いコミュニティの合意を獲得し、BoostConのあとすぐにBoostに採用されるされることである。我々には一週間しかない、したがって、生産力を最大限にするために、関心ある個々のトピックの小さなグループで活動する。Boostが採択することができるという方向へ率いることを保証するために、いくつかの短い投票を行い、その週を通じてBoostのメーリングリストでフィードバックを求めるだろう。

十分なBoostモデレータおよびリリースマネージャー達は、カンファレンスに続く数ヶ月で、受け取ったアイデアを前身させるためにBoostConに出席することを計画する。

Boost.Process ： C++によるプロセス管理

Boost.Process はシステムのプロセス管理のためのライブラリである。これはシェルコマンドの実行や、子プロセスの生成、子プロセスに対する環境変数あるいは入出力ストリームの設定、子プロセスとの同期・非同期での通信、そして子プロセス終了の待機（あるいは強制終了）に使うことができる。

発表パートではBoost.Processの進歩、設計上の決定、改良点に焦点を当てる。チュートリアルパートではBoost.Processが提案するいくつかのツールと、それらがどのようにプロセス管理で使われるかを説明する。

Boost.Units

Boost.Units はコンパイル時次元解析、単位変換のための自由度の高いライブラリである。これは、ユーザーがある単位の量を表現すると捉えた値の作成、無意味な操作の禁止、必要な場面での変換の適用によりプログラミングエラーを軽減するために設計された。

C++0xの進行状況

C++0xの批准を今年にひかえ、BoostCon2010での更新から(2010-現在)議論の的になっている問題や、これまでの批准の進捗、前回の更新から追加されたさまざまな新機能について詳細を述べるとともに、巻き起こった議論について、またその問題をどのように解決しようとしたかについて、1.5時間頂いてレヴューを行なう。

話者は、長年、IBMでカナダのC++標準化委員会のメンバーを務めてきた者だ。中程度のC++の知識がある者を対象にしているが、もちろん、どなたでも聴講可能である。

Boost.Asio拡張の作成

Boost.AsioはBoost C++ librariesの有名なポータブルネットワークライブラリである。
このライブラリが、Boost.Netという名前にならなかったのには理由がある。Boost.Asioの真の力は非同期的な操作を実装するためのフレームワークたりえる点である。ネットワーク機能はその非同期的な操作のよい実例の一つにすぎない。

このチュートリアルでは、どのようにBoost.Asioを拡張することができるか、ということと、どうやって非同期的な処理を実装するかについて述べる。
まずは、既存の拡張である、ファイルやディレクトリを監視するディレクトリモニタを紹介する。
また、このフレームワークに適合しない非同期的な操作を紹介し、Boost.Asioの制限について示す。

Skootによる設計の旅。ピア指向ジェネリックネットワークライブラリ

効率的で、エレガントで、汎用的なC++ライブラリを完成させるまでの道程は、決して平坦ではない。GPSが壊れたかのように道を誤り、暗い路地をすり抜ける羽目になり、非常にストレスがたまる。
それと同時に、APIの設計を固めたり、利用箇所全てで機能性を検証することは、刺激的で満足のいく旅路となるだろう。
このプレゼンテーションでは、数々の設計上のトレードオフについて、またSkoot libraryで利用しているBoost librariesについて議論する。

Skootは、分散環境やピア指向の処理環境で利用しやすい、C++のネットワーキングライブラリである。
また、TCP、UDPプログラミングにおける様々な通信パターンや利用法を単純化し抽象化する。
Skootは、Asio、Function、Bind、Shared(とWeak)Pointer、そしてOptionalといった多くのライブラリを利用している。
多くのC++開発者は汎用ライブラリの完成形だけを注視して、そこに至るまでの議論を軽視する傾向がある。

  • ある種のtype erasureに対し、テンプレート化クラスが意味があるのはどんな時か？
  • 非常に強力なテンプレート関数や関数オブジェクトがあるのに、多くのC++開発者がテンプレートクラスだけをありがたがるのは何故か？
  • いつでもデストラクトされる可能性のあるオブジェクトへの参照を有効にしつづける方法は？
  • Boost libraryの魔法、Bindとは何か？ なぜそれがモミ林にいるキンキラの吸血鬼よりすばらしいのか？
    • (訳註：モミは吸血鬼を封印する効果があるとされている。吸血鬼は光にも弱いため、"glittering vampire in a forest of fir trees"は二重の意味でありえない。これと対比させる事で、Bindの"魔法"の強力さを示している)
  • C++で仮想テンプレートメンバ関数が必要になった場合、どうすればいいのか？
  • Asioの実装者である、Chris Kohlhoffはノーベル賞か何かを受賞すべきか？

これらの疑問はSkoot開発中に湧き、解決されていったが、これらを説明することで、Boost導師と言える領域に達していない開発者を啓発することができると思う。
このプレゼンテーションは、汎用的なテンプレートを基礎にした設計技法を学んでいる、また、FunctionとBind(と、その他のライブラリ)を基本構成要素としてどう利用するかについて興味があるような、熟練したC++開発者向けである。
ライブラリの使用方法や、API設計や洗練、また良いユニットテストの作成についても議論する。

(人物紹介：Bio: Cliffは現在SeattleにあるBoeingに勤務する、経験豊かなC++開発者である。
氏の開発経歴の中で主なものは、ネットワーキングと複数のプログラミング言語での可用性の高い分散処理である。また、Prologに愛着を持っていることも付記しておく。
Cliffは、複数の新興企業に勤務した経歴がある。これらは今やすべて破産、買収されたが、実勢価格の自社株購入権を失った時でも、安定した給料を高く買われている。)

Genevaライブラリによる分散パラメトリック最適化

このプレゼンテーションではBoost libraryに大きく依存している分散最適化アルゴリズムのオープンソースライブラリであるGenevaを紹介する。
Genevaは現在、勾配降下法、進化アルゴリズム、群アルゴリズムをカバーしており、まもなく焼きなまし法が追加されることになっている。
すべてのアルゴリズムは、候補となるソリューションが最適化アルゴリズムを自由に切り替えられるように、同じデータ構造に作用する。
Genevaはグリッド環境、クラウド環境、マルチコアシステム、クラスター上でも、大規模なパラメトリック最適化問題を解くことができる。
このライブラリは、同時に最適化問題に取り組む数百のクライアントでテストされている。
使用しているライブラリは、Boost.Serialization、Threads、Conversion、Date/Time、Function、Bindなど多岐にわたる。
このプレゼンテーションでは、ユーザーの視点から、Geneva library自体について、また、Boostで培われた経験について論じる。

C++による高速数値計算：遅延コード生成(LzCG)のためのExpression Templateとその先へ

Expression templateは、数値計算において、強力な最適化を可能にするC++の機能である。

Expression templateはBoost.uBLASや、他の有名なC++の数値計算ライブラリ (例えば、先駆けであるBlitz++やArmadilloなど) に用いられている。ATLASやFFTWのような"標準"となるC++で書かれたライブラリはまだない。なぜないのか? このチュートリアルの最初の章では、私は数値計算における最適化の挑戦について、最適化のためにどのようにしてexpression templateが使われているのか、そして、expression templateの使用を妨げる根本的な要因についてレビューを行う。

2つめの章では、私はいくつかの数値計算フレームワークが、どのようにして、一般にC++-onlyのライブラリで達成されているよりも高いパフォーマンスを達成しているかについて紹介する。それらのライブラリでの重要な特徴は、複雑なコード生成、実行されるハードウエアへの正確な適応、そして、実行前に多くの異なる実装の性能を計る能力をもつことである。

最後に、私は、どのようにすればC++のパフォーマンスを、Expression templateによってもたされるそれよりも高くできるかについて論議する。私は新しい開発途中のフレームワークを用いて、実際にどのように動いているかのデモを行う。

国内、国際的な研究プログラムや基金を通じた、Boost開発の資金調達について

このプレゼンテーションでは、まず、Boostの開発をサポートする目的で、国内・国際的な研究プログラムや資金を活用するための実現可能な方法について議論する。

ゴールは3部構成である：

  • Boostの開発に役立てるために、国内、国際的な研究資金調達スキーム(NSFやEuropean Unionなど…)を活用するために、多国間の連携に向けて取り組み始めるには
  • Boostを、世界各地の大学や工業大学でコンピュータサイエンス教育のカリキュラムで取りあげられるような標準的なトピックにするためには
  • Boost開発に科学分野からの新しい参加者を取り込むには

Boostの未来 - パネルディスカッション2011

Boostには、本筋の議論や、尊重すべき、また有用なメーリングリストを維持するために、ポストの承認と管理を含むメーリングリストの運用を行っている小規模のモデレータグループがいる。

このグループは、Webサイトや、ソースリポジトリの管理やその他の管理業務も遂行している。

また、少なくとも、Boostに関することを促進するために、委員会を監督する非公式幹部としての役割をも果す。

Rangeのためのジェネリックな変換と分割:Unicodeのためのソリューション

一貫した世界のライティングシステムのうちのほとんどが通る、テキストを表現し、操作する業界標準であるUnicodeに対処するBoostでのソリューションの数多くの需要は常にあった。この話では、我々は、Google Summer of Code 2009で開始したソリューションを示す。Rangeのコンセプトに基づいて、計量で、非侵入的で、柔軟で、ジェネリックで、潜在的にlazyである。

アルゴリズムをジェネリックにするために、全てが書き直された。また、それによって、このライブラリはいかなる既存のUnicodeソリューションにも依存しない。このライブラリは、いくつかの外部データを要求するが、ライブラリがそれ自身のデータベースに埋め込むにも関わらず、ライブラリを別のデータベースとリンクするために使用することができる明快で安定したABIがある。

Unicodeライブラリのニーズは、スピンオフとして別のライブラリに至った：Convertライブラリは、N to M変換を使用して、容易にRangeを変換し、分割することを可能にするライブラリであり、Rangeを正格もしくはlazyにイテレートする。また、それはSIMDによって加速された変形の開発を助ける設備を提供する。このライブラリは、最初はUnicodeのために作られたが、我々はそれを文字エンコーディング変換と無関係な様々なものに使用することができることを示す。

Protoを楽しむ - C++ EDSLデザインのハンズオンチュートリアル

Embedded Domain Specific Languagesは、中小の大きさの問題を宣言的で効率的な手段で扱うための設計として、実際に選ばれることが増えている。とりわけ、C++はBoost.Protoのようなライブラリのおかげで、そのような開発の親言語として、本当に興味深い。

このチュートリアルは、現実的なシチュエーションでのクイックスタートとなり、Boost.Protoを用いたコードが美しく小さく効率的であることをデモすることに焦点を当てている。

チュートリアルは以下の要素から構成される:

  • 短いライブラリの基本的なブロックのプレゼンテーション
  • 単純な計算機のコードから、拡張可能なコアを持つ解析関数の微分を行うシステムのプロトタイプまでのガイド付きの練習問題。この問題は、Protoを用いてEDSLを構築するいくつかの段階と、Proto特有のイディオムについて示す。

参加者はテンプレートメタプログラミングに関する知識を持つ中級か上級のC++ユーザが望ましい。昨年のEric NieblerによるProtoに関する発表を見るのもよいだろう。

Haskell - C++テンプレートメタプログラミングのための擬似言語

C++テンプレートメタプログラミングは使うのも解析するのもデバッグするのも難しいが、それはだいたいコンパイル時のC++が関数型言語的で構文がゲロいからである。うまくメタプログラミングするコツは、関数型プログラミングに精通して、C++メタプログラムのための擬似言語を作ることであるが、実のところ既にそのための言語はあり、そいつはHaskellとか言われている。このセッションではまず、そのHaskellで書いたコードと等価なC++のメタコードを並べることでHaskellがどんな言語かを紹介する。その後、Haskellを使った複雑なC++メタプログラムの読み書きの方法を示す。最後はC++における「実行できるテンプレート」の説明で、モナドとは何か、どうやってそれを使うかを示す。

IntelのC++ Software Transactional Memory CompilerとC++でのトランザクション言語構築のドラフト仕様について

トランザクションメモリ(TM)を利用すれば、プログラマからは複雑な共有メモリ管理が隠蔽されるため、並行プログラミングが容易になる。このセッションでは、最新のC++でのトランザクション言語構築のドラフト仕様について、ならびに、インテルのC++ software transactional memory (STM) compilerでの実装例について紹介する。

Boost libraryの作者は高度に最適化され、極度にタイプセーフなソフトウェアを実装することを目標としている。
このセッションでは、厳格なタイプセーフと最適化を達成するために、Intel C++ STM compilerでどのようにトランザクションが利用されているかについて詳細に述べる。
特に、テンプレート宣言やラムダ式、コピーコンストラクタ、そして基本的な関数やクラスでどのようにトランザクションが利用されているか紹介する。
また、リラックス・トランザクションの概念について紹介し、この概念を用いて、取り消し不能なアクション(例えば、I/Oのように実行前に戻せないアクション)をどう扱うとよいかについて示す。

最後に、最新のC++でのトランザクション言語構築のドラフトと、Intel’s C++ STM compilerのロードマップについて述べる。

MPL.Graphの紹介

MPLメタプログラミングとBGLグラフコンセプトの過激な合いの子である、MPL.Graphがコンパイル時にメタデータのグラフを作成し走査するためのBoostライブラリとして提案された。

グラフのデータ構造とアルゴリズムは様々な目的でコンパイルタイムに適用できる。例えば、クラス階層や、Expression Templateツリー、ステートマシンや文法は完全にコンパイルタイムに処理できるグラフである。また、呼び出しグラフや、オブジェクトの所有権、オブジェクト間のポインターは、部分的にコンパイルタイムに処理できるが、残りはランタイムに処理する必要があるグラフである。

これらは全て、グラフのアルゴリズムを実行するために、標準的なグラフインターフェイスを適用することができるか、計算されたグラフから作り出される。仕様および分析にコンパイルタイムグラフを使用すれば、抽象化の無駄なランタイムサイクル回避でき、概念的な明快さと抽象化（一度"メタ"の壁を乗り越えられれば）が向上する。

今のところ、MPL.GraphはBGLのincidence_listとadjacency_listデータ構造と、breadth_first_searchとdepth_first_searchアルゴリズムのコンパイルタイムバージョンを提供している。このライブラリはBoost.MSMで、リージョン(連結成分)と到達不能な状態とを区別するために、いまのところはサブライブラリとして使用されている。このトークではMPL.Graphの新しい用法を紹介する。(例えば、文法や、Fusion Graphとして知られるヘテロなグラフデータ構造など) また、最終的な目標である、コンパイルタイムグラフでランタイムグラフを記述する、"グラフのグラフ"といえるメタグラフについて少しだけ紹介する。

ロックフリープログラミング パート2： データ構造

まず昨年夏の話の概要から始め、昨年中断したところ - ロックフリープログラミングの"FCD(恐怖、必然性、そしてかなりの嘘)"について更に深めるところから再開する。

今回はデータ構造を主題にするつもりだ。まずは、単純なロックフリースタックから始め、このスタックのABA問題(訳註：see http://en.wikipedia.org/wiki/ABA_problem)について、その後、様々なロックフリーキューについて議論する。

Boostベースの並列通信ライブラリによる、セルブロードバンドエンジンのアーキテクチャをマスターする

セルブロードバンドエンジン(CBE)は、内部のリングバスによって接続しているPowerPCプロセッサと、8ベクトル共同処理要素(8 vector co-processing elemens)を組み合わせる、組み込みシステムである。それは、マルチメディア、シグナルプロセッシング、ハイパフォーマンスコンピューティングなどのアプリケーションにふさわしいプラットフォームである。

現行のセルプロセッサ(PowerXCell 8i)は、204.8 GFlop/sの最大の単精度のパフォーマンスと、102.4 GFlops/sの倍精度のパフォーマンスで規定される。この巨大な計算力とアーキテクチャのパワー効率(IBM BladeCenter QS22のための1ワットあたり0.87の倍精度GFlops/s)の観点から、グラフィック処理装置(graphics processing units:GPGPU)上の現代のx86マルチコアアーキテクチャおよび汎用計算(general-purpose computation)の適切な代わりであった。これらの利点にも関わらず、セルプロセッサの採用は期待されたよりも遅かった。我々は、これがアーキテクチャの新たな性質、およびその複雑性を抽象化する、便利なツールの不足に起因すると考える。

この話では、我々は、セルアーキテクチャのための効率的なアプリケーションの開発を単純化するライブラリを作る努力を示す。我々は、基礎となるハイパフォーマンスアルゴリズムで直感的なインタフェースを作るために、現代のC++コンセプト、および多くのBoostライブラリ(MPL, PP, Function, Spirit)をどのように利用するかを示す。我々は、セルアーキテクチャと、我々がどのようにそれをマスターしたかにともなう調整について議論する。

我々のライブラリの不可欠な部品は、メッセージパッシングに基づくCBEのシステムデザインに向いているプログラミングモデルである。我々の実装はBoost.MPIインタフェースに基づく非同期通信を含んでおり、また、パフォーマンスは集合的な操作(collective operations)を最適化した。

また、我々は非同期データ転送、およびマルチバッファリングをサポートする、分散コンテナと、セグメント化されたイテレータの実装を示す。さらに、我々は制限のあるリソースを持ったシステムに特に適している、Boost.Testのあとに設計された計量の単体テストモジュールのデモを示す。

最後に、我々はそのようなアーキテクチャのためのソフトウェアエコシステムの実行可能性を評価し、また、Boostの設計にどのように影響を受けたか、そのようなシステムからのパフォーマンスにコテ入れし、おそらく、そのような特定の組み込みハードウェア上のBoostの将来に関する議論を始めることができる。

ODBとBoostによるオブジェクトリレーショナルマッピング

ODBは、C++のためのオープンソースで、クロスプラットフォームなクロスデータベースオブジェクトリレーショナルマッピング(ORM)システムである。同様の機能を提示する他のライブラリと異なり、ODBは、永続クラス(persistent classes)とC++クラス宣言から、それらのデータベース表現との間の変換を行うコードを自動的に生成する。また、ODBは高度にカスタマイズ可能である。人気のあるフレームワーク、BoostやQtのようなライブラリの基本型、スマートポインタ、およびコンテナのようなコンポーネントは、標準のバージョンと合わせて永続クラスでシームレスに使用することができる。

話の前半は、ODBシステムの基本概念とワークフローを導入する。後半は、BoostのためのODBプロファイル、永続Boost値型(例えばboost::gregorian::date)のサポートを行うライブラリ、スマートポインタ(例えばboost::shared_ptr)およびコンテナ(例えばboost::optional、boost::unordered_set)に注目する。

GCCプラグインによるC++解析

GNU Compiler Collection(GCC)は、成熟し、広く使用されたC++コンパイラ実装を持ったオープンソースでクロスプラットフォームなコンパイラスイートである。GCCのバージョン4.5.0は、コンパイラコンポーネントの再利用と同様に、コンパイルプロセスのカスタマイズを許可する、新たな動的なプラグインアーキテクチャを追加した。この発表のゴールは、GCCプラグインを使用して、C++を解析する方法を示すことである。

この話は、解析された翻訳単位の内部表現と、GCCプラグインアーキテクチャのハイレベルな概要から始まる。その後、C++宣言が存在することに関する情報の表示をするための、単純なプラグインの実装を示す。この話は、主翻訳単位、アプリケーション特有のプラグマと属性のハンドリング、プログラマティックなテンプレートインスタンス化に追加のC++コードを注入するなどのより高度な技術をカバーする。

この発表は、Clang(最近全面的なC++98サポートを達成した別のC++コンパイラ実装)とGCCプラグインアーキテクチャの簡潔な比較なしでは不完全になる。この話は、Boostの、および(GCCプラグインを使用して実装することができる)より広いコンテキストで可能なおもしろいアプリケーションの迅速なブレーンストーミングセッションで締めくくる。

Phoenix V3の概要

Phoenixは次世代のインラインの無名多態関数オブジェクト生成器となるだろう。V3ではBoost.Bind と Boost.Lambdaの機能が合成された新しいライブラリとなった。このライブラリを記述する際、後方互換性を保持したまま前述したライブラリ(訳註：BindとLambda)の制限を修正した。このセッションの目的は、C++における関数プログラミングが、いかに重要かつエレガントかについて概説することだ。セッションの第一部では、Phoenixで定義されたDomain Specific Embedded Language (DSEL)について述べる。DSELは演算子のオーヴァーロードと標準C++関数で構成されている。PhoenixがC++を模倣した言語を定義したのは、潜在的なユーザーが関数プログラミングに入門するハードルを下げるためだ。一方、既存のC++コードは(関数オブジェクトとして知られる)高階関数に依存している。たとえば、C++標準ライブラリはあるアルゴリズムの挙動を変更するために高階関数を使っている。第二部では関数オブジェクトの代わりにどうPhoenixを利用するか、また、Phoenix expression内でどう既存のユーザーコードを有効にするかについて例示する。しかし、Phoenixの真の力はこんなものではない。Phoenixは前のセクションで議論したように、式をデータとして扱う (C++においては)ユニークな機構を備えている。これによって、C++の標準的な手法ではなく、ユーザーの好みに応じた手法でPhoenixを利用できる。潜在的なユーザーにPhoenixを軸に展開する将来的なアプリケーションの見識を得ていただくために、このセッションの締めくくりとして、これらの機構についての概説をするつもりである。

Boost.SIMDによる実用的なSIMDアクセラレーション

SIMDマシン - 同じ命令で複数の要素からなるデータを並列に計算する能力を持つマシン - は、今日では、スーパーコンピュータからデスクトップコンピュータやモバイルコンピュータまで、ありふれたものとなっている。
数値計算のツールやライブラリは、SIMDを使用することによって計算速度を向上させることができるが、今のところ、C++デベロッパのための、最小で高レベルな、プラットフォームに依存しないインターフェイスを提供するライブラリはないといえるだろう。

このチュートリアルで、我々はレビュー待ちの状態にあるBoost.SIMDライブラリについて紹介し、技術的な挑戦と、どのようにBoost.SIMDを用いて、一般的な、あるいは、あまり一般的でない問題に適用させるのかについて解説する。
解説では、我々のライブラリが、全ての種類のアルゴリズムを高速化するという点や、ペナルティがないようにSIMDハードウエアをちょうどよく抽象化するという点においての有用さについて述べる。

Boost.SIMDの設計は、可能な限り軽量になるように、また、巨大な数値計算ライブラリNT2の一部となるように作られている。
NT2は、テーブルや行列を作るために、SMP、MPI、GPGPUの技術と一緒にBoost.SIMDを用いている。
Boost.SIMDはSIMDのみを扱う専用ライブラリとして作られている。
したがって、Boost.SIMDの主たる抽象化はSIMDレジスタである。(例えば、SIMDプロセッサによって処理される基本となる単位)
また、Boost.SIMDはプラットフォームに依存しない高レベルインターフェイスを提供するが、ローレベルな問題はユーザにとって主な関心事のままである。

Boost.SIMDは、一定のコードパターンを認識し、最も効率的な解法への射影をするように、Boost.Proto DESLフレームワークを用いている。例えば、Altivecと未来の世代のx86環境に存在する積和命令や、与えられた範囲で必要とされる値を検出するために用いている。

さらに、このライブラリは、与えられたアーキテクチャのプリミティブに適正に簡単に特殊化でき、新しいターゲットや関数を作成することができる強力な外部ディスパッチ機構を供えている。

現実世界におけるSpirit.Qi

Spiritの過去のセッションは、Spiritの導入や、チュートリアルによって現実の利用に注目した。実際のSpirit.Qiパーサーを書く際、速い段階で「悪魔は細部に宿る」ということに気付くだろう。思考錯誤によって、あるいはおそらくSpiritメーリングリストによって発見しなければならない特別なケース、トリック、イディオムがある。それには時間がかかり、便利とは限らないかもしれない。このセッションに、我々はprintf()(スタイルフォーマット文字列)のためのSpirit.Qiパーサーの開発を通じて見て回るだろう。結果として型安全で効率的な、printf()の置き換えになるだろう。

平面上の点、線分、多角形中間軸のボロノイ図における掃引線アルゴリズム

平面上の交点のないセグメントと点の集合を入力値とするボロノイ図を演算するアルゴリズムについて述べる。

点のボロノイ図の演算を行なうFortuneによる平面掃引アルゴリズムを踏まえて、理論値であるO(n log n)の計算量を維持したまま、このアルゴリズムを線分に適用できるように拡張した。
線分に対するボロノイ図は、多角形中間軸を自明に生成することができ、VSLI、CAD、CAMの製造など、さまざまな適用が考えられる。
効率を犠牲することなく数値堅牢性を保証するアプローチについても議論するつもりである。
lazy-exact arithmeticに基づく堅牢な述語を用いることで、このアルゴリズムが整数座標入力について確実に正しい結果を返すことを示す。

Boostに提案されたB木ライブラリ

B木はデータベースやファイルシステム、ディスクに記憶される連想コンテナなどに利用される、どこにでもあるデータ構造である。

このセッションではB木について、また、ディスクに記憶されるB木によるmap、set、multimap、multisetライブラリについて紹介する。
まずB木を概略的に説明し、提案されたライブラリコンテナとC++標準の関連するコンテナとの関連について示す。すなわち、実装されているインターフェースや、落し穴、可変長データ、パフォーマンス、また、このライブラリの実装がどこまで進んでいるかについて紹介する。
フィードバックや議論する時間も設ける予定だ。

このセッション終了時には、参加者した方々がご自身のアプリケーションにこのライブラリを利用することができるようになり、このライブラリがBoostに正式実装されるよう、さらなるフィードバックしていただけるようになるはずである。

非同期について考える ： Boost.Asioを使用したアプリケーション設計

最初から、Boost.Asioは本心では、フレームワークとしてではなく、ツールキットとして設計された。ライブラリは1セットの基礎、汎用的なビルディングブロックの提供に注目する。タスクを検討するために、一つ以上の正しい方法があり、また、ライブラリは特定の書き方を強制しない。

この発表では、我々は、問題を設計するためにどのように非同期の考え方を適用することができるかを考えていく。我々は、設計代案、共通の罠と落とし穴、それと複合操作によって計算量を攻撃する方法を見ることになるだろう。この話はまた、最適化、およびパフォーマンスと拡張性を管理するために、Boost.Asioが提供するツールをカバーするだろう。

この話は、出席者がBoost.Asioにある程度基礎的なレベルのなじみがあると仮定する。

C++0xのスレッドと共有変数

C++0xの規格ドラフトは、言語へスレッドを導入し、スレッド間で共有される変数の意味を念入りに定義する。設計は、デフォルトでマルチスレッドのプログラムがスレッドの単純な割り込み実行に基づいたセマンティクス(つまり、順序一貫性:sequential consistency)を保証するべきであるという考えに基づく。間違ったものや無意味であるものとして、我々がデータレース(通常の共有変数への、ほとんどの種類の非保護同時アクセス)を考察するという理由だけで、これは効率的な実行を許可する。ドラフトは代わりに、とくにID付けされたオブジェクトにアクセスを許可するアトミック操作の広範囲なコレクションをサポートする。

我々は、C++0xのスレッドサポートの概要を示し、次に、共有変数セマンティクスを定義するメモリモデルとアトミックライブラリの相互作用に注目する。過去の慣例とできるだけ一致するように心がけたが、我々は多くの難題と、驚きに遭遇した。我々は、コピーしないために試みた過去の誤りのいくつかに言及する。

これは、Sarita Adve、Lawrence Crowl、Paul McKenney、Clark Nelson、Herb Sutter、他の多くの方との共同作業について説明する。

C++のマルチパラダイムデザインによるネイティブXML処理

XMLプログラミングは、抽象、分割、プログラミングスタイル、およびイディオムの、それ自身の規則によって強力なデータ処理パラダイムとして出現した。経験を積んだXMLプログラマが求めるものは、それらの生産性がXMLプログラミングのドメイン固有パターンとプラクティスの使用を許可する言語とツールの有効性に依存する。しかし、これらのツールが与えられたXMLスキーマの静的に型付けされた、用語特化のオブジェクトモデル(vocabulary-specific object model)を自動的に生成するため、オブジェクト指向のコミュニティは専用XML言語よりもXMLデータバインディングツールを好む。不運にも、これらのツールはたいてい、純粋なオブジェクト指向の法則を使用して、XMLプログラミングの抽象的概念を統合する際の困難さのために、経験を積んだXMLプログラマの期待するものを避ける。この話は、C++のマルチパラダイムプログラミング能力の新たな適用によって、この普及しているギャップがどのように縮小されるのかを実証する。項目として、ジェネリックプログラミング、メタプログラミング、ジェネレーティブプログラミング、戦略プログラミング(strategic programming)、およびC++によってサポートされた演算子オーバーロードがネイティブで型付けされたXMLプログラミングをどのようにともに可能にするのかを話す。

C++0xはなぜネットワークプログラミングのための、最高の中の最高の言語なのか

警告 ： これは臆病な人のための話ではない。最先端の言語機能があり、ハックがあり、言語の乱用があるだろう。このセッションは椅子を投げておわるかもしれない。

スリルを求めるオタクにとって、それは楽しい旅であるべきだ。我々は、新たなC++0x言語とライブラリ機能のうちいくつかがどのように大きな位置を占めるのかを見ていく。また、いくつかのそれと古いものは、簡潔で、表現力があり、効率的なネットワークプログラムを作るためにBoost.Asioと連携することができる。

翻訳

Akira Takahashi, Norihisa Fujita, zak, DigitalGhost