オクトラⅡ、画質最高で時々ハングする問題が解決したかどうか試さないといかんのかな…

Arcのドライバ、8/23リリースの31.0.101.4669に更新したけどdistribued.net clientの（cl-std=1.1非対応）問題は解決してないっすね。バイナリパッチをdnetc.exeに当てろってことで良いんですかね…

とりあえず自分のコーディングスタイルを見直すきっかけにはなった。一応style(9)準拠にしてるのでそれを継続ってことで。

;でインデント、面白いアイデアだとは思うけど…

for (i = 0; i < 200; i++)
do_something();

みたいなケースへの対応は難しいんじゃないかなあ。

まあコーディングスタイルを新しく作ってるようなもんだから、たとえfor()だのifだのに続く処理が一行しか無くても必ず{}で括れというスタイルを強制した上で;でインデントしろよなー、ということなんだろうけど。

tiger lake(11th Gen)以降のCeleron/PentiumはAVX2対応持ってるので、一生懸命SSE対応したところで意味無いんだよね実は。

LPCNet、本家はxiphのなんだけど…FreeDV2020向けのdrowe67版をここしばらく触っていて、本家からかなり乖離しちゃってるから少しメンテしないといけないのかもね（SSE周りとか）というのがあらすじ。

8x4(sparse_sgemv_accum8x4)対応は取り込めないかなーと思ってみてみたけど、これはかなり影響範囲が大きそうなのでやめた方が良いのかも https://github.com/xiph/LPCNet/commit/4a39b4131a0ea28208831e179b0f1d10470b449b

なので、結局は
- vec_sse.hは廃止
- vec_avx.hをそこそこ新しくする
- SSEの時もvec_avx.hを使うようにお願いする
という対応が今できる最善ってことになるか。vec.hの挿げ替えもちょっと危ないかな。

パンを食った枚数をいちいち覚えちゃいないのと同様、投げたPRなんていちいち覚えちゃいないよ。

…ってこんなこと書いてると「ロクにテストもせず何やってんの」と言われそうだなあ。あん時何やってたんだっけ自分というのを振り返ってるだけなんだが…

あと、これも検証。defined(__AVX__)であればvec_avx.hを通すことでAVX化は可能、defined(__SSE__)が無い場合はvec_avx.hも通さないしSSE化もしない（それ以前にビルドエラーで止まる）。

なので、defined(__SSE__)でなんかする、でSSE対応してたという過去の話についてもまあ（やってることが怪しいとはいえ）多少の意味はあったということか。

一応供養のために動作テストをしてみたけども…

- vec_sse.hの結果はベクタ命令使わない場合と同じ（vec_avx.hの結果は少し異なる）
- 当然だけどvec_avx.h使えばSSE/AVX同じ結果になる
- vec_sse.hだと16.6sec, vec_avx.hでSSE化すると8.8sec（AVXと遜色ない結果になる）

やっぱ廃止で正解かな？出力結果は間違いじゃなかったみたいだけど。

自分で言うのもなんだけど、vec_sse.hなんてクソ（を放り込んだのは自分）を放り込む前に、何故vec_avx.hがSSE対応してるかを見抜けなかったのかと当時の自分に説教したい…という訳で、きちんと尻を拭おうと思います。ごめんなさい。 https://github.com/drowe67/LPCNet/pull/60

こっちにする https://raw.githubusercontent.com/xiph/LPCNet/55d6f1b5eb9902301ecbef9e726303d252a620b7/src/vec_avx.h

めも：https://raw.githubusercontent.com/xiph/LPCNet/3ac930e9b78edbf350f5efadb486a6214b5f189f/src/vec_avx.h

ほぅ…

このアカウントは、notestockで公開設定になっていません。