Hasktorchで学ぶ関数型ディープラーニング__型安全なニューラルネットワークとその実践.pdf

Transcript

1. Hasktorchで学ぶ関数型ディープラーニング： 型安全なニューラルネットワークとその実践 Rev 0.1 Junji Hashimoto 1
2. 自己紹介 • Junji Hashimoto • グリー、12年 • インフラエンジニア ◦ シニアリードエンジニア ◦ KVS Unitのチームリーダー • 業務 ◦ KVSの運用、パフォーマンス分析（Memcached, PHP, Datadog APM, eBPF） ◦ Web3のバリデータ運用(DB=LevelDB、運用自動化=LLM) • 社外活動 ◦ Hasktorch(Haskel)やgpu.cpp(WebGPU)の機械学習のフレームワーク開発 ◦ AIの安全性の分析と修正（画像系) 2
3. 目次 • Hasktorchの概要 ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化とFFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 3
4. 目次 • Hasktorchの概要 ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化とFFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 4
5. Hasktorchの概要 • Hasktorch(2017〜) ◦ Pytorchと同じ基盤(libtorch)を使ったHaskellのライブラリ ◦ CPUやGPUをサポートした自動微分・ディープラーニング ◦ テンソルが計算の中心 • プロジェクトの目的 ◦ 関数型によるディープラーニング ▪ 状態を持たないで、入力で出力が決定 ◦ コンパイル時にテンソルの計算に関連するシェイプやデバイスの型のエラーを検知 ◦ 使いやすく実用的なライブラリ • 開発者 ◦ Hasktorch Team ◦ Austin Huang ◦ Sam Stites ◦ Torsten Scholak ◦ Adam Paszke ◦ Junji Hashimoto ◦ など 5
6. Hasktorchを構成しているパッケージ • libtorch(C++) ◦ pytorchのC++バックエンド • libtorch-ffi ◦ pytorchのバックエンドであるlibtorchをhaskellから使うためのライブラリ ◦ リソース管理しているレイヤー • hasktorch ◦ テンソルのシェイプについて型あり（ Typed）、型なし(Untyped)の両方のライブラリを提供 ◦ 自動微分に関して、状態に依存しないライブラリ 6
7. 目次 • Hasktorchの概要 ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化とFFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 7
8. Tensors(Untyped) 8 [2,3] :: シェイプ（テンソルの次元） Float :: DType（テンソルの値の型） asTensor:: 値からテンソルの生成 コード 評価した値 asValue::テンソルから値の生成 テンソルの値
9. CPU <-> GPU(Untyped) 9 CPUのメモリからMacのGPUのメモリへの転送
10. スライス(Untyped) 10 上書き用のLensのスライス スライス
11. 自動微分(Untyped) 11 テンソルから 自動微分のパラメータ生成 grad関数で微分
12. 最適化(Untyped) 12 class Optimizer optimizer where runStep :: Parameterized model => model -> optimizer -> Loss -> LearningRate -> IO (model, optimizer) 入力：モデルと最適化のパラメータとロス 出力：更新したモデルと最適化のパラメータ
13. 実際のニューラルネットワーク構築 (Untyped) • MLPで構築 • スペックとデータの型の定義 • インスタンス生成と推論関数の定義 • トレーニング 13 入力：画像 0,1,..9 モデル：MLP 出力：分類結果
14. データのスペックとデータの型の定義 (Untyped) 14 スペックを定義 テンソルのシェイプなどを定義 モデルのデータを定義 Parameterizedでテンソルのシリアライズ Genericで再帰的に生成
15. データの生成と推論関数 (Untyped) 15 スペックからモデルのデータの初期化 推論の関数
16. トレーニング関数 (Untyped) 16 ロスからパラメータの最適化
17. メイン関数 (Untyped) 17
18. APIの検索 • HackageのQuick Jumpで検索 • sボタンで開く。 18
19. 目次 • Hasktorchの概要 ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化とFFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 19
20. Tensors(Typed) 20 型にDType(Float)とシェイプ 値のDTypeとシェイプ TypedからUntypedに変換
21. CPU <-> GPU(Typed) 21 CPUのメモリからMacのGPUのメモリへの転送
22. 自動微分(Typed) 22 自動微分のパラメータ生成 自動微分 パラメータからテンソルの取得
23. 最適化(Typed) 23 runStepで最適化
24. シェイプの検証 (Typed)：依存型 • テンソルのシェイプに利用 ◦ DataKinds拡張で型に値を保持 ▪ [Nat]とか。 ▪ Nat は Natural (Word) ▪ Nat はペアノ数（data Peano = Zero | Succ Peano）ではないが。 24
25. シェイプの検証 (Typed)：依存型 • シェイプの制約に利用 ◦ TypeFamily拡張を使って型レベルの関数を作成 25
26. シェイプの検証 (Typed)：依存型 • GHCの型推論だけでは、制約のチェックができない ◦ GHCプラグインのサポートが必要 • 利用しているGHCプラグイン ◦ ghc-typelits-knownnat ◦ ghc-typelits-natnormalise ◦ typelevel-rewrite-rules 26
27. シェイプの検証 (Typed)：依存型 • ghc-typelits-knownnatプラグイン ◦ 型レベルから値レベルへの変換 ◦ KnownNat型クラスタで型レベルの自然数 (Nat)から値レベルの自然数 (Integer)変換 ◦ KnownNat n => n+ 2 ▪ n+2がKnownNatにならない->解決 27
28. シェイプの検証 (Typed)：依存型 • ghc-typelits-natnormaliseプラグイン ◦ Natレベルの式と式の等価性 ◦ 例：(x + 2)^(y + 2) == 4*x*(2 + x)^y + 4*(2 + x)^y + (2 + x)^y*x^2 ◦ ghc-typelits-natnormaliseプラグインを使って解決。 28
29. シェイプの検証 (Typed)：依存型 • typelevel-rewrite-rulesプラグイン ◦ 条件レベルの等価性 ◦ a or ( a or b) == a or bだが、GHCは簡略化してくれないので、推論できない。 29
30. Hasktorchの主要なメンバー • 自動微分を使いやすくするためのライブラリ ◦ 2つのレイヤーを提供 ▪ Torch : シェイプの型なし ▪ Torch.Typed: シェイプの型あり • データ ◦ Tensor : テンソルのデータ ◦ IndependentTensor / Parameter : 自動微分するテンソルのデータ • 型クラス ◦ TensorLike : Tensorとスカラ(例：Float)やリスト(例：[Float])のデータとの相互変換 ◦ TensorIndex : スライス型 ◦ Optimizer : ロスの値を元に微分を計算 ◦ Randomizable : データの初期化（シェイプを決定） ◦ Parameterized : データを自動微分可能にするもの。（ Genericsで自動生成） ◦ HasTypes : データのCPU/GPUデバイスの切り替え、DTypeの変更をサポートするLens ◦ HasForward : データと推論の関数を紐付けるもの。 ◦ Castable: 型と値の変換のサポート 30
31. Hasktorchの概要とエコシステム（まとめ） • Hasktorch ◦ 関数型の特徴（値が変わらない） ◦ 自動微分をサポートしたディープラーニングのフレームワーク ◦ 純粋関数で計算を記述 ◦ 自動微分はgrad関数で計算 (backward関数がない) ▪ grad関数も純粋関数 ◦ API ▪ テンソルの型にシェイプがないAPI ▪ テンソルの型にシェイプがあるAPI • 依存型：GHCプラグイン ▪ HackageでAPIの検索 31
32. Hasktorchの概要とエコシステム（関連リソース） • 関連プロジェクト ◦ hasktorch-yolo (テンソルの型なし ) ◦ Transformer (テンソルの型あり ) ◦ GPT2-Hasktorch (テンソルの型なし ) ◦ gpt2-haskell (テンソルの型あり ) ◦ BERT / RoBERTa / T5 (漸進的型付け) ◦ SpiderSQL (漸進的型付け) ◦ 様々なhasktorchに付随の例 • ドキュメント ◦ ホームページ ◦ Tutorial ◦ APIドキュメント ◦ Hasktorch-tutorial (Cmdv) ◦ Neural Networks(Bogdan Penkovsky) 32
33. 目次 • Hasktorchの概要とエコシステム ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化と FFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 33
34. Hasktorchのセットアップ • サポートしている環境 ◦ OS ▪ Ubuntu(Linux) ▪ NixOS(Linux) ▪ Windows(WSL) ▪ MacOS ▪ Docker(linux amd64) ◦ ビルドツール ▪ stack ▪ cabal ▪ nix ◦ ghc（コンパイラ） ▪ 9.6と9.8 ◦ libtorch(ライブラリ) ▪ 2.3,2.4,2.5,2.7 ◦ 他 ▪ Jupyter Notebook(Nix, Docker) 34
35. Hasktorchを構成しているパッケージ • libtorch(C++) ◦ pytorchのC++バックエンド ◦ セットアップでハマるところ • libtorch-ffi ◦ pytorchのバックエンドであるlibtorchをhaskellから使うためのライブラリ ◦ リソース管理のレイヤー • hasktorch ◦ テンソルのシェイプについて型あり、型なしの両方のライブラリを提供 ◦ 自動微分に関して、状態に依存しないライブラリ 35
36. HasktorchのCabalでの開発 1. ghcupでghcとcabalをインストール 2. hasktorchをgit clone 3. libtorchをインストール a. hasktorch/depsのget-deps.shを実行 4. libtorchの共有ライブラリへのパスを設定 a. source setenvを実行 5. StackageのLTSのセットアップ a. ./setup-cabal.shを実行 b. cabal freezeファイルをセットアップ 6. ビルド a. cabal build allを実行 36
37. HasktorchのStackでの開発 1. ghcupでstackをインストール。 2. hasktorchをgit cloneする。 3. libtorchをインストール a. hasktorch/depsのget-deps.shを実行 4. libtorchの共有ライブラリへのパスを設定 a. source setenvを実行 5. ビルド a. stack build allを実行 37
38. stackで新規プロジェクト開発 1. ghcupでstackをインストール 2. hasktorch-stack-skeletonをgit clone 3. libtorchのインストール a. makeを実行 4. ビルド a. stack build allを実行 注意：大筋は大丈夫なはずだが、バージョンとかのアップデートが必要かも。 38
39. Cabal(Nix)で新規プロジェクト開発 1. Nixをインストール 2. hasktorch-skeletonをgit clone 3. hasktorchのnixのキャッシュをセットアップ（option） a. nix-env -i cachix とかを実行してcachixをインストール b. cachix use hasktorchを実行 4. 開発のシェルに入る a. nix developを実行 5. ビルド a. cabal build allを実行 39
40. Nixのインストール • curl -L https://nixos.org/nix/install | sh • . ~/.nix-profile/etc/profile.d/nix.sh • mkdir -p ~/.config/nix • echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf 40
41. 目次 • Hasktorchの概要とエコシステム ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化と FFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 41
42. Notebook(Docker)の起動手順 1. dockerをインストール 2. 次のコマンドを実行 a. docker run -it --rm -p 8888:8888 htorch/hasktorch-jupyter 42
43. Notebook(Nix)の起動手順 1. Nixをインストール 2. hasktorch-skeletonをgit clone 3. fullのブランチをcheckout 4. パッケージを追加(option) a. flake.nixのconfig.ihaskell.packagesに必要なパッケージを追加 5. hasktorchのnixのキャッシュをセットアップ（ option） a. nix-env -i cachix とかを実行してcachixをインストール b. cachix use hasktorchを実行 6. 開発シェルの起動 a. nix developを実行 7. jupyter notebookの起動 a. ihaskell-notebookを実行 8. Haskell Kernelを選択。 43
44. Notebook(Nix)の起動手順 :Nixのインストール • curl -L https://nixos.org/nix/install | sh • . ~/.nix-profile/etc/profile.d/nix.sh • mkdir -p ~/.config/nix • echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf 44
45. Notebook(Nix)の起動手順 : hasktorch-skeletonのセットアップ 45
46. Notebook(Nix)の起動手順 : hasktorch-skeletonのセットアップ 1. Nixをインストール 2. hasktorch-skeletonをgit clone 3. fullのブランチをcheckout 4. 開発シェルの起動 a. nix developを実行 5. jupyter notebookの起動 a. ihaskell-notebookを実行 6. Haskell Kernelを選択。 7. ihaskell-hvegaでグラフを書く。 46
47. Notebook(Nix)の起動手順 : hasktorch-skeletonのセットアップ 1. Nixをインストール 2. hasktorch-skeletonをgit clone 3. fullのブランチをcheckout 4. 開発シェルの起動 a. nix developを実行 5. jupyter notebookの起動 a. ihaskell-notebookを実行 6. Haskell Kernelを選択。 7. ihaskell-hvegaでグラフを書く。 47
48. 目次 • Hasktorchの概要とエコシステム ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化と FFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 48
49. Hasktorchを構成しているパッケージ • libtorch(C++) ◦ pytorchのC++バックエンド • libtorch-ffi ◦ pytorchのバックエンドである libtorchをhaskellから使うためのライブラリ ◦ リソース管理しているレイヤー（パフォーマンスと関係するレイヤー） • hasktorch ◦ テンソルのシェイプについて型あり、型なしの両方のライブラリを提供 ◦ 自動微分に関して、状態に依存しないライブラリ 49 なぜこのアーキテクチャなのか？ • GPU(CUDA)の高性能なカーネル関数の開発は大変 ◦ HaskellのGPUバックエンドの性能が上がらない。 ◦ AccelerateやFutharkといったコンパイラではユーザーが共有メモリが扱えない。 ◦ 逆伝搬のカーネルを書くのはもっと大変 • よくデバッグされている Pytorchのカーネルを利用
50. libtorch-ffiパッケージの構成 • pytorchのバックエンド(libtorch)をhaskellから使うためのライブラリ • コード生成(codegenパッケージ) ◦ libtorchの提供する関数の一覧 (Declarations.yaml)のファイルからコード生成 ▪ yamlファイルからAST（関数の宣言）を生成 ▪ 関数のパース：megaparsec ▪ コード生成：shakespeare ◦ C++のオーバーロードに対応した Haskellの関数を生成 ◦ IOベースにした関数を生成。（ pureでない） • HaskellからC++の関数を呼び出し ◦ FFI(Foreign Function Interface) ▪ HaskellからCの関数を呼ぶ場合 • foreign import ccall "exp" c_exp :: Double -> Double – 宣言 ◦ Template Haskell ▪ inline-c / inline-c-cpp パッケージ (C++のコードをHaskellのコードに埋め込む) ◦ ForeignPtr ▪ C++のリソースをForeignPtrでラップ ▪ GCでC++のリソースを解放するために利用 ◦ Cast(Castable 型クラス) ▪ Raw pointerをForeignPtrにラップするために利用 50
51. パフォーマンス最適化と FFIを用いたメモリ管理 • FFIはunsafe callを利用。（呼び出しのオーバーヘッド削減） • ForeignPtrはc finailizerを使ってdelete • データの読み出しには注意 ◦ ForeignPtrのオブジェクト（destructor付き）をたくさん作るとGCが遅くなるので、時にはC++でアクセス。 • メモリ不足の時にはGCを起動 51
52. FFIはunsafe callを利用 • FFI（Foreign Function Interface） ◦ HaskellからC/C++の関数を呼び出すインターフェース ◦ unsafe call ▪ C++の関数を呼び出し元の Haskellのスレッドで実行 ▪ 元のHaskellのスレッドはブロックされる。 ◦ safe call ▪ C++の関数を別のスレッドを作成し、実行 ▪ 元のHaskellのスレッドはブロックされない。 ▪ 別のスレッドを作成。作成に数十 usくらいかかる。 • 1GHzなら10us = 10000cycle • Hasktorchではunsafe callを利用 ◦ 数十us以下の処理時間なら、 unsafe call が速い 52 CPU CPU HEC HEC Thread Thread L L L L L Thread unsafe call ブロック L safe call 移動 ブロックなし
53. ForeignPtrはc finailizer • ForeignPtr ◦ FFIで利用するメモリの管理用のポインタ ▪ destructorをつけることができる。 ▪ destructorはWeakPtrで管理。 ▪ c finalizerとhaskell finalizerの二つが選択できる。 ◦ c finalizer ▪ c言語で書かれたdestructor ▪ GCの中で実行される。 ▪ すぐにオブジェクトが解放される。（ GCが終わった時には解放されている。） ▪ ただし、GCをブロックしている。 ◦ haskell finalizer ▪ haskellで書かれたdestructor ▪ GCの処理が終わってから実行（ GCが終わった時には解放されてない。） ▪ コンテキストスイッチが発生して遅い。 • GCのプロセスと別に処理する必要がある。 • hasktorchではc finalizerでオブジェクトを解放 53
54. ForeignPtrはc finailizer • ForeignPtr ◦ FFIで利用するメモリの管理用のポインタ ▪ destructorをつけることができる。 ▪ destructorはWeakPtrで管理。 ▪ c finalizerとhaskell finalizerの二つが選択できる。 ◦ c finalizer ▪ c言語で書かれたdestructor ▪ GCの中で実行される。 ▪ すぐにオブジェクトが解放される。（ GCが終わった時には解放されている。） ▪ ただし、GCをブロックしている。 ◦ haskell finalizer ▪ haskellで書かれたdestructor ▪ GCの処理が終わってから実行（ GCが終わった時には解放されてない。） ▪ コンテキストスイッチが発生して遅い。 • GCのプロセスと別に処理する必要がある。 • hasktorchではc finalizerでオブジェクトを解放 54
55. データの読み出しには注意 • ForeignPtrのオブジェクト（destructor付き）をたくさん作るとGCが遅くなる。 ◦ ForeignPtrは頻繁に生成 ▪ 例 • a = ones’ [], b = 3 * a • ForeignPtrは3回作られる。 ◦ ForeignPtrでC++のオブジェクトをdelete ▪ GCで使用の有無を毎回全数チェック ▪ オブジェクトはWeak Pointerで管理 ◦ 不要なForeignPtrの削除は容易ではない。 ▪ LinearTypeはGCと関係がない。（参照がなくなるところで destructorを入れてくれたりしない。） ▪ GHC Pluginでの最適化なら技術的にできるが、最適化する ASTのパターンの定義がネストが深く て簡単ではない。 ◦ 小さなテンソルを結合して大きなテンソルを作成しない（対処療法） ▪ 例 • 画像を読み込む時はByteStringで読み出し、memcpyでテンソルのメモリにコピー 55
56. メモリ不足の時には GCを起動 • GCを呼び出すタイミング ◦ FFIのC++のメモリ不足の例外発生時 ◦ hasktorchのOptimizer型クラスのrunStep関数 ▪ 1epochが終わるたびにGC • メモリのフラグメンテーション対応 ◦ glibcのmallocはフラグメンテーションを起こす。 ▪ rubyで顕著 ◦ malloc_trim関数をGCと一緒に呼び出し。 56
57. 目次 • Hasktorchの概要とエコシステム ◦ Untyped API ▪ 基本的な使い方 ▪ 実際のニューラルネットワーク構築 ◦ Typed API ▪ 基本的な使い方 ▪ 依存型 • Hasktorchのセットアップ ◦ CabalやStackでの開発 ◦ Jupyter NotebookでのHasktorch活用 • Hasktorchの内部 ◦ パッケージ構成 ◦ パフォーマンス最適化と FFIを用いたメモリ管理 • FAQ • Hasktorchの今後と活用の可能性 57
58. よくある質問 • 欲しい関数がない。 ◦ パターン１：hasktorchパッケージにはないが、 libtorch-ffiにはある ▪ hasktorchの関数をみて、libtorch-ffiの関数をラップ ▪ 例 • 平均を計算する関数の例 • mean t = unsafePerformIO $ cast1 Libtorch.mean_t t ◦ パターン２：hasktorchにもlibtorch-ffiにもない。 ▪ 自作してください 58
59. よくある質問 • pytorchで書いたモデルを読みたい。 ◦ state dictファイルにして読み込む。 ◦ hasktorchのmodel-servingの例を参考 59
60. よくある質問 • includeしているファイルがないと言われる。 ◦ 原因 ▪ libtorchがインストールされてない。 ▪ libtorchへのパスが設定されてない。 ▪ libtorchのバージョンが違う。 ◦ 背景 ▪ haskellに精通しているからといってC++に精通しているわけではない。 ▪ 加えて、haskellでC++のライブラリの設定に精通しているわけではない。 ▪ ghcupしか知らないユーザーもいる。 ◦ 対策 ▪ nixを使う。(nixの設定方法、デバッグ、心理的安全性がないとかの問題がある。) ▪ homebrewやaptのパッケージでlibtorchを入れる。 • パッケージシステムに精通しているわけではない。 60
61. よくある質問 • ビルドできたけどライブラリがないと言われる。 ◦ 原因 ▪ libtorchをパッケージ管理ソフトで入れてない。（グローバルに入れてない。） ▪ libtorchの共有ライブラリへの参照がない。 • LD_LIBRARAY_PATHやDYLD_LIBRARY_PATHの設定がない。 ◦ 背景 ▪ haskellに精通しているからといって共有ライブラリに精通しているわけではない。 ◦ 対策 ▪ nixを使う。(nixの設定方法、デバッグ、心理的安全性がないとかの問題がある。) ▪ homebrewやaptのパッケージでlibtorchを入れる。 • パッケージシステムに精通しているわけではない。 61
62. よくある質問 • pytorchのライブラリにリンクするとエラーが出る。 ◦ 原因 ▪ C++のABIのフォーマットが違う ◦ 背景 ▪ pytorchが互換性のために古いgccのABIを使っている ▪ haskellに精通しているからといって共有ライブラリに精通しているわけではない。 ◦ 対策 ▪ -D_GLIBCXX_USE_CXX11_ABI=0をつけてビルドする。 • https://github.com/hasktorch/hasktorch/blob/master/libtorch-ffi/libtorch-ffi.cabal#L171 62
63. よくある質問 • Hasktorchに書き換えたけど遅い。GPUだともっと遅い。 ◦ 原因 ▪ バッチ処理してない。 ▪ 関数のディスパッチ処理が遅い。 ◦ 背景 ▪ テンソルでバッチ処理をしてない小さなデータの処理はディスパッチ処理などの呼び出しのオー バーヘッドの時間が無視できないので遅い。 ▪ 4つのFloatの足し算に1usくらいかかる。（おおよそ1000クロックかかる。） ◦ 対策 ▪ カーネル関数やスライスで一括して処理 ▪ C++でカーネル関数を書く。 ▪ 分析：linuxならperfでどこの関数が遅いのか確認 63
64. まとめ • Hasktorch ◦ 関数型の特徴をもった自動微分をサポートしたディープラーニングのフレームワーク ◦ 純粋関数で計算を記述 ◦ 自動微分はgrad関数で計算 (backward関数がない) ◦ 使いやすく利便性を考慮して開発！！ • 各種OS・ツールでの開発をサポート ◦ Linux、MacOS、Docker、Cabal、Stack、Nix • パッケージ構成 ◦ libtorch-ffi(FFI) • FAQ 64
65. 今後 • 合成可能なモジュール ◦ SpecとDataと推論関数のそれぞれは合成可能だったが、モデルレベルでは合成可能でない ◦ 型なしのAPIでは構築済み ◦ 型ありのAPIで構築(ToDo) • FFIのFusion ◦ Hasktorchの計算はFFIを使っている。FFIの呼び出し回数を減らしたい。 ▪ 一時的なForeignPtrが生成され、GCに負荷をかけているが、それも緩和 ◦ GHC Pluginで構築(ToDo) • Cudaでカーネル関数を生成 ◦ inline-c-cppでhaskellコード上でC++を使ってカーネル関数を生成できるようにした。 ◦ c++でカーネルを書いてHasktorchから呼べるようにした。 ◦ inline-c-cudaを使って構築(ToDo) 65
66. END 66