TensorFlow：dequeue_up_toはtf.train.batchのdequeue_manyよりも遅いですか？

Question

GitHubのsource codeでは、allow_smaller_final_batch=Trueをtrain.batchに入力すると、すべてのバッチでdequeue_manyの代わりにdequeue_up_toが使用されます。 dequeue_up_toは遅いですか？私はTensorFlowリポジトリで検索した後も、何とかこのソースコードを見つけることができません。 dequeue_manyとdequeue_up_toの機能をこのファイルhereまでトレースしましたが、gen_data_flow_opsとその機能が見つかりません。また、レポの検索ではgen_data_flow_opsの結果が返されます。これはなぜですか？

Answer 1

難易度コードをトレースするPythonコードからC++へのパススルーは、TensorFlowのopラッピングテクニックの不幸な結果です。一般的に、C++の実装はFooBarOpと呼ばれ、Pythonは生成されたコードでfoo_barを呼び出します。

この場合、gen_data_flow_ops._queue_dequeue_up_to_v2は、QueueDequeueUpToV2の登録のための自動的に生成されたPythonラッパーです。これはC++ DequeueUpToOpのエイリアスです。

元の質問に答えるために、キュー自体と大きなパフォーマンス差はありません（アップデートのデキューのバージョンでは、キューが閉じられた後に何かが異なります）。 allow_small_batchを有効にすると、スタティックシェイプの情報がグラフから削除されます（バッチサイズ）。スタティックシェイプをベースに最適化すると、いくつかのopsダウンストリームが遅くなることが考えられます。