link もっと前
   2019年 12月 17日 -
      2019年 12月 8日  
link もっと後

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

link permalink

link 編集する

memset のベンチマーク(AArch64, Cortex-A72 編)

(参考)コード一式は GitHub に置きました(GitHub へのリンク

先日 Ryzen 7 2700 な x86_64 マシンで memset の性能を計測(2019年 12月 14日の日記参照)しました。同様の計測を AArch64 でもやってみました。環境は RK3399 Cotex-A72 1.8GHz です。メモリはおそらく LPDDR3-1600 のはず、OS は Debian GNU/Linux 10.2 buster です。

リファレンスとするのは前回同様、システムにインストールされている glibc-2.28 の memset 関数(アセンブラ版)です。大抵の場合、この関数が最速ですね。

ざっと glibc-2.28 の実装を見たところ、x86_64 向けは各種 SIMD 向けに最適化されたアセンブラコード(glibc/sysdeps/x86_64/multiarch/memset-avx2-unaligned-erms.S など)が使われて、aarch64 向けは汎用的なアセンブラコード(glibc/sysdeps/aarch64/memset.S)が使われるようです。

まずは最適化オプション O3 と O2 の差から見てみようと思います。


gcc -O3 -fno-builtin の測定結果(Cortex-A72 編)


gcc -O2 -fno-builtin の測定結果(Cortex-A72 編)

やはり O3 の最適化による速度向上はさすがとしか言えません。x86_64 ではあまり振るわなかった musl memset 関数が非常に優秀で、libc の memset に並ぶ勢いです。

AArch64 の NEON を使ったベクトル最適化

前回はベクトル最適化 -ftree-vectorize オプションを使うとほぼ O3 の性能に追い付きましたが、AArch64 ではどうなるでしょう?


gcc -O2 -ftree-vectorize -fno-builtin の測定結果(Cortex-A72 編)

ベクトル最適化を有効にすると NEON の 128bit ストア命令が使われるようになります。

O2 と比較すると確かに性能向上していますが、x86_64 ほどの威力は発揮しません。

メモ: 技術系の話は Facebook から転記しておくことにした。大幅に加筆。

[編集者: すずき]
[更新: 2020年 1月 9日 23:44]

コメント一覧

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



link permalink

link 編集する

memset のベンチマーク(x86_64, Ryzen 7 2700 編)

(参考)コード一式は GitHub に置きました(GitHub へのリンク

昨日 musl C library の memset 関数を調べていたときに「単純な実装と比較して、どれくらい速いんだろうか?」と疑問に思いました。単純な実装とは下記のような実装です。

単純な memset 実装

void *memset_simple(void *dest, int c, size_t n)
{
	unsigned char *s = dest;

	for (; n; n--, s++) *s = c;

	return dest;
}

C ライブラリは世の中にたくさん実装がありますが、glibc-2.28 と musl-1.1.24 にご登場願うことにします。各 C ライブラリの memset 実装は下記のとおりです。

GNU C library の memset 実装(C 言語版)

void *memset_glibc(void *dstpp, int c, size_t len)
{
  long int dstp = (long int) dstpp;

  if (len >= 8)
    {
      size_t xlen;
      op_t cccc;

      cccc = (unsigned char) c;
      cccc |= cccc << 8;
      cccc |= cccc << 16;
      if (OPSIZ > 4)
	/* Do the shift in two steps to avoid warning if long has 32 bits.  */
	cccc |= (cccc << 16) << 16;

      /* There are at least some bytes to set.
	 No need to test for LEN == 0 in this alignment loop.  */
      while (dstp % OPSIZ != 0)
	{
	  ((byte *) dstp)[0] = c;
	  dstp += 1;
	  len -= 1;
	}

      /* Write 8 `op_t' per iteration until less than 8 `op_t' remain.  */
      xlen = len / (OPSIZ * 8);
      while (xlen > 0)
	{
	  ((op_t *) dstp)[0] = cccc;
	  ((op_t *) dstp)[1] = cccc;
	  ((op_t *) dstp)[2] = cccc;
	  ((op_t *) dstp)[3] = cccc;
	  ((op_t *) dstp)[4] = cccc;
	  ((op_t *) dstp)[5] = cccc;
	  ((op_t *) dstp)[6] = cccc;
	  ((op_t *) dstp)[7] = cccc;
	  dstp += 8 * OPSIZ;
	  xlen -= 1;
	}
      len %= OPSIZ * 8;

      /* Write 1 `op_t' per iteration until less than OPSIZ bytes remain.  */
      xlen = len / OPSIZ;
      while (xlen > 0)
	{
	  ((op_t *) dstp)[0] = cccc;
	  dstp += OPSIZ;
	  xlen -= 1;
	}
      len %= OPSIZ;
    }

  /* Write the last few bytes.  */
  while (len > 0)
    {
      ((byte *) dstp)[0] = c;
      dstp += 1;
      len -= 1;
    }

  return dstpp;
}
musl C library の memset 実装(C 言語版)

void *memset_musl(void *dest, int c, size_t n)
{
	unsigned char *s = dest;
	size_t k;

	/* Fill head and tail with minimal branching. Each
	 * conditional ensures that all the subsequently used
	 * offsets are well-defined and in the dest region. */

	if (!n) return dest;
	s[0] = c;
	s[n-1] = c;
	if (n <= 2) return dest;
	s[1] = c;
	s[2] = c;
	s[n-2] = c;
	s[n-3] = c;
	if (n <= 6) return dest;
	s[3] = c;
	s[n-4] = c;
	if (n <= 8) return dest;

	/* Advance pointer to align it at a 4-byte boundary,
	 * and truncate n to a multiple of 4. The previous code
	 * already took care of any head/tail that get cut off
	 * by the alignment. */

	k = -(uintptr_t)s & 3;
	s += k;
	n -= k;
	n &= -4;

#ifdef __GNUC__
	typedef uint32_t __attribute__((__may_alias__)) u32;
	typedef uint64_t __attribute__((__may_alias__)) u64;

	u32 c32 = ((u32)-1)/255 * (unsigned char)c;

	/* In preparation to copy 32 bytes at a time, aligned on
	 * an 8-byte bounary, fill head/tail up to 28 bytes each.
	 * As in the initial byte-based head/tail fill, each
	 * conditional below ensures that the subsequent offsets
	 * are valid (e.g. !(n<=24) implies n>=28). */

	*(u32 *)(s+0) = c32;
	*(u32 *)(s+n-4) = c32;
	if (n <= 8) return dest;
	*(u32 *)(s+4) = c32;
	*(u32 *)(s+8) = c32;
	*(u32 *)(s+n-12) = c32;
	*(u32 *)(s+n-8) = c32;
	if (n <= 24) return dest;
	*(u32 *)(s+12) = c32;
	*(u32 *)(s+16) = c32;
	*(u32 *)(s+20) = c32;
	*(u32 *)(s+24) = c32;
	*(u32 *)(s+n-28) = c32;
	*(u32 *)(s+n-24) = c32;
	*(u32 *)(s+n-20) = c32;
	*(u32 *)(s+n-16) = c32;

	/* Align to a multiple of 8 so we can fill 64 bits at a time,
	 * and avoid writing the same bytes twice as much as is
	 * practical without introducing additional branching. */

	k = 24 + ((uintptr_t)s & 4);
	s += k;
	n -= k;

	/* If this loop is reached, 28 tail bytes have already been
	 * filled, so any remainder when n drops below 32 can be
	 * safely ignored. */

	u64 c64 = c32 | ((u64)c32 << 32);
	for (; n >= 32; n-=32, s+=32) {
		*(u64 *)(s+0) = c64;
		*(u64 *)(s+8) = c64;
		*(u64 *)(s+16) = c64;
		*(u64 *)(s+24) = c64;
	}
#else
	/* Pure C fallback with no aliasing violations. */
	for (; n; n--, s++) *s = c;
#endif

	return dest;
}

単純な実装と比較して、かなり長いですし、分岐を減らす、アラインメントを取る、一度に複数バイト(8, 16バイトなど)コピーするなど、各所に工夫が見られます。

測定条件、測定対象

動作環境は、

  • CPU: AMD Ryzen 7 2700
  • Mem: DDR4-2400 (Dual Channel), 32GB (8GB x 4)
  • OS: Debian GNU/Linux 11 (bullseye)
  • gcc: gcc (Debian 9.2.1-21) 9.2.1 20191130
  • Linux: 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 GNU/Linux

単純な memset と、glibc の memset と、musl の memset の 3つとの比較対象として、普通に memset を呼んだ場合の速度を用います。実体は glibc の SSE2 版 memset 実装(アセンブラで実装されている)が呼び出されます。この関数を使う理由は下記の通りです。

  • 領域のサイズに反比例した、綺麗なカーブを描くので、基準として見やすい
  • アセンブラ実装なので、コンパイラの最適化レベルの影響をほとんど受けず、性能が一定

測定方法ですが、1バイトの memset を 10億回、2バイトの memset を 5億回、……のように、一度に処理する領域を増やしながら、処理回数を減らします。合計でおよそ 1GB の領域を memset するようにしています。

コンパイラの最適化と公平な比較

ベンチマークに使う呼び出し側プログラムは下記のように、関数ポインタ経由で呼び出し、コンパイル時に -fno-builtin オプションをつけます。

ベンチマーク測定用のプログラム(一部)

char tmpbuf[1024 * 1024 * 1024];

struct testcase cases[] = {
	{ "libc",       memset, },
	{ "glibc avx2", __memset_avx2_unaligned, },
	{ "musl asm",   memset_musl_asm, },
	{ "glibc C",    memset_glibc, },
	{ "musl C",     memset_musl, },
	{ "simple",     memset_simple, },
	{ "size",       0, },
	{ "cnt",        0, },
	{ 0, 0, },
};

void test(char *p, size_t size, int cnt)
{
	int pos, i;

	for (pos = 0; cases[pos].func; pos++) {
		gettimeofday(&cases[pos].start.tv, NULL);
		for (i = 0; i < cnt; i++) {
			cases[pos].func(p, i, size);
		}
		gettimeofday(&cases[pos].end.tv, NULL);
	}

	cases[pos].start.n = 0;
	cases[pos].end.n = size;
	pos++;

	cases[pos].start.n = 0;
	cases[pos].end.n = cnt;
	pos++;

	print_timeval(cases);
}

理由は、

関数ポインタ経由
インライン展開を防ぐためです、インライン展開された関数は他の関数に比べて call, ret の負荷が減る分、速く見えてしまいます
-fno-builtin
コンパイラの最適化レベルを上げると、単純な memset 関数の実装をコンパイラが検知して libc の memset 呼び出しに置き換えてしまうことがあります。同じ関数を比較してもベンチマークの意味がないため、置き換えが発生しないように防いでいます。

測定結果

まずは良く使われる最適化レベル O2 で測ってみます。


gcc -O2 -fno-builtin の測定結果

アセンブラで書かれた memset と比較すると、glibc や musl の実装は遅いですが、かなり健闘していますね。一方で、単純な memset 実装はかなり性能が悪いです。

次は O3 にしましょう。ほぼ最強の最適化レベルです。


gcc -O3 -fno-builtin の測定結果

なんと単純な memset がメチャクチャ速くなり、musl の実装を超えてしまいました。最適化の威力恐るべし。

O2 と O3 は異なる最適化が働きますが、一番効いている要素はどれでしょう?O2 にベクトル最適化オプションだけ追加してみます。


gcc -O2 -ftree-vectorize -fno-builtin の測定結果

O3 の性能グラフにかなり近づきました。ベクトル最適化が大きな性能改善要素となるようです。

C ライブラリの本気を見よ

ちなみに glibc や musl は C 言語による実装の他に、各アーキテクチャのためにアセンブラによる専用の実装を持っています。x86_64 向けであれば glibc も musl も専用の実装を持っています。

このベンチマークの趣旨からは外れますが、アセンブラの実装も測ってみました。こんな感じです。


アセンブラ実装の測定結果

SSE2 の実装(標準の memset は SSE2 を使う)と AVX2 の実装はほとんど速度差がありません。musl の実装は C 言語版と比べると速い部分もありますが、glibc のマニアックな実装と比べると今一つですね……。

[編集者: すずき]
[更新: 2020年 1月 9日 23:44]

コメント一覧

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



link permalink

link 編集する

musl の memset 関数

musl C library(サイトへのリンク)の memset 関数の実装はかなり気合が入っており、特に先頭&終端データの処理が面白いです。

こんなコードです。

musl memset 関数のバッファ先頭&終端処理

if (!n) return dest;
s[0] = c;
s[n-1] = c;
if (n <= 2) return dest;
s[1] = c;
s[2] = c;
s[n-2] = c;
s[n-3] = c;
if (n <= 6) return dest;
s[3] = c;
s[n-4] = c;
if (n <= 8) return dest;

私はぱっと見では何をしてるのかさっぱりわかりませんでした。図を書いてみてやっと意味が分かりました。


処理開始前

領域のサイズ n が 1〜8 の場合、このコードだけで処理が終わります。説明の都合上、if を区切りとして、3つのかたまり(赤、緑、青)に分けました。n = 1, 2 の場合は赤だけ、n = 3, 4, 5, 6 の場合は赤+緑、n = 7, 8 の場合は赤+緑+青が実行されます。

ゴチャゴチャ説明するより、1ステップずつ、実行した結果を図示した方がわかりやすいかと思います。


s[0] = c まで


s[n - 1] = c まで、 n = 1, 2 は memset 完了


s[1] = c, s[2] = c まで


s[n - 2] = c, s[n - 3] = c まで、 n = 3, 4, 5, 6 は memset 完了


s[3] = c まで


s[n - 4] = c まで、 n = 7, 8 は memset 完了、それ以上のサイズは処理を継続

図を見るとわかるように、同じ領域に 2回以上書く場合がありますが、memset は同じ領域に 2度書いても問題ありません(書き込む値は同じなので、何度書いても結果は同じ)。

この「何度書いても良い」性質を利用して、分岐を限界まで減らす戦略のようです。

ストアより分岐を減らす方がメリットがある、とみているわけですね。イマドキの CPU に合った最適化なのでしょうね。

メモ: 技術系の話は Facebook から転記しておくことにした。大幅に追記。

[編集者: すずき]
[更新: 2019年 12月 15日 23:01]

コメント一覧

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



link もっと前
   2019年 12月 17日 -
      2019年 12月 8日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

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

最終更新: 8/11 19:13

カレンダー

<2019>
<<<12>>>
1234567
891011121314
15161718192021
22232425262728
293031----

最近のコメント 5件

  • link 20年07月10日
    すずき 「鳥のゲームは知りませんでした。色々やって...」
    (更新:08/11 18:59)
  • link 20年07月12日
    すずき 「小学生でサイトに投稿はスゴイです。そして...」
    (更新:08/11 18:59)
  • link 20年07月10日
    わしだ 「オープンブック9003時代に鳥(Pinn...」
    (更新:08/10 22:40)
  • link 20年07月12日
    わしだ 「The Tower懐かしいですね。\n話...」
    (更新:08/10 22:36)
  • link 20年08月06日
    すずき 「室内の銅配管は段々硬くなるので、床に落ち...」
    (更新:08/10 17:53)

最近の記事 3件

link もっとみる
  • link 20年07月11日
    すずき 「[STATIONflow 実績コンプリート] STATIONflo...」
    (更新:08/11 19:13)
  • link 20年07月01日
    すずき 「[STATIONflow ランク 100] STATIONflow...」
    (更新:08/11 19:13)
  • link 20年06月30日
    すずき 「[STATIONflow の駅の評価] STATIONflow の...」
    (更新:08/11 19:13)

こんてんつ

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 過去日記について

その他の情報

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