目次: 射的
スピードシューティングを始めてから10か月です。今日は、第一回目の公式記録会に参加したのと、5月には公式大会(アンリミティッド - 一般社団法人日本トイガン射撃協会JTSA)があります。今までの練習会のタイムをまとめておこうかと思います。
以前と変わらず、基本的に練習は週1回のみです。たまに練習以外のシューティング系イベントにも行きますが、記録を見る限りタイム上達とは関係なさそうです。
今回のUnlimitedの個人目標は合計80秒を切ること、です。特にこの数字に意味はありませんが、自分の実力の壁がこの辺りにあるのと、1ラウンド4秒 → 1ステージ16秒 → 合計タイムが80秒ちょうどになるので、暗算でもわかりやすいのです。
記録を見ると当初は順調に早くなり80秒を切るかと思ったら、ここ最近1〜2か月は全然ダメです。ベストタイムは2/19の80.7秒でした。
日付の * は別のエアガン(グロック17 Gen.4)を使った記録ですが、特に早くも遅くもなりませんでした。道具のせいにするな、腕が悪いんだろって?はい、その通りですね……。
タイムが上下してしまう原因は明らかでして、各ステージのベストスコアとワーストスコアのブレが激しすぎるためです。ベストスコアが偶然重なれば合計80秒台前半、ワーストスコアが重れば合計90秒台です。的を外さないよう、ステージにあったリズムで撃つ、というシューティングの基本ができていない証でしょう。精進あるのみです。
いつか週1という練習頻度の限界が来る気はしますが、まだ遠そうな気配です。あと1か月、怪我しない程度にボチボチやっていこうかなと思います。
目次: RISC-V
完全に自分用メモです。自分でlibcを改造しない限りこのエラーに引っかかることはないでしょう。
世の中にCライブラリの実装はいくつかありますが、musl libcというライブラリがあります。MITライセンスで商用利用等の自由度が高く、最近ですとAWSのコンテナイメージで有名になったAlpine Linuxの標準Cライブラリです。Rustのスタティックリンクにも使われていた気がします。
そんなmusl libcですが、1.1.23からRISC-V 64bitに対応しました。しかしRISC-V 32bitはOpen Future Goalsという位置に置かれ(musl libcの公式WikiのRoadmap)、しばらく実装される見込みがありません。
GNU libcならばRISC-V 32bitに対応していますが、ライセンスの特徴(GPL/LGPLを嫌がる界隈にはお勧めしづらい)とメモリ使用量が多い傾向があります。組み込み向けも狙っているので、GNU libc一本だとちょっと厳しい印象です。印象だけじゃなくてちゃんと評価した方が良い?……おっしゃる通りですね。
このような事情でmusl libcのRISC-V 32bitポーティングにトライしています。
基本的にmusl libcは32bit/64bitで完全に実装を分ける(例: arch/arm, arch/aarch64)設計思想のようです。設計思想に従えば既に存在するarch/riscv64の横にarch/riscv32を新規に追加するのが素直でしょう。
しかしRISC-Vのツールチェーンはmultilibという64/32bitをひとまとめにしたツールチェーンを使えるので、muslの設計思想と合いません。64bit専用と32bit専用のツールチェーンに分けても良いですが、するとGNU libcと合わなくなってしまい困りました。
おそらくmusl libc的には邪道ですが、RISC-V 64bitの実装に「32bitだったらこうして」という条件を追記することにします。
やっと本題です、前置きが長い!RISC-V 32bit用の移植をミスると、GCCのビルド(正確に言うとlibstdc++ のビルド)で下記のようなエラーが出ます。
In file included from gcc/libstdc++-v3/src/c++17/floating_from_chars.cc:78: gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h: In function ‘{anonymous}::fast_float::value128 {anonymous}::fast_float::full_multiplication(uint64_t, uint64_t)’: gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h:281:3: error: ‘__uint128_t’ was not declared in this scope; did you mean ‘__int128__’? 281 | __uint128_t r = ((__uint128_t)a) * b; | ^~~~~~~~~~~ | __int128__
直接の原因はGCCの挙動の差です。RISC-V 64bitだと __uint128_tを定義しますが、RISC-V 32bitだと __uint128_tを定義しません(使用すると未定義型エラーになります)。しかしなぜ __uint128_tを使うコードが有効になるのか、一見しても原因がわかりません。
調べてみるとエラーがドミノのように連鎖して起きていました。ビルドエラーを起こしているソースコードから眺めていきましょう。
// gcc/libstdc++-v3/src/c++17/floating_from_chars.cc
#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64 \
&& __SIZE_WIDTH__ >= 32
# define USE_LIB_FAST_FLOAT 1
# if __LDBL_MANT_DIG__ == __DBL_MANT_DIG__
// No need to use strtold.
# undef USE_STRTOD_FOR_FROM_CHARS
# endif
#endif
#if USE_LIB_FAST_FLOAT //★★RISC-V 64/32bitどちらでも有効になる★★
# define FASTFLOAT_DEBUG_ASSERT __glibcxx_assert
namespace
{
# include "fast_float/fast_float.h" //★★エラーを起こすコードを含んだヘッダ★★
} // anon namespace
#endif
ビルドエラーを起こすfast_float.hのincludeが原因?と思いましたが、64bit/32bitいずれの場合もincludeする条件が成立し、おかしなことは起きていないようです。原因はヘッダの内部でしょう。
// gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h
...
// Need to check incrementally, since SIZE_MAX is a size_t, avoid overflow.
// We can never tell the register width, but the SIZE_MAX is a good approximation.
// UINTPTR_MAX and INTPTR_MAX are optional, so avoid them for max portability.
#if SIZE_MAX == 0xffff
#error Unknown platform (16-bit, unsupported)
#elif SIZE_MAX == 0xffffffff
#define FASTFLOAT_32BIT //★★こちらになるはずでは??★★
#elif SIZE_MAX == 0xffffffffffffffff
#define FASTFLOAT_64BIT //★★こちらが選択されるのはなぜ?★★
#else
#error Unknown platform (not 32-bit, not 64-bit?)
#endif
#endif
...
// compute 64-bit a*b
fastfloat_really_inline value128 full_multiplication(uint64_t a,
uint64_t b) {
value128 answer;
#ifdef _M_ARM64
// ARM64 has native support for 64-bit multiplications, no need to emulate
answer.high = __umulh(a, b);
answer.low = a * b;
#elif defined(FASTFLOAT_32BIT) || (defined(_WIN64) && !defined(__clang__))
answer.low = _umul128(a, b, &answer.high); // _umul128 not available on ARM64
#elif defined(FASTFLOAT_64BIT)
__uint128_t r = ((__uint128_t)a) * b; //★★ビルドエラー発生個所★★
answer.low = uint64_t(r);
answer.high = uint64_t(r >> 64);
#else
#error Not implemented
#endif
return answer;
}
RISC-V 32bit向けなのにFASTFLOAT_64BITが定義されたとき、__uint128_t型が使われるコードがビルドされてエラーになります。ヘッダの上の方を見るとSIZE_MAXに依存しているようで、SIZE_MAXが怪しいです。
// musl/arch/riscv64/bits/stdint.h
typedef int32_t int_fast16_t;
typedef int32_t int_fast32_t;
typedef uint32_t uint_fast16_t;
typedef uint32_t uint_fast32_t;
#define INT_FAST16_MIN INT32_MIN
#define INT_FAST32_MIN INT32_MIN
#define INT_FAST16_MAX INT32_MAX
#define INT_FAST32_MAX INT32_MAX
#define UINT_FAST16_MAX UINT32_MAX
#define UINT_FAST32_MAX UINT32_MAX
#define INTPTR_MIN INT64_MIN
#define INTPTR_MAX INT64_MAX
#define UINTPTR_MAX UINT64_MAX
#define PTRDIFF_MIN INT64_MIN
#define PTRDIFF_MAX INT64_MAX
#define SIZE_MAX UINT64_MAX //★★原因★★
私の移植が適当過ぎてSIZE_MAXの値が64bit向けのままになっていたことが原因でした。先述したようにmusl libc的には邪道ではありますが、32bit向けの分岐を追加します。
#if __riscv_xlen == 64
#define INTPTR_MIN INT64_MIN
#define INTPTR_MAX INT64_MAX
#define UINTPTR_MAX UINT64_MAX
#define PTRDIFF_MIN INT64_MIN
#define PTRDIFF_MAX INT64_MAX
#define SIZE_MAX UINT64_MAX
#elif __riscv_xlen == 32
#define INTPTR_MIN INT32_MIN
#define INTPTR_MAX INT32_MAX
#define UINTPTR_MAX UINT32_MAX
#define PTRDIFF_MIN INT32_MIN
#define PTRDIFF_MAX INT32_MAX
#define SIZE_MAX UINT32_MAX
#endif
分かってしまえば簡単な話ですが、エラーメッセージからこの原因を推測するのはちょっと難しいですね……。
ついに40歳の大台(?)に乗りました。
いわゆる老害というやつにならないように気をつけようと思っていますが、そもそも身近に若い人がいません。これは良いことなのか悪いことなのか??
COVID-19の感染者が増えたとき「第○波」と名付けられていたのは記憶に新しいと思います。大体のピーク時期は下記のようになっていました。(詳細は厚生労働省やNHKのデータをご覧ください)。ざっと4〜6ヶ月に1度に(= 年2〜3回)流行しており、今後も収束しなさそうですね。
全数把握は2022年の9月くらいで終わり、今後はインフルエンザと同じ扱いになっていくのでしょうか?COVID-19が今後どうなるか素人の私にはわかりませんが、災禍ないことを祈るばかりです。
仕事のスタイルも大きく変わりました。勤務先では2020年の春くらいからリモートワークに切り替わり、現在も続いています。当初は、リモートワークなんて余裕余裕〜オフィスに出社しなくて良いなんてラッキー!満員の通勤電車滅びろ、くらいに思っていました。リモートワーク2年やってみて、考えは変わらないもののいくつか気づきもありました。
すぐに気づいたのは「通勤のため家の外に出かける」が意外と自分にとって大事だったことです。頭のモード?気持ち?の切り替えの役目を果たしていたらしく、リモートワークのときは気乗りしない日が増えました。
この話をすると、朝でも昼でも散歩に行けば?と言われますけど、そうじゃないんですね。「自主的」に外に行けるなら、やる気も自主的に出してます。家の外に出る「強制力」と「家の外に出かけることによるスイッチ効果」のコンビが大事だったみたいです。なので、今はたまに用事を作って会社に行く日を作っています。もちろん満員の通勤電車は要らないので滅びてOKなくなってどうぞ。
もうひとつ気づいたのは「社員がオフィスに集まっている状態」で暗黙のうちに得られる情報量の多さです。オフィスにみんなが居ると遠くの雑談が聞こえてきたり、話しかけなくても姿を見れば「忙しそうだ」とか「悩んでいる?」とか情報を得ることができました。リモートワークはそのような暗黙の視覚、聴覚情報が一切ありません。積極的に話しかけない限り、誰が何をしているのかわかりません。
この問題の解決方法はいくつかトライしてみましたが、あまりうまくいっていないように感じています。
社員がオフィスに集まっていたときは、何もアクションしない人にも受動的に情報が入ってきましたが、リモートワークだとなかなかそうはいきません。アクションする人としない人のコミュニケーション機会の差が開いてしまいます。
いやいや、オフィスを無理に再現しようとするから破綻が生じるのだ、潔く諦めチャットなどの文字ベースコミュニケーションをメインにせよ、という割り切りもあります。しかしそれも万能ではなく、文字ベースのコミュニケーションが明らかに苦手な人は放置なのか?どうケアするか?といった新たな問題が生じます。
今は各人、各企業の試行錯誤が続いているのだろうと思います、私は今の所これ!という解がありません。そのうち見つかるんですかねえ。
目次: 自宅サーバー
Dockerを使っていると要らなくなったイメージ、コンテナ、ビルドキャッシュがたまってきて、/varディレクトリ以下が肥大化していることがあります。いつも忘れてしまうお掃除用のコマンドをメモしておきます。
### 終了しているcontainerの削除 $ docker container prune ### 確認 $ docker container ls -a ### タグもなく使われていないimageの削除 $ docker image prune ### 確認 $ docker image ls -a ### build cacheの削除 $ docker builder prune ### 確認 $ docker builder ls
Dockerがディスク容量をどの程度使用しているのかについてはsystem dfが便利(docker system dfのマニュアル)です。
$ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 1 1 14.26GB 0B (0%) Containers 2 1 0B 0B Local Volumes 0 0 0B 0B Build Cache 17 0 0B 0B
昔はコマンドの名前に一貫性がなかった記憶がありますが、今はxxx lsとすれば大抵の場合は一覧が出るため統一感があります。私のようなライトユーザーがやりたいと思う程度の機能は、大抵既に存在しており良くできていてありがたいです。
目次: ベンチマーク
お手軽最適化のメモ、昨日の続きです。行列の掛け算を題材にします。前回は行列の掛け算と素朴な実装のコードを紹介しました。今回はお手軽最適化を紹介します。
スカラー処理だと遅いけれど、お手軽に最適化(数倍程度)がしたいときの参考になれば幸いです。
素朴版のコードですとi, j, kの順でループになっていて、kを最内ループにしていました。ループ内の計算は、
c[i * nn + j] += a[i * kk + k] * b[k * nn + j]
でした。このときメモリアクセスのパターンは、
です。GCCの自動ベクトル化ですと、このアクセスパターンをうまく最適化できないようです。対象が最内ループのみなのかもしれません。ループを入れ替えjを最内にして、BとCを行方向に読むようにします。するとメモリアクセスのパターンは、
です。ループを入れ替えるとループ内でCの0初期化ができないので、ループの外に追い出して最終的に下記のようなコードになります。
void sgemm_inner(const float *a, const float *b, float *c, int mm, int nn, int kk)
{
for (int i = 0; i < mm; i++) {
for (int j = 0; j < nn; j++) {
c[i * nn + j] = 0.0f;
}
}
for (int i = 0; i < mm; i++) {
for (int k = 0; k < kk; k++) {
for (int j = 0; j < nn; j++) { //★★jが最内ループ★★
c[i * nn + j] += a[i * kk + k] * b[k * nn + j];
}
}
}
}
$ gcc -Wall -g -O2 -fno-tree-vectorize -static -march=znver3 sgemm.c $ ./a.out matrix size: M:1519, N:1517, K:1523 time: 1.528314 (参考: 素朴版の実行時間) time: 2.277758 (参考: OpenBLASシングルスレッドの実行時間) $ export OPENBLAS_NUM_THREADS=1 ----- use CBLAS verify: 0.052149
ループ入れ替えで倍くらい速くなっていますが、この最適化の本領はコンパイラの自動ベクトル化です。GCCならば -ftree-vectorizeオプションを指定すると、行列Bと行列CへのアクセスにSIMD命令を使うようになります。
Ryzen 7 5700Xの場合はAVX2命令を使えます。他のCPUをお使いの場合は -marchを適宜変更してください。
$ gcc -Wall -g -O2 -ftree-vectorize -static -march=znver3 sgemm.c $ ./a.out matrix size: M:1519, N:1517, K:1523 time: 0.181133 (参考: OpenBLASシングルスレッドの実行時間) $ export OPENBLAS_NUM_THREADS=1 ----- use CBLAS verify: 0.052149
素朴版とOpenBLASでは1/43もの差がありましたが、ループ入れ替えと自動ベクトル化によってOpenBLASの1/3.5程度まで近づきました。GEMMが計算偏重の処理で最適化の効果が出やすい、という点を考慮する必要はあるものの僅かな書き換えで得られる効果にしては割と良いのではないでしょうか。
ソースコードを書き換える元気があれば、別の最適化方法もあります。GEMM特有の話に近付いてしまい、汎用的な話から遠ざかりますが、最適化ポイントの例という意味では参考になるはず……です。たぶん。
今回はSIMD命令でjの方向に一気に読むまでは同じですが、jの方向に進めるのではなく、kの方向に進めて、計算結果をCに足していく戦略です。具体的に言えばAi,kとBk,j〜Bk,j+7の8要素を一気に掛け算してCi,j〜Ci,j+7へ一気に足します。なぜ8要素かというとAVX/AVX2のレジスタ長(256bit)を使うと、32bit長のfloatを一度に8要素処理できるためです。
SIMD命令にはAi,kをSIMDレジスタの全要素に配る命令(set1_psから生成されるbroadcast命令)や、掛け算と足し算を一度に行うfmadd命令など、この計算順に最適な命令が揃っています。
AVX/AVX2のIntrinsicsの詳細についてはIntelのサイトなどを見ていただくとして(Intel Intrinsics Guide)、コードは下記のようになります。
#include <immintrin.h>
void sgemm_avx(const float *a, const float *b, float *c, int mm, int nn, int kk)
{
for (int j = 0; j < nn;) {
if (nn - j >= 8) {
for (int i = 0; i < mm; i++) {
__m256 vc = _mm256_set1_ps(0.0f);
for (int k = 0; k < kk; k++) {
__m256 va = _mm256_set1_ps(a[i * kk + k]);
__m256 vb = _mm256_loadu_ps(&b[k * nn + j]);
vc = _mm256_fmadd_ps(va, vb, vc);
}
_mm256_storeu_ps(&c[i * nn + j], vc);
}
j += 8;
} else {
for (int i = 0; i < mm; i++) {
c[i * nn + j] = 0.0f;
for (int k = 0; k < kk; k++) {
c[i * nn + j] += a[i * kk + k] * b[k * nn + j];
}
}
j++;
}
}
}
$ gcc -Wall -g -O2 -static -march=znver3 sgemm.c $ ./a.out matrix size: M:1519, N:1517, K:1523 time: 0.384861 (参考: 素朴版の実行時間) time: 2.277758 (参考: ループ入れ替え版+自動ベクトル化の実行時間) time: 0.181133 (参考: OpenBLASシングルスレッドの実行時間) $ export OPENBLAS_NUM_THREADS=1 ----- use CBLAS verify: 0.052149
素朴版と比べると6倍速いですが、ループ入れ替え+自動ベクトル化には負けています。
先程のコードはSIMDレジスタを3個しか同時に使っていませんでした。AVX/AVX2のYMMレジスタは16個もあるのに3個しか使わないのはもったいですから、iのループを8要素ずつアンローリングしてSIMDレジスタを同時にたくさん使いましょう。レジスタをうまく使いまわせば12要素のアンローリング(Bの保持に1個、Cの保持に12個、Aの保持に1個、計14個)まではできそうです。たぶん。
#include <immintrin.h>
void sgemm_avx_unroll8(const float *a, const float *b, float *c, int mm, int nn, int kk)
{
for (int j = 0; j < nn;) {
if (nn - j >= 8) {
int i = 0;
for (; i < (mm & ~7); i += 8) {
__m256 vc0 = _mm256_set1_ps(0.0f);
__m256 vc1 = _mm256_set1_ps(0.0f);
__m256 vc2 = _mm256_set1_ps(0.0f);
__m256 vc3 = _mm256_set1_ps(0.0f);
__m256 vc4 = _mm256_set1_ps(0.0f);
__m256 vc5 = _mm256_set1_ps(0.0f);
__m256 vc6 = _mm256_set1_ps(0.0f);
__m256 vc7 = _mm256_set1_ps(0.0f);
for (int k = 0; k < kk; k++) {
__m256 vb = _mm256_loadu_ps(&b[k * nn + j]);
__m256 va0 = _mm256_set1_ps(a[(i+0) * kk + k]);
__m256 va1 = _mm256_set1_ps(a[(i+1) * kk + k]);
__m256 va2 = _mm256_set1_ps(a[(i+2) * kk + k]);
__m256 va3 = _mm256_set1_ps(a[(i+3) * kk + k]);
__m256 va4 = _mm256_set1_ps(a[(i+4) * kk + k]);
__m256 va5 = _mm256_set1_ps(a[(i+5) * kk + k]);
__m256 va6 = _mm256_set1_ps(a[(i+6) * kk + k]);
__m256 va7 = _mm256_set1_ps(a[(i+7) * kk + k]);
vc0 = _mm256_fmadd_ps(va0, vb, vc0);
vc1 = _mm256_fmadd_ps(va1, vb, vc1);
vc2 = _mm256_fmadd_ps(va2, vb, vc2);
vc3 = _mm256_fmadd_ps(va3, vb, vc3);
vc4 = _mm256_fmadd_ps(va4, vb, vc4);
vc5 = _mm256_fmadd_ps(va5, vb, vc5);
vc6 = _mm256_fmadd_ps(va6, vb, vc6);
vc7 = _mm256_fmadd_ps(va7, vb, vc7);
}
_mm256_storeu_ps(&c[(i+0) * nn + j], vc0);
_mm256_storeu_ps(&c[(i+1) * nn + j], vc1);
_mm256_storeu_ps(&c[(i+2) * nn + j], vc2);
_mm256_storeu_ps(&c[(i+3) * nn + j], vc3);
_mm256_storeu_ps(&c[(i+4) * nn + j], vc4);
_mm256_storeu_ps(&c[(i+5) * nn + j], vc5);
_mm256_storeu_ps(&c[(i+6) * nn + j], vc6);
_mm256_storeu_ps(&c[(i+7) * nn + j], vc7);
}
for (; i < mm; i++) {
__m256 vc = _mm256_set1_ps(0.0f);
for (int k = 0; k < kk; k++) {
__m256 vb = _mm256_loadu_ps(&b[k * nn + j]);
__m256 va = _mm256_broadcast_ss(&a[(i+0) * kk + k]);
vc = _mm256_fmadd_ps(va, vb, vc);
}
_mm256_storeu_ps(&c[i * nn + j], vc);
}
j += 8;
} else {
for (int i = 0; i < mm; i++) {
c[i * nn + j] = 0.0f;
for (int k = 0; k < kk; k++) {
c[i * nn + j] += a[i * kk + k] * b[k * nn + j];
}
}
j++;
}
}
}
$ ./a.out matrix size: M:1519, N:1517, K:1523 time: 0.108420 (参考: ループ入れ替え版+自動ベクトル化の実行時間) time: 0.181133 (参考: OpenBLASシングルスレッドの実行時間) $ export OPENBLAS_NUM_THREADS=1 ----- use CBLAS verify: 0.052149
もはや最適化前のコードの原型がありませんが、ループ入れ替え版+自動ベクトル化の1.7倍くらいの速度になりました。OpenBLASの1/2程度まで迫っています。この最適化手法が汎用的か?と聞かれると何とも言えないですが、SIMDレジスタを同時にたくさん使う、最内ループ以外もアンローリング(最内ループはコンパイラがやってくれる)辺りは割と汎用的なアイデアです。
あと前回言った通り、GEMMは最適化の題材として取り上げただけなので、実際にGEMMを計算する場合はこのコードや自分で書いたコードを使うのではなく、信頼と実績のOpenBLASを使ってくださいませ。
< | 2023 | > | ||||
<< | < | 03 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 | - |
合計:
本日: