データローダーの概要: 議論

リンク一覧

• 概要と序文
• データローダー
• 実験のセットアップ
• 数値結果
• 議論
• 関連作業
• 結論、謝辞、参考文献
• A. 数値結果の続き

5. 議論

この作業では、異なるライブラリ間のパフォーマンスを比較するための主なツールとして時間を使用しました。これについてはいくつか言及すべきことがあります。まず、実行時間は非常に変動しやすく、制御が難しいバックグラウンド プロセスに依存することに気付きました。同時に、マルチ GPU リソースへのアクセスはコストがかかるため、実行できる実験の数が制限されます。理想的には、各実験をより多くのパラメーター (ワーカー、バッチ サイズ) で 3 回以上繰り返し実行したかったのですが、そのためのリソースがありませんでした。私たちはすべてのコードをオープンソースで作成しているため、読者には自分のハードウェアでベンチマークを実行し、結果を報告していただくようお願いしています。同時に、ライブラリはかなり頻繁に更新されるため、バージョンの変更によってパフォーマンスが大幅に向上または低下する可能性があります。

上記の点を考慮して、読者には本論文の質的側面を理解していただくようお願いするが、ここで得られた数値は変化する可能性がある点に留意する必要がある。

第二に、比較が難しい側面は、このプロジェクトで検討されているライブラリの使いやすさです。このベンチマークに含まれるライブラリのほとんどには包括的なドキュメントがなく、主に具体的な例に依存しています。その結果、これらのライブラリでの実装は簡単ではなく、非効率になりがちです。コードをオープンソースにすることの利点の 1 つは、どの開発者でもコードを特定して改善できることです。これは、このプロジェクトで作成されたベンチマークがコミュニティの定型コードとして使用されることを期待しているため、特に重要です。

他のライブラリよりも優れたライブラリがあるわけではないことに注意してください。代わりに、それぞれに独自の長所があります。FFCV の例を考えてみましょう。これは私たちの実験では最速のようですが、ラベル変換がサポートされていないため、そのような機能を必要とするプロジェクトでは採用されていません。

今後の作業では、複数の GPU にわたるフィルタリングとトレーニングの相互作用を分析したいと考えています。同時に、GPU の数が増えるにつれて、これらのライブラリのスケーリング機能を調べることも興味深いでしょう。同様に、DL トレーニング ワークフローのシャッフル ステップのパフォーマンスの観点からデータ読み込みライブラリをベンチマークすることも非常に興味深いでしょう。これは、合計トレーニング時間に大きな影響を与える可能性があり、その実装はいくつかの種類のアプローチがある重要な問題だからです。

リモート ストレージからのデータ読み込みを提供し、ローカル ストレージ実験と同等の結果を示すライブラリに関する研究は、ネットワーク経由のデータ ストリーミングのキャッシュ ポリシーを策定および設計するというアイデアを探求する動機となりました。その設定では、データ ポイント (画像など) を転送する必要がある回数を減らすことで、全体的なトレーニング時間 (およびネットワーク使用料が支払われる場合はコスト) を大幅に短縮できます。トレーニング中にネットワーク データセットをキャッシュするというアイデアは新しいものではありません (Mohan ら、2020 年)。それでも、トレーニングとストリーミング データについて議論するときは、データセット全体をキャッシュできると想定されることがよくあります。さらに、従来のように、すべてのサンプルがエポックごとに 1 回使用されると想定されています (Kumar および Sivathanu、2020 年)。キャッシュ サイズが小さい場合に何が起こるかを調査し、エポックごとにすべてのデータ ポイントを 1 回使用するという要件を削除することに関心があります。このような定式化は、アクティブ ラーニング、データ要約、カリキュラム学習から借用する必要があります。