2026-02
2026-02-28
pe
f32 2402.6290 +/- 18.18653
f16 2400.0132 +/- 18.16830
かわらん
1スレッドで1点を計算するが、畳みこみなので過去のn_conv点を参照する。するとn_convスレッドが同じ点を参照することになり、メモリ帯域を圧迫する
これはスレッド単位で過去の点のウィンドウをレジスタあたりに持っておき、1スレッドでN >> n_convであるN点を計算することで解決できる
実際 Prefill では高速化された(Decode は連続する点を処理しないのでこのスコープではない)が、FFN のための行列積があまりに支配的であって速度は向上しなかった
明らかに速度に影響しないというところまで落とせたので悪くはなさそうだが
2026-02-26
書くことってあんまりないのだよな
と言いながら書く
が、ROCm を使った場合と同じくらい遅くて、CPUが使われている
他のアーキテクチャにおける SSM State の大きさ(d_state)が128や256である一方、PLaMo2 は 64 らしく、GPUカーネルが起動していなかった なんか浅くないか?指示追従性の悪さってここに起因してるんじゃあ
既存のカーネルが使い回せるかはd_stateが Subgroup Size の倍数であるかに依存しているが、さすがに 64 を超える(SIMD96とか!?!?!?) GPU は存在しないだろ(あったとして分割互換モードがあるだろ)ということで分岐を追加したらデコードの速度が1.5倍になって満足
実際どうなんだろう、今の AMD は SIMD32 の Dual Issue だから、将来的には演算規模としてはそれくらいになってもおかしくはない。しかしむやみに SIMD の幅を広げるとレジスタファイルが猛烈に食われるわけで……(レジスタファイルにトランジスタを食われるくらいなら Dual Issue の制御を入れてしまえという気持ちで今の構成になってそうだし) というかSIMDだと足りんぜ！ということで行列演算なのではないか
2026-02-22
大阪に行った
そんなか?と思った。そんなものなのかもしれない
時代は天王寺璃奈
新世界→天王寺→日本橋筋→日本橋商店街→難波
逆走。
ダ・カーポは?
……
不意の出来事により物語性が付与され、「アイドルとは物語だ」の顔付きに
ストーリー読んでてよかった。オカピで険しい顔になった甲斐があったというもの
それはそれとして苦しい♪
2026-02-21
2026-02-01
東所沢の光るマンホールいつ見ても面白い