2015-07-14

C++標準化委員会の文書 2015-05 post-Lenexaのレビュー: N4521-N4530

Merge Fundamentals V1 into V2

Library Fundamentals TSのV1とV2をマージする提案。

V1とV2が分かれていた理由は、NB投票をする際の混乱を防ぐためだったそうだ。

余計に分かりづらかった気がするのだが。

N4522: std::atomic_object_fence(mo, T&&...)

atomic_object_fenceの提案。atomic_thread_fenceと似ているが、これはVariadic Templatesで任意個のリファレンスを取る。リファレンスに取ったオブジェクト以外の順序は未規定である。

N4523: constexpr std::thread::hardware_{true,false}_sharing_size

C++にキャッシュラインサイズを取得するライブラリの追加。

C++11では、std::thread::hardware_concurrency()が追加された。これは、独立して実行できるスレッドの数を返す(例えばコア数)。これは実装の際のヒントに使える。

同じ考え方で、キャッシュラインサイズをヒントとして取得したい。標準ライブラリに入れることで、移植性の高い方法でキャッシュラインサイズが取得できる。しかし、キャッシュラインそのものの定義が実装ごとに異なり移植性がない。

そのためこの提案では、目的を絞った二種類のキャッシュラインサイズ情報を取得できるようにしている。false-sharing sizeとtrue-sharing sizeだ。

false-sharingとは、2つの独立したオブジェクトが同じキャッシュライン上に乗っているがために、一方のオブジェクトに変更が加えられると、もう片方も同期のためにストールすることをいう。false-sharing sizeとは、2つのオブジェクトがfalse-sharingを避けるために取るべきオフセット値を返す。

true-sharingとは、2つのオブジェクトを合わせたメモリーフットプリントとアラインメントが同じキャッシュラインに乗るサイズを返す。

これらの値は、alignas()の中で使うのに最適である。

namespace std {
  class thread {
    // ...
  public:
    static constexpr size_t hardware_false_sharing_size = /* implementation-defined */;
    static constexpr size_t hardware_true_sharing_size = /* implementation-defined */;
    // ...
  };
}

著者はGoogle社員とnVidia社員になっている。nVidia社員が著者になるのはなかなか珍しい気がする。

N4524: Respect vector::reserve(request) Relative to Reallocation

std::vector::reserveは指定したサイズ以上のストレージを確保することが規格で規定されている。この提案は、reserveは指定したサイズを確保するように文面を変更する提案である。

初心者が期待している挙動として、サイズを指定したら、それ以上にストレージを浪費してほしくないということがまずある。また、既存のlibstdc++, libc++, MSVC2013は、指定されたサイズをそのままあロケーターに渡す実装をしている。そのため、これは単に既存の挙動を標準化するだけである。

この提案は、vector<bool>には変更を加えない。また、basic_stringにもreserveはあるものの、vectorとは性質が違うので、この提案では何もしない。

N4525: C++ Standard Library Issues Resolved Directly In Lenexa

Lenexa会議で解決された標準ライブラリの小粒な問題集。

[PDF注意] N4526: Towards improved support for games, graphics, real-time, low latency, embedded systems

「ゲーム、グラフィック、リアルタイム、低レイテンシー、組み込み系のサポートの改良に向けて」と題された壮大な論文。

内容は、N2271のEASTLを検証するものとなっている。EASTLはEAが自社内で設計して使っているSTL風のライブラリで、ゲーム用にパフォーマンスを重視した設計になっている。

[PDF注意] N4527: Working Draft, Standard for Programming Language C++

C++の最新のドラフト

N4528: Editor's Report -- Working Draft, Standard for Programming Language C++

C++ドラフトの編集者による報告書。

今回の変更点はshared_mutexか。

N4529: C++ Extensions for Library Fundamentals, Version 2, Working Draft

Library Fundamentals TSのドラフト。様々なこれまでに提案されて可決された比較的小粒なライブラリが含まれている。

N4530: Editor's Report — Library Fundamentals TS

Library Fundamentals TSドラフトの編集者の報告書。

ドワンゴ広告

KADOKAWA系列のenterbrainから出版されているニンジャスレイヤーが社内に転がっているので、最近、ニンジャスレイヤーの面白さに目覚めた。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

4 comments:

Anonymous said...

ゲームには全部詰まってるのでEAの提案には興味があります。
ただその代償として複雑な実装を要求することになったらちょっと頭をひねります。
やっぱ、関数の名前と引数を見て処理が頭におぼろげに浮かぶ位の処理が移植性にしてもバランスがいいと思います。
カリカリチューンはダメではないですが、多用するべきではないです。
それとNvの社員の名前が挙がるのってC++では珍しいですね。
あそこはクーダをやっているので文句を言うならC側だと思うのですが、c++に興味でもあるんでしょうか。
気になります。GPUでC++クラスの粒度が扱えることはとてもエピックなことに思いますよ。
まぁわからないですけど。

Anonymous said...

あ、そうだ。
N4523ですが、こんな命名規則でいいんですかね~。
自分にはTRUEが何でFALSEがなにかさっぱりですよ。
ちゃんと名前を割り当てるべきではないですか?

Anonymous said...

cache の line sizeって、CPUの種類によって変わってくるんだけど、
(今のx86だと64byte/line だけど昔は32byte、同時代に混在することもある)
constexprでいいものなんでしょうか?

Anonymous said...

Twitterにずっと昔から転がっていたのに死んだ木の本を見るまで気づかなかったということは、C++の参考書を紙で出版する意味はありそうですね。