Changes between Version 1 and Version 2 of HowTo/BoostStudy14

Timestamp:

Mar 1, 2014, 3:20:52 PM (11 years ago)

Author:

村山 俊之

Comment:

--

HowTo/BoostStudy14

@@ -3 +3 @@
 日時: 2014/3/1 10:00 ~ 18:00
 場所: IIJ@神保町
+レジュメとか: [https://sites.google.com/site/boostjp/study_meeting/study14 Boost.勉強会 #14 東京 - boostjp]
 
 == cpprefjp を支える技術 ==
@@ -161 +162 @@
    * ユーザビリティとは、その分野に精通していないユーザーにとっての公開されているアルゴリズムインタフェースのわかりやすさ。
      同時に、精通しているユーザーにとってのアルゴリズムを構成できる幅のこと。
+
+== 一体いつから FIFOがスケールしないと錯覚していた? ==
+
+ * Lock-free?
+   * スレッドをブロッキングせずに全体での進行が保証される
+ * Lock-free stack
+   * 最後のノードが常に先頭…
+ * Lock-free queue もできるよ
+ * stack に積みに行くスレッドがいっぱいあると push と pop で当然渋滞するよね…
+   * 対策:
+     * ウェイトを入れる - 200 clock ぐらい?
+       * 無駄な衝突がなくなってスループット向上。
+     * 待機中にマッチングすればよくね?
+       * EliminationArray
+         * EliminationArray 自体にはランダムな位置に突っ込む。その一が null であることを期待して…
+           * ランダムにしないとこっちはこっちで衝突しちゃうから。
+ * EliminationArray を FIFO に適用する - Elimination Queue
+   * Queue の外に EliminationArray を設ける
+   * Enqueue, Dequeu をカウントするカウンタをそれぞれ設ける
+   * CAS に失敗したら EliminationArray に乗せる。このノードには Enqueue カウンタ番号がついてる。
+   * Dequeu カウンタのほうが大きかったら↑を拾って持っていく。
+ * EliminationArray を使わなくても 8スレッドぐらいまではスケールする。
+   * 1CPU を 8スレッドまでに制限するか、 EliminationArray を使うかの選択と言うのはありうるかも…
+
+== glfw3 OpenGL を使ったGUI フレームワーク ==
+
+ * マルチプラットホームのフレームワーク
+   * windows, linux, OS X
+   * unmodified zlib/libpng license
+ * GLFW とは?
+   * 必要最小限の機能、シンプルな構造
+   * サンプルあるよ!
+   * glut の貧弱な部分を強化した感じ (glut はもはやメンテナンスされてない)
+   * リアルタイム性重視
+   * OpenGL/ES とマッチ
+   * GUI 構造や構成が C++ 向き
+   * かなり前から少しずつ構築しているため、最近の流行とは逆行する部分も…
+     * boost, C++11 の機能を的確に利用できてない
+   * 組み込みでも使えるよ! (iostream には注意…)
+ * 依存性
+   * GLFW3, GLEW, Freetype2, OpenAL, libz, libpng, libjpeg, openjpeg, Mad(mp3), AAC, Mupdf, jbig2dec, bullet(physics)
+ * core
+   * 機種依存性が高いコード
+   * GLFW3 をラップした I/F
+   * Freetype2 I/F
+   * 漢字 FEP関係
+   * I/O デバイスラッパー
+ * GL_FW
+   * OpenGL/ES を使った描画クラスなど
+   * OpenGL C++ ラッパー
+   * フォントの描画・管理
+   * 画像管理 (モーションオブジェクト)
+   * ライト (開発中)
+   * シーングラフ (開発中)
+   * シェーダー (開発中)
+ * IMG_IO
+   * 色、画像を扱う基本クラス
+ * SNG_IO
+   * 単音、ストリーム
+   * OpenAL との橋渡しなど
+ * WIDGETS
+   * GUI 部品
+   * Widget 管理
+   * 組み込み機器にも移植可能な軽量コンパクト設計
+ * UTILS
+   * 頂点、行列など線形代数関係
+   * ファイル I/O
+   * 文字列操作
+   * プリファレンス
+   * シーン制御
+ * GLFW3 の改造
+   * ドラッグアンドドロップ (Windows のみ)
+   * FEP 関係のメッセージ(予定)
+ * 開発環境
+   * MinGW (MSYS)
+ * GUI フレームワークに期待されること
+   * 日常、非日常な処理
+   * ありがちな処理は _簡単な設定_ だけで可能
+     * 現状では enum ハードコーディングなど (組み込み機器などを考慮すると XML ファイルとかは使いたくない)
+   * 複雑で特殊な処理を実装することが可能であること
+   * 拡張性
+   * 予想できるスマートな挙動
+   * シンプルな構造
+   * マウス、ジョイスティック、タッチパッドなどでも操作が可能 (今後の課題)
+ * 次世代の GUI?
+   * マウスでもタッチ操作でも可能なポリシー
+   * Windows, OS X, X11(Qt) の操作はある程度継承
+   * 「UI ガイドラインを守れば何もかもうまく行く」は幻想にすぎない
+   * case by case
+   * CPU もグラフィックスも十分高速なので、もっとヘビーな GUI を考えてもいいかも… (見た目だけの問題でなく)
+     * ジェスチャーとか?
+ * アプリケーションの構造
+   * メッセージを使わない
+   * 毎フレーム直列同期処理
+   * ゲーム向きの構造
+   * シーンごとの処理
+     * initialize
+     * update
+     * render
+     * destroy
+
+== データサイエンスワールドからC++を眺めてみる ==
+
+ * イントロ
+   * データサイエンティストもてもて?
+   * どんなツールを使ってるんだろ??
+     * 1st = R, 2nd = python, 3rd = MySQL ... C/C++ は 9位
+   * R は処理が遅い。
+     * ループとか
+   * R から C++ を呼んで高速化 ...結構多い
+   * C++ から R の関数を呼ぶやりかたもあるよ
+ * R から C++ を使ってみる
+   * Rcpp パッケージ
+     * R から C++ を実行するパッケージ
+     * R から C++ ソースをコンパイルして実行。
+       * R から呼びたい関数にコメント行でマークアップする
+ * C++ での統計解析
+   * Boost.Accumulators
+     * 記述等軽量には対応してるけど、統計的検定、多変量解析、機械学習には対応してない模様。
+     * 統計量の計算などの統計処理を提供。
+     * 使い勝手は良さげ
+   * Apophenia
+   * ROOT
+   * GSL
+   * ALGLIB
+     * これが一番対応範囲が多い?
+     * 数値計算及びデータ処理のためのソフト
+     * C++, C#, Python, VBA などから呼び出せる
+     * 商用版もあるとか…
+     * データ構造を文字列に持たせるなど、 C++ からの使い勝手は癖がある。
+   * Rllvm なんてのもあるらしい…
+   * C++ から R を呼ぶ - RInside パッケージ
+     * RInside オブジェクトを生成、計算式を文字列で渡して実行、値を取り出す、ということができる。
+     * Qt に R を埋め込むことも可能。
+ * まとめ
+   * C++ で統計解析を行う良いツールがあれば @sfchaos さんまで。
+
+ * [https://sites.google.com/site/cpprefjp/editors_doc/random_figure cpprefjp でも使ってた]
+
+== .NET とかが当たり前にやってること、C++だとどうするか ==
+
+