🔍torch.tensor への変換における Numpy と Polars の速度比較2023/12/03に公開2023/12/052件PyTorchnumpyPolarstechGitHubで編集を提案DiscussionNista2023/12/05深掘りしていただき、ありがとうございます!!めっちゃ参考になりました。データへのアクセスと、型変換に関するオーバーヘッドの切り分けができていなかったんですね。そうなるとコードの実行速度を第一に考えるなら__init__の初期化時にtensor変換がベストプラクティスでしょうか...? 元々想定していたのは、 tensorで管理できるnumerical列 画像など非テーブルデータへのpath が同居しているようなデータでしたが、この場合も__init__時に画像を全てロードして極力tensorに乗せてしまって、あとはtensorをidxでスライスするのが最速な気がしています。(今度はメモリに乗り切るのか問題などはあるとおもいますが...) 返信を追加uchiiii2023/12/06いえいえ、Nista san のブログが非常に面白い結果だったので、勝手に気になって調べてしまいました。こちらこそありがとうございます! 同居しているようなデータ このようなデータですよね。 https://pytorch.org/tutorials/beginner/data_loading_tutorial.html この場合も__init__時に画像を全てロードして極力tensorに乗せてしまって、あとはtensorをidxでスライスするのが最速な気がしています。(今度はメモリに乗り切るのか問題などはあるとおもいますが...) そうですね、メモリが無限にあるのであれば、全てデータを GPU に載せておくのがいいと思いますが、それは現実的じゃないですよね。画像はあまりに大きいデータなので逐次読み込むしかない(直接 GPU 上に load できればなおよしな)気がしますが、それ以外の numerical 列に関しては、(polars で色々操作した後)あらかじめ cuDF に変換しておき、torch.tensor と互換性のある memory 配列 で保持しておくのがいいのかもしれません(が、未検証ですmm) https://qiita.com/nijigen_plot/items/bca14c1884d2a69cdbf3 自分のブログでは非常に細かいところまで計測しましたが、これからわかることはこのデータのサイズだと Polars も十分高速ということですね!(他の部分と比べると row 単位のアクセスの速度は無視していいレベル)なので、実用性を考えると、Nista san の方法で全く問題ない気がしていて、きっと別のところが律速になりそうだなと! 返信を追加
Nista2023/12/05深掘りしていただき、ありがとうございます!!めっちゃ参考になりました。データへのアクセスと、型変換に関するオーバーヘッドの切り分けができていなかったんですね。そうなるとコードの実行速度を第一に考えるなら__init__の初期化時にtensor変換がベストプラクティスでしょうか...? 元々想定していたのは、 tensorで管理できるnumerical列 画像など非テーブルデータへのpath が同居しているようなデータでしたが、この場合も__init__時に画像を全てロードして極力tensorに乗せてしまって、あとはtensorをidxでスライスするのが最速な気がしています。(今度はメモリに乗り切るのか問題などはあるとおもいますが...) 返信を追加
uchiiii2023/12/06いえいえ、Nista san のブログが非常に面白い結果だったので、勝手に気になって調べてしまいました。こちらこそありがとうございます! 同居しているようなデータ このようなデータですよね。 https://pytorch.org/tutorials/beginner/data_loading_tutorial.html この場合も__init__時に画像を全てロードして極力tensorに乗せてしまって、あとはtensorをidxでスライスするのが最速な気がしています。(今度はメモリに乗り切るのか問題などはあるとおもいますが...) そうですね、メモリが無限にあるのであれば、全てデータを GPU に載せておくのがいいと思いますが、それは現実的じゃないですよね。画像はあまりに大きいデータなので逐次読み込むしかない(直接 GPU 上に load できればなおよしな)気がしますが、それ以外の numerical 列に関しては、(polars で色々操作した後)あらかじめ cuDF に変換しておき、torch.tensor と互換性のある memory 配列 で保持しておくのがいいのかもしれません(が、未検証ですmm) https://qiita.com/nijigen_plot/items/bca14c1884d2a69cdbf3 自分のブログでは非常に細かいところまで計測しましたが、これからわかることはこのデータのサイズだと Polars も十分高速ということですね!(他の部分と比べると row 単位のアクセスの速度は無視していいレベル)なので、実用性を考えると、Nista san の方法で全く問題ない気がしていて、きっと別のところが律速になりそうだなと! 返信を追加
Discussion
深掘りしていただき、ありがとうございます!!めっちゃ参考になりました。データへのアクセスと、型変換に関するオーバーヘッドの切り分けができていなかったんですね。そうなるとコードの実行速度を第一に考えるなら__init__の初期化時にtensor変換がベストプラクティスでしょうか...?
元々想定していたのは、
が同居しているようなデータでしたが、この場合も__init__時に画像を全てロードして極力tensorに乗せてしまって、あとはtensorをidxでスライスするのが最速な気がしています。(今度はメモリに乗り切るのか問題などはあるとおもいますが...)
いえいえ、Nista san のブログが非常に面白い結果だったので、勝手に気になって調べてしまいました。こちらこそありがとうございます!
このようなデータですよね。
そうですね、メモリが無限にあるのであれば、全てデータを GPU に載せておくのがいいと思いますが、それは現実的じゃないですよね。画像はあまりに大きいデータなので逐次読み込むしかない(直接 GPU 上に load できればなおよしな)気がしますが、それ以外の numerical 列に関しては、(polars で色々操作した後)あらかじめ cuDF に変換しておき、torch.tensor と互換性のある memory 配列 で保持しておくのがいいのかもしれません(が、未検証ですmm)
自分のブログでは非常に細かいところまで計測しましたが、これからわかることはこのデータのサイズだと Polars も十分高速ということですね!(他の部分と比べると row 単位のアクセスの速度は無視していいレベル)なので、実用性を考えると、Nista san の方法で全く問題ない気がしていて、きっと別のところが律速になりそうだなと!