コグノスケ


link 未来から過去へ表示(*)
link 過去から未来へ表示

link もっと前
   2023年 3月 3日 >>> 2023年 2月 22日
link もっと後

2023年 3月 3日

Docker のお掃除コマンド

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 とすれば大抵の場合は一覧が出るため統一感があります。私のようなライトユーザーがやりたいと思う程度の機能は、大抵既に存在しており良くできていてありがたいです。

編集者: すずき(更新: 2023年 3月 8日 14:52)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2023年 2月 28日

SIMD を使ったお手軽最適化 - その 2

お手軽最適化のメモ、昨日の続きです。行列の掛け算を題材にします。前回は行列の掛け算と素朴な実装のコードを紹介しました。今回はお手軽最適化を紹介します。

スカラー処理だと遅いけれど、お手軽に最適化(数倍程度)がしたいときの参考になれば幸いです。

お手軽コース - 自動ベクトル化

素朴版のコードですと i, j, k の順でループになっていて、k を最内ループにしていました。ループ内の計算は、

ループ内の計算式

c[i * nn + j] += a[i * kk + k] * b[k * nn + j]

でした。このときメモリアクセスのパターンは、

  • A: 行方向に連続(メモリアクセスパターンは連続 = 自動ベクトル化できる)
  • B: 列方向に連続(メモリアクセスパターンは飛び飛びアクセス = 自動ベクトル化できない)
  • C: 同一要素を何度もアクセス


素朴版の計算順(i, j, k ループ)

です。GCC の自動ベクトル化ですと、このアクセスパターンをうまく最適化できないようです。対象が最内ループのみなのかもしれません。ループを入れ替え j を最内にして、B と C を行方向に読むようにします。するとメモリアクセスのパターンは、

  • A: 同一要素を何度もアクセス
  • B: 行方向に連続(メモリアクセスパターンは連続 = 自動ベクトル化できる)
  • C: 行方向に連続(メモリアクセスパターンは連続 = 自動ベクトル化できる)


ループ入れ替え版の計算順(i, k, j ループ)

です。ループを入れ替えるとループ内で C の 0 初期化ができないので、ループの外に追い出して最終的に下記のようなコードになります。

SGEMM ループ入れ替え版

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];
			}
		}
	}
}
SGEMM ループ入れ替え版の実行時間
$ 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 を適宜変更してください。

SGEMM ループ入れ替え版+自動ベクトル化の実行時間
$ 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 が計算偏重の処理で最適化の効果が出やすい、という点を考慮する必要はあるものの僅かな書き換えで得られる効果にしては割と良いのではないでしょうか。

もう少し頑張るコース - intrinsics

ソースコードを書き換える元気があれば、別の最適化方法もあります。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要素処理できるためです。


Intrinsics 版の計算順

SIMD 命令には Ai,k を SIMD レジスタの全要素に配る命令(set1_ps から生成される broadcast 命令)や、掛け算と足し算を一度に行う fmadd 命令など、この計算順に最適な命令が揃っています。


broadcast 命令


fmadd 命令

AVX/AVX2 の Intrinsics の詳細については Intel のサイトなどを見ていただくとして(Intel Intrinsics Guide)、コードは下記のようになります。

SGEMM Intrinsics 版

#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++;
		}
	}
}
SGEMM Intrinsics 版の実行時間
$ 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個)まではできそうです。たぶん。

SGEMM Intrinsics+ループアンローリング版

#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++;
		}
	}
}
SGEMM Intrinsics+ループアンローリング版の実行時間
$ ./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年 3月 5日 14:13)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2023年 2月 27日

SIMD を使ったお手軽最適化 - その 1

お手軽最適化のメモです。行列の掛け算を題材にします。

最初にお断りしておくと GEMM のような汎用処理の場合は、自分で最適化せずに OpenBLAS を使ってください(素人が最適化しても勝てません)。しかし OpenBLAS のような限界まで最適化されたコードは誰でも簡単には書ける、とは言えません。

スカラー処理だと遅いけれど、お手軽に最適化(数倍程度)がしたいときの参考になれば幸いです。

GEMM ってなんですか?

GEMM は General Matrix Multiply の略で、高校数学辺りでやった(はず)の行列の掛け算のことです。float の場合は SGEMM と呼ばれ、double の場合は DGEMM と呼ばれます。最適化の題材はどちらでも良いんですけど、今回は SGEMM を使います。

忘れている方のために 2行 3列の行列 A と 3行 2列 B の掛け算 A x B = C だとこんな感じです。


行列の掛け算の例

A の列数と B の行数は一致していなければなりません。行数と列数の関係を表すと、行列 A(M行 K列)x 行列 B(K行 N列)= 行列 C(M行 N列)となります。


行列の掛け算の行数と列数

C の 1要素を計算するには、A の 1行と B の 1列が必要です。式、および、視覚的に示すと下記のようになります。


行列の掛け算(式)


行列の掛け算(A の行と B の列の関係)

説明はこれくらいにしてコードを見ましょう。

基本コース - 素朴に演算

SGEMM を素直にコードにするとこんな感じです。行方向にデータを格納(Row-major order といいます)しているので、N列の行列 C の i行 j列(以降 Ci,j と書く)にアクセスする際は c[i * N + j] とします。

SGEMM 素朴版

void sgemm_naive(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 k = 0; k < kk; k++) {
				c[i * nn + j] += a[i * kk + k] * b[k * nn + j];
			}
		}
	}
}

行列のサイズを適当に設定(M = 1519, N = 1517, K = 1523)して、実行時間を測ります。CPU は Ryzen 7 5700X です。

SGEMM 素朴版の実行時間
$ gcc -Wall -g -O2 -static sgemm.c

$ ./a.out
matrix size: M:1519, N:1517, K:1523
time: 2.277758

実行時間は実行するたびに変わりますが、大体 2.27秒くらいでしょうか。OpenBLAS のシングルスレッド(環境変数 OPENBLAS_NUM_THREADS=1 にするとシングルスレッド動作になります)で計算した時間を見ると、

OpenBLAS の SGEMM を呼ぶコード

	c_ex = malloc(m * n * sizeof(float) * 2);

	// C = alpha AB + beta C
	float alpha = 1.0f, beta = 0.0f;
	int lda = k, ldb = n, ldc = n;

	printf("----- use CBLAS\n");

	gettimeofday(&st, NULL);
	cblas_sgemm(CblasRowMajor, CblasNoTrans, CblasNoTrans,
		m, n, k, alpha, a, lda, b, ldb, beta, c_ex, ldc);
	gettimeofday(&ed, NULL);
	timersub(&ed, &st, &ela);

	printf("verify: %d.%06d\n", (int)ela.tv_sec, (int)ela.tv_usec);
OpenBLAS の SGEMM 実行時間
$ export OPENBLAS_NUM_THREADS=1

$ gcc -Wall -g -O2 -static -L path/to/openblas/ sgemm.c -lopenblas

$ ./a.out
matrix size: M:1519, N:1517, K:1523
----- use CBLAS
verify: 0.052149

わずか 0.05 秒、実に 43倍という驚異のスピードです。すごいですね……。

行列の掛け算の説明でほぼ終わってしまいました。お手軽最適化はまた次に。

編集者: すずき(更新: 2023年 2月 28日 02:01)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2023年 2月 25日

東京の道の名前

東京の道はようわからん通称(明治通り、みたいなやつ)が付いています。東京育ちの人にはなじみ深い名前だと思うんですが、都外出身者からすると、東京の道の通称と国道何号線、都道何号線の区分が全く合っていないので、知らない場所の道の通称を言われると結構困ります。

なぜかというと国道何号線、都道何号線という表記は地図で省かれることはない一方で、東京の道の通称は高速道路や地下鉄と重なったときに省かれてしまうことがあるためです。地図を見ても「〇〇通り?何それ?どこ??」と困惑します。

通称とは一体?

東京の道の通称は東京都が決めています(東京都通称道路名〜道路のわかりやすく親しみやすい名称〜 - 東京都建設局)。道案内の青看板に載るような名前と思ってもらえばわかりやすいでしょう。

東京都がまとめてくれているのはありがたいんですが「東京都が公式に定めた通称」というのは不思議な響きで、それは公称ではなかろうか?通称とは一体……??

なぜか存在しない大正通り

東京の道の通称には「年号」+「通り」という名前がいくつかあります。このうちなぜか大正通りだけは存在しません。不思議ですね。

  • 江戸通り(No.26: 国道6号など、千代田区大手町二丁目〜台東区花川戸二丁目)
  • 明治通り(No.3: 都道416, 306号など、港区南麻布二丁目〜江東区夢の島)
  • 昭和通り(No.24: 国道4号など、港区新橋一丁目〜台東区根岸五丁目)

調べてみると割と有名な話らしいです(「明治通り」「昭和通り」はあるのに、なぜか「大正通り」はない東京のちょっとした謎 - アーバン ライフ メトロ)。詳しくは記事を読んでいただくとして、簡単に言えば、

  • 東京日日新聞の公募で大正通りと呼ぼうとした(今の靖国通り)が定着せず
  • 東京都の公募で靖国通りが選ばれた、東京都建設局のまとめる一覧に大正通りは入ってない
  • 東京に「大正通り」はある(武蔵野市吉祥寺)
  • 「平成通り」もある(中央区兜町〜築地二丁目)
  • 「令和通り」はまだない

ということみたいです。

編集者: すずき(更新: 2023年 2月 27日 00:16)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2023年 3月 3日 >>> 2023年 2月 22日
link もっと後

管理用メニュー

link 記事を新規作成

<2023>
<<<03>>>
---1234
567891011
12131415161718
19202122232425
262728293031-

最近のコメント 5件

  • link 23年01月06日
    すずき 「ありがとうございます。アップデートとかセ...」
    (更新:01/24 23:19)
  • link 23年01月06日
    カナやん 「あまり褒められた方法じゃないですが、Am...」
    (更新:01/24 21:37)
  • link 22年10月10日
    すずき 「ああー、懐かしいですね。いきなりWind...」
    (更新:10/12 00:51)
  • link 22年10月10日
    hdk 「いつ頃だったかのMicrosoft Of...」
    (更新:10/11 20:31)
  • link 22年09月19日
    すずき 「それもありますね。さらに調べていたら今回...」
    (更新:09/26 11:51)

最近の記事 3件

  • link 23年03月10日
    すずき 「[誕生日] ついに 40歳の大台(?)に乗りました。いわゆる老害と...」
    (更新:03/11 15:06)
  • link 23年03月03日
    すずき 「[Docker のお掃除コマンド] Docker を使っていると要...」
    (更新:03/08 14:52)
  • link 20年01月27日
    すずき 「[クロスビルド用ツールチェーン - GCC 10.0 にしたら] ...」
    (更新:03/06 17:07)
link もっとみる

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 3/11 15:06