4

パフォーマンスが重要なコードで 'deque' を使用したことがある人なら誰でも、(少なくとも VS2010 に同梱されている STL では) ブロック サイズが 16 バイトであることに気付いているでしょう。これは、VS2010 に同梱されているヘッダー ファイルの実際の抜粋です。

#define _DEQUESIZ   (sizeof (value_type) <= 1 ? 16 \
    : sizeof (value_type) <= 2 ? 8 \
    : sizeof (value_type) <= 4 ? 4 \
    : sizeof (value_type) <= 8 ? 2 \
    : 1)    /* elements per block (a power of 2) */

これは新しい情報ではありません。この宣言がパフォーマンスの問題を引き起こす理由の詳細については、deque<T> の追加の間接化についてを参照してください。

さまざまなアルゴリズムで両端キューを使用したいのですが、この実装に制約されている場合はそうではありません。この問題を回避する最善の方法は何ですか?

1) この問題のない別の容器を使用してください。もしそうなら、誰かが GNU ライセンス制限のないものを教えてもらえますか?

2) この制限に対処する新しいコンテナ クラスを作成します。この新しいコンテナ クラスは std 名前空間の一部ではありません。

3) 「deque」ヘッダー ファイルの _DEQUESIZ 定義を編集します。STLで定義されているように、_DEQUESIZの正確な仕様は両端キューの概念の一部ではないため、IMOはこれは合法だと思います。

4) 追加のテンプレート パラメータを deque (および関連するイテレータ クラス) に追加して、コンパイル時にブロック サイズを指定できるようにします。このパラメーターは、デフォルトで _DEQUESIZ の現在の定義になります。このろくでなしの STL を使用する私のコードは移植性がないため、私はこのソリューションをほとんど拒否しています。

5) STL を変更するよう議会に働きかけ、パフォーマンスの問題なしに「deque」を喜んで使用できるようにします。IMO、これは現在の財政の崖の議論よりも成功する可能性があります。ところで、私はカナダ人なので、下院全体 + 上院 + 大統領のリグマロールは混乱を招きます。

4

2 に答える 2

0

私は1）を支持します。

標準ライブラリのlibc++実装は、非常にリベラルなライセンスの下で配布されます。実際には、コンパイラがそれを窒息させた場合に適応するように調整できるほどリベラルです（Clangを中心に設計されており、はるかに準拠しており、C ++ 11 VS 2010よりも認識しています）。ライセンスを保持するだけで済みます。

于 2012-12-21T16:11:56.207 に答える
0

本当の答えではありませんが、コメントするには長すぎます:

パフォーマンスが心配な場合は、新しいコンテナー クラスを作成することはお勧めしません。通常、STL 実装は、対象となる特定のコンパイラの実装の詳細に基づいて、移植性のない最適化を使用しますが、通常はそうすることができません。かなり単純な STL アルゴリズムを自分で書き直そうとしたことがありますが、STL アルゴリズムの約半分の実行速度が得られました。

変更_DEQUESIZすると、他のコードが元の値に最適化される可能性があるため、予期しない場所でパフォーマンスの問題が発生する可能性があります。繰り返しになりますが、特定のコンパイラ用のコードを書いているときに実行できる、移植性のない最適化の一種です。それだけでなく、 の実際の値に依存する一部のコードを壊すことさえあります_DEQUESIZ。

全体として、私の意見では、オプション 1 だけが実現可能であると言えます。残念ながら、私は提供できる良いオプションを知りません。これが、これがあなたの問題に対する本当の答えではないと私が書いた理由です。

于 2012-12-21T12:20:54.240 に答える