toolsの機能自体はあまり積極的に動かさないようなのですが、時間がかかっても構わないからデバッグログの解析をgemma4でやってもらおうとチャット形式で指示してみました。
デバッグの出力ログはstable-diffusion.cppのsyclの出力なので非常に大きいです(笑)
ざっくり見てもそれなりにどんな機能が動いているのかはわかるのですが、各関数がどの程度動いているのかボリューム感までは把握しづらい面もあり、お試しで試してみることにしました。
最初に対象のファイルがデバッグ出力のログであることを明示したうえで、ファンクション名を抜き出してもらおうとしたところ、やはり最初の100行程度でテキストを集計してくれました。ここでgrepサーチを利用する前提で、３パターンほど全体の集計を行うための方法の提示がありました。
A. すべてのユニークな関数/処理名とその合計出現回数
B. 特定の関数名（例: ggml_check_sycl）の出現回数
C. さらに多くの行を読み込んで分析を続ける
とりあえず、Aを行ってもらおうとしましたが、結局grepで該当行だけ抜き出したファイルの先頭156行程度を集計するにとどめ、要望があればその後も続けるとのことですが…まぁそこまでは…という事で実行時に正規表現などを当然のように利用していたので試しに
👨bashでこのような出力を行えるスクリプトを提示してもらえますか？
と問いかけたところ…
🤖はい、もちろんです。ログファイルが非常に大きい（76MB）ことを考慮し、Bashと**grep, awk、sort**, **uniq**といった標準的なUNIXツールの組み合わせで、ご要望の集計を行うスクリプトの例を提示します。
と、超やる気満々の返答とともにbashのスクリプトが出来上がりました。今までgeminiには部分的に聞いたりしたことはあったのですが、すっごい漠然とした指示でスクリプトを依頼したことはありませんでした。
実際に出来上がったもので、とりあえずはいいんですが、どうせならと、具体的にどうしたいか伝えたところ、さらにスクリプトが提示されました。
今までawkは使ったことが無いので良くは分かりませんが、結構何でもテキスト整形するのは便利そうなのは伝わってきました。
まぁ残念なポイントは２つめのスクリプトは丁寧なコメントが入っていたために、そのコメント内でシングルコーテーションがそのまま使用されていたために、そこでスクリプトエラーが発生してしまいましたが、ロジック的にはそれなりに動く感じです。ただgemma4は注視するポイント以外はかなりぼやけてしまうようで、前提となる動作は無視されるようなスクリプトとなっていたため、２つのスクリプトを掛け合わせ、当初予定していた集計が結構手軽に作成できるようになりました。
以前行ったときは力業で表計算（calc）を使ったんですが、テキストサイズが10Mとか超えると何をやるのも結構大変なことになるのですが、試しで集計してみたのですが、正直もうめんどうすぎてやる気はおこりません(笑)
修正後のコードとか、エラーとかの事もフィードバックさせて伝えると、もっと良いロジックになるよとさらなる提示がされました。ちょっと見たところ、まぁ思っている感じにはならないコードでしたが(笑)
試しに実行したところまぁそうだよね…と言う結果に。
多分、フィードバックすれば修正も行えると思えますけど…まぁそこまでは(笑)逆にE4Bモデルで簡単なスクリプトを作ってくれるだけでも正直驚くべきところでしょう。（今までチャットで会話を楽しんでいた程度だったので(笑)）
ちなみに一番相手をしてもらっているE4Bでもシステムプロンプトを設定すると結構な頻度で会話のレベルで破綻したりすることを確認していますが、ある程度の範囲内ならコンテキストをかなり大きくしてたりしますがかなりいい感じで話を続けることができています。
今のところtoolsの利点は、直接ファイルを参照してもらうのに便利程度と言った感じでしょうかね…起動スクリプトとか読み込ませると勝手にたどってくれそうではあるので、もう少し使えるかな？(笑)
ちなみに集計結果は、
309812 WaitForSubmit
186366 ggml_backend_sycl_device_supports_op
83926
62945 ggml_backend_sycl_buffer_init_tensor:
62160 ggml_sycl_compute_forward:
35626 ggml_sycl_op_mul_mat_sycl
31080 ggml_sycl_compute_forward
27638 adjustment_local
13819 operator()
11534 ggml_cpy_f32_f32_sycl
2281 call
2212 ggml_backend_sycl_device_get_memory
1840 dequantize_row_q3_K_sycl
1800 ggml_sycl_op_im2col
1696 dequantize_row_q4_K_sycl
1322 [SYCL]
1106 get_zes_init_res:
1106 get_memory_size_by_sycl_api:
1072 norm_f32_sycl
1029 ggml_sycl_op_unary
981 ggml_backend_sycl_buffer_set_tensor:
809 ggml_backend_sycl_host_buffer_type_for_device
752 convert_unary_nc_sycl
709 scale_f32_sycl
224 dequantize_block_sycl
184 ggml_backend_sycl_synchronize
128 dequantize_row_q5_K_sycl
50 ggml_backend_sycl_graph_compute_impl
48 ggml_sycl_adjusted_looper
48 ggml_cpy_f32_f16_sycl
30 ggml_backend_sycl_buffer_get_tensor:
26 ggml_backend_sycl_buffer_reset
15 ggml_backend_sycl_buffer_type_alloc_buffer:
3 ggml_backend_sycl_reg
3 ggml_backend_sycl_host_malloc
1 ggml_sycl_init
1 ggml_check_sycl
1 ggml_backend_sycl_print_sycl_devices
1 ggml_backend_sycl_init.
手前味噌な処理がトップに上がっちゃってたりしますが、ファンクション内で何度も出力してる場合はその数が積算されちゃってたりするはずですが、まぁ傾向と対策はこれで行いやすくなりそうです。二行目の空行はたぶんパラメータとか複数行に跨るパターンとか、[SYCL]で始まってない行とか、そんなのかな？
0 件のコメント:
コメントを投稿