憧れのAOT

実行時間を見ていると、今までそんな感じはあまりなかったのですが、どうも初回の時に確実に時間がかかっている印象。

特定の条件下だと、この初回の待ち時間が無いような感じがするのと、特定の条件下だと不意に時間がかかるような感じがハッキリと見てて来ました。

この奇妙なウェイト…JavaとかのJITと呼ばれるジャストインコンパイルの感触にとても似ていました。まさか…と思って検索しているとSYCLも何気にデフォルトでは中間コードにコンパイルしているだけのようで、実行時にネイティブコードへさらに変換してから実行しているとのこと…マジかｗ

とこれが先週末に初めて知って、その対応としてAOTと呼ばれるコンパイル時に中間コードからさらにネイティブコードへコンパイルし、実行ファイルとマージする仕組みが存在することを知る…。

この辺で正直お腹いっぱいです(笑)

で、ドキュメントを見ると理論だけ説明したドキュメントしか検索されなくなり…

しかも、実際のデバイスを識別するコードも表記ゆれがあったりで、何が本当なのかも正直分からなくなっちゃいました。実機はN150のalder lakeのnシリーズとかいうらしく、識別子はadl-nとかadl_nとか…現状、実際にコンパイルするとadl_nでないとエラーになることがあったり、出来上がったバイナリは小さくなってたり…。あとmakeを繰り返していたら実行ファイルがいつの間にか巨大化していた事実…。

幾つかの謎がまじりあって…結局AOTでコンパイルして出来上がったバイナリは、実行時にSegmentation fault (core dumped)で落ちる始末…

geminiに何回か聞いてみたんですが具体的な回答は得られなかったことからこの辺の仕様は変化が激しいようで… 

デバッグ出力などもイマイチほしい情報が見れなくなってたり、本当にお手上げ…sycl自体githubに上がっているのでそっちを調べていかないとダメなのかもしれません。

あと、この辺になるとなぜかvllmの話が多く引っかかるようになったきがします。

ちなみにggmlのCMakeFiles.txtにはコメントで :AOT とか書かれているところを見ると、対応していたけど、現状では動かなくなってしまったか、もとから動かなかったのかそんな感じになっています。一回りして見てみると、ビルド用のコードはちゃんと指定している感じなんですけどね。

ただ、AOTにしようとすると今までJITで自動的に生成されていたものがあらかじめバイトコードにになっている必要があるのですが、よくよく考えてみると、GPUだけではなくCPUのコードも使っているのではないか？と言う部分もあるのでCPUとGPU両方のコードを指定する必要がある気がするのですが…指定しても結果は変わらなかったんですよねぇ…まぁこの辺はハッキリしないのでそこまで突っ込んできちんとビルド手順を踏んでいないので気が向いたらやってみようかという感じですが。

で、そうこうしているうちに、結構本家のコードが変わってきました(笑)

llama.cppのggmlは色々と手が加わっていてim2col関連も一次元配列に特化したコードが作られていたり、まぁそれなりの変化があるわけですが、根本てきな部分でも結構変わっているようで、今ビルドしたら、ggml部分を手持ちの物に挿げ替えたらビルドできなくなってました（涙

そしてあまりコードが増えるとJITされるタイミングが増えるので、正直どちらの方向性が正しいのかと言うのも気にはなりますね。

ちなみに情勢としてはハングアップする理由よりもどうも一括で実行できるように変形するという流れが強いようで…だれもポンコツキューのことは気にしていない様子(笑)

画像生成にsyclを使うとか奇特な人間は普通はしないだろうし、iGPUで遊んでいる人もほとんどいないと思うので当然かもしれませんが...