CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する

Tweetは是非 #CEDEC2018
スライドはセッション後すぐ公開します

河合宜文 / Kawai Yoshifumi / @neuecc
New World, Inc.
C#
Unity

C#最速シリアライザ
https://github.com/neuecc/MessagePack-CSharp/

Reactive Extensions for Unity
https://github.com/neuecc/UniRx/
async/await(UniTask)
async UniTask<string> DemoAsync()
{
// You can await Unity's AsyncObject
var asset = await Resources.LoadAsync<TextAsset>("foo");
// .ConfigureAwait accepts progress callback
await SceneManager.LoadSceneAsync("scene2").ConfigureAwai
// await frame-based operation(you can also await frame c
await UniTask.Delay(TimeSpan.FromSeconds(3));
// like 'yield return WaitForEndOfFrame', or Rx's Observe
await UniTask.Yield(PlayerLoopTiming.PostLateUpdate);
// You can await standard task
await Task.Run(() => 100);
// get async webrequest
async UniTask<string> GetTextAsync(UnityWebRequest req)
{
var op = await req.SendWebRequest();
return op.downloadHandler.text;
}
var task1 = GetTextAsync(UnityWebRequest.Get("http://goog
var task2 = GetTextAsync(UnityWebRequest.Get("http://bing
var task3 = GetTextAsync(UnityWebRequest.Get("http://yaho
// concurrent async-wait and get result easily by tuple s
var (google, bing, yahoo) = await UniTask.WhenAll(task1,
// You can handle timeout easily
await GetTextAsync(UnityWebRequest.Get("http://unity.com"

サーバーも
クライアントも
全部C#で統一する

サーバーサイドエンジニアでC#で書ける人間がい
なくて覚えなおし基盤システムがもう構築されて
るコードが流用できないそもそもWindowsだしい
やMicrosoftがいや余計にお金がかかりそうプロプ
ライエタリじゃないのGoのほうがなうい別にPHP
で困ってないC++のほうがパフォーマンスいいん
じゃないのノウハウがないインターネットに情報
がないオープンじゃない気がするMacで動かない
んじゃないの事例もあんまないし失敗しそうetc...

やっぱ遅かった。
当時(15年前)パフォーマンスを志向してこなかった

Performance by Default
というUnityの標語
ECS + Job System + Burst Compilerで、C#をC++よりも高速に
性能の向上は不可能を可能にする！
C# 7.x + .NET Core 2.1
Linuxで動く.NET実装(登場からかなり時間も経ち十分現実的です)
OSS化により細かい性能向上PRを受け入れ、
人海戦術でボトルネックが潰されていっている
言語やランタイムにも手を入れ大きな性能向上を果たしている

リアルな性能は基盤だけでは決まらない
ウェブフレームワークやデータベースアクセス、シリアライゼー
ション、etc...
（そもそも言語自体の評価が、言語だけではなくライブラリやエコ
システムなども含めて評価すべき）
現実的にはまだC#はよくなってきたとはいえ、手薄
そこがパフォーマンスを当初からしっかり意識して鍛え上げられて
きた言語と、最近やっと目覚めたゆとりC#との違い
だからこそ、やらなければならない

C#最速JSONシリアライザ
https://github.com/neuecc/Utf8Json

C#も誕生15年、一見枯れてるように見える、が
別にそんなことはなかった
C#で真の意味でのパフォーマンスが意識されだしたのは近年
言語のポテンシャルを100%活かしたライブラリを開発することに
よって、C#のパフォーマンスを下支えする
そして性能のベースラインを掲示したことにより、世界中でシリア
ライザに限らずC#のパフォーマンスへの意識を変えた
常に前線で競える言語となるために
誰かがやってくれるのではなく誰もが当事者
それがオープンであるということだし、C#もそういう世界にいる

Introduction to the
High Performance C#

NOTICE
この先の内容はあくまでエクストリーム
なパフォーマンスを求めたい場合のため
であり普通に書く場合これらに気をつけ
る必要は別に特に全くあまりないことも
多いことは前提としてください

徹頭徹尾、遅くなる要因を取り除く
極限的な領域だとプロファイラは役に立たない
（ぶっちゃけ見ても特に何もネックになっていない）
理論的に最速になるコードのイメージを描いて、
全ての言語知識を駆使して通過するコードパスから無駄を省き、
それに近づける
狂気に彩られた執念で全てを潰す
特別なことはないし一つ一つはとにかく地味
それを死ぬほど徹底する、それが唯一最大の秘訣で、難しいこと

例えばint(999)をbyte[]にシリアライズ
var bytes = BitConverter.GetBytes(999);
unsafe
{
var bytes = new byte[4];
fixed (byte* ptr = bytes)
{
*((int*)ptr) = 999;
}
}

// ふつーのシリアライザのAPIの例
byte[] Serialize<T>(T obj)
{
// 1. 内部での書き込みストリーム作りのためにnew MemoryStream
using(var stream = new MemoryStream())
// 2. データ生成時の内部ステートを保持するためのWriterのnew
var writer = new XxxWriter(stream);
// 3. Int用子シリアライザの取得あるいはprimitiveの場合はswitch
var serializer = serializerCacheDictionary[typeof(T)];
// 4. (意外と内部では入ってることがある)objectへのボクシング
serializer.WriteObject(writer, (object)obj);
// 5. 可変長整数へのエンコード
if(x <10) write... else if(x < 150) write...
// 6. WriteByte呼び出しの連打（内部では幾つかのifやインクリメント）
stream.WriteByte(byte >> 0); stream.WriteByte(byte >> 8) ...
// 7. MemoryStreamのToArrayはbyte[]コピー
memoryStream.ToArray();
}

// ふつーのシリアライザのAPIの例
byte[] Serialize<T>(T obj)
{
// 1. 内部での書き込みストリーム作りのためにnew MemoryStream
using(var stream = new MemoryStream())
// 2. データ生成時の内部ステートを保持するためのWriterのnew
var writer = new XxxWriter(stream);
// 3. Int用子シリアライザの取得あるいはprimitiveの場合はswitch
var serializer = serializerCacheDictionary[typeof(T)];
// 4. (意外と内部では入ってることがある)objectへのボクシング
serializer.WriteObject(writer, (object)obj);
// 5. 可変長整数へのエンコード
if(x <10) write... else if(x < 150) write...
// 6. WriteByte呼び出しの連打（内部では幾つかのifやインクリメント）
stream.WriteByte(byte >> 0); stream.WriteByte(byte >> 8) ...
// 7. MemoryStreamのToArrayはbyte[]コピー
memoryStream.ToArray();
}
そりゃ遅い！
けれどそれは言われてみれば……
というのも事実
そして逆に言えば
これを全部避ければ速いはず！

// こんなクラスがあるとして
public class Sample
{
public int Id { get; set; }
public string Name { get; set; }
public string[] Addresses { get; set; }
}
// Object作って
Sample obj = new Sample
{
Id = 10,
Name = "Foo",
Addresses = new[] { "Foo", "Bar", "Baz" }
};
// こんな感じにbyte[]に変換するというAPI
byte[] bin = MessagePackSerializer.Serialize<Sample>(obj);

// これを詳細にバラすと
byte[] bin = MessagePackSerializer.Serialize<Sample>(obj);
// Sampleの子シリアライザを取得し
var sampleFormatter = StandardResolver.Instance.GetFormatter<Sample>();
// resultの参照
byte[] bin = null;
// こんな風になっている(refによってbinに結果が詰まってくる)
sampleFormatter.Serialize(ref bin, 0, obj, StandardResolver.Instance);

sampleFormatter.Serialize(ref bin, 0, obj, StandardResolver.Instance);
// 子シリアライザ取得のための入れ物（後述）
IFormatterResolver resolver = StandardResolver.Instance;
// メモリプールから作業用byte[]を取得
var bin = BufferPool.ThreadStaticBuffer;
// byte[]上の0位置から書き込み開始
var offset = 0;
// オブジェクトの線形化 -> 配列上にならべる[Id, Name, Addresses]
offset += MessagePackBinary.WriteArrayHeader(ref bin, offset, 3);
// intのプリミティブバイナリ化
offset += MessagePackBinary.WriteInt32(ref bin, offset, obj.Id);
// stringのプリミティブバイナリ化
offset += MessagePackBinary.WriteString(ref bin, offset, obj.Name);
// string[]の子シリアライザを取得
var addressessFormatter = resolver.GetFormatter<string[]>();
offset += addressessFormatter.Serialize(ref bin, offset, obj.Addresses, resolver);
// 新規にbyte[]を作り作業用byte[]からコピー
var finalBytes = new byte[offset];
Buffer.BlockCopy(bin, 0, finalBytes, 0, offset);
return finalBytes;

取得にDictionaryはコストゼロのように使いがち
MessagePack for C#では以下のように型毎のシリアライザを取得
普通の作り方（？）だとこれを辞書から取ってくる
Dictionary(ハッシュテーブル)はO(1)
つまりタダじゃん、やったー！ではない
O(1)でも内部的な処理量はそこそこあり、それなりに遅い
（もっといえば汎用的に使えるようになっているため、その汎用化
部分がコードのパフォーマンスを若干落としてる、詳細は後述）
IMessagePackFormatter<string[]> f = resolver.GetFormatter<string[]>();
IMessagePackFormatter<string[]> f = dict[typeof(string[])];

public class SampleResolver : IFormatterResolver
{
public static readonly IFormatterResolver Instance = new SampleResolver();
SampleResolver() { }
public IMessagePackFormatter<T> GetFormatter<T>()
{
// Dictionaryのlookupのかわりに<T>.fieldから取ってくる
// 処理効率はJITコンパイラに委ねられ、C#のレイヤーでどうこうするより圧倒的に速い
return Cache<T>.formatter;
}
static class Cache<T>
{
public static readonly IMessagePackFormatter<T> formatter;
// 静的コンストラクタはスレッドセーフで必ず一度しか呼ばれないことが言語的に保証されている
static Cache()
{
var t = typeof(T);
if (t == typeof(int)) formatter = new Int32Formatter();
else if (t == typeof(string)) formatter = new NullableStringFormatter();
else ....
}
}
}

ジェネリック型はIL2CPPでコードサイズが膨らむ
{
// この中身のコードはTが値型の場合、同じものが吐かれる(参照型ならば共有される)
// 値型はPrimitiveだけじゃなくEnumなども含まれるため、場合によっては凄い量になる……
static Cache()
{
// もしこの中身が凄い多い場合かなりのことになる
// 実際UnityのIL2CPPでDictionary<TKey, TValue>はバイナリサイズが膨らむ要因の一つ！
var t = typeof(T);
if (t == typeof(int)) formatter = new Int32Formatter();
else if (t == typeof(string)) formatter = new NullableStringFormatter();
else ....
}
}

{
static Cache()
{
var f = CacheHelper.CreateFormatter(typeof(T));
if (f != null)
{
formatter = (IMessagePackFormatter<T>)f;
}
}
}
static class CacheHelper
{
public static object CreateFormatter(Type t)
{
if (t == typeof(int)) return new Int32Formatter();
else if (t == typeof(string)) return new NullableStringFormatter();
else ....
return null;
}

標準のDictionaryは決して最速ではない
GetHashCode, Equalsの呼び出しがIEqualityComparer<T>経由とい
うオーバーヘッドがかなり大きい
直接呼び出しと、仮想メソッド呼び出しの性能差は確実にある
辞書が必要なら型を決め打って直接呼び出しにした
自家製のほうが性能面では明らかに良好
キーが非ジェネリックな辞書(Dictionary<Type, ...>)や
文字列(Dictionary<string, ...>
バイト配列(Dictionary<byte[], ...>)相当のものはよく作り使う

標準のDictionaryは決して最速ではない
GetHashCode, Equalsの呼び出しがIEqualityComparer<T>経由と
いうオーバーヘッドがかなり大きい
直接呼び出しと、仮想メソッド呼び出しの性能差は確実にある
辞書が必要なら型を決め打って直接呼び出しにした
自家製のほうが性能面では明らかに良好
キーが非ジェネリックな辞書(Dictionary<Type, ...>)や
文字列(Dictionary<string, ...>
バイト配列(Dictionary<byte[], ...>)相当のものはよく作り使う

byte[](ArraySegment<byte>) のKeyの辞書を作る
KeyからValueを引くためだけにStringにデコードするのは高コスト
もし入力がbyte[]なら、デコードせずそのまま参照すればいい

byte[](ArraySegment<byte>) のKeyの辞書を作る
KeyからValueを引くためだけにStringにデコードするのは高コスト
もし入力がbyte[]なら、デコードせずそのまま参照すればいい
ハッシュ値算出のアルゴリズムを工夫する
byte[]からハッシュ値を作るアルゴリズムは色々ある
MessagePack for C#ではFarmHashを採用
小さめのサイズの文字列に適しているため用途にマッチしていた
一般的にはxxHashが万能に最強説がある
LZ4やZStandard作者によるもの

プロパティ名のマッチングを最適化したい
MessagePackのMapモード(JSONの{}とほぼ同じ)やUtf8Jsonで
デシリアライズ時に、キーをどの値としてデコードすべきか
名前のマッチングが必要
一々デコードしてのStringがキーの辞書は論外
byte[]がキーの辞書も良いけれど、この場合更に上の技法がある

文字列は重い
Dictionaryの仕組みとして取得時にGetHashCode -> Equalsが走る
C#の文字列の中身はUTF16で、つまりbyte[]的なもの
GetHashCodeで全探索して算出、Equalsで全数比較
文字列が長ければ長いほどインパクトがあることは頭に留めたい
例えばint IDに変換して代替できるなら、そのほうがずっと良い
Enumは重い
Enumは実態は数値型で生で扱う場合は超軽量ですが
それ以外は重めの処理が入りがちなので注意
特にUnityではDictionaryのKeyに使うとボクシングが発生……

文字列は重い
Dictionaryの仕組みとして取得時にGetHashCode -> Equalsが走る
C#の文字列の中身はUTF16で、つまりbyte[]的なもの
GetHashCodeで全探索して算出、Equalsで全数比較
文字列が長ければ長いほどインパクトがあることは頭に留めたい
例えばint IDに変換して代替できるなら、そのほうがずっと良い
Enumは重い
Enumは実態は数値型で生で扱う場合は超軽量ですが
それ以外は重めの処理が入りがちなので注意
特にUnityではDictionaryのKeyに使うと都度ボクシングが発生……

ILは大事だが全てではない
最初に意識すべきことは、C#はコンパイルされると、
どのようなILに変化するか
しかし速度的な真の終着点は、どのようなASMで実行されるか
CLRの場合はJITコンパイラ、Unityの場合はIL2CPPの結果が大事
ほとんどの場合は素直な結果になりますが、
時々最適化が走ってILとは異なる結果になる場合もある
（EqualityComparer.Defaultのdevirtualizationなどもそう)

インライン化はかなり効くのでうまく使いたい

C#は油断するとすぐに「何か」を生成する
C#の便利機能のほとんどが暗黙的な(クラス)生成で成り立っている
C#erはGeneration 0のGCは無料だとマントラを唱えていた
しかしそれは幻想であり、現実無料ではない
更に言えば現状のUnityは世代別GCではないのでより高コスト
高速化の基本原則はアロケーションを最小限にすること
よし、便利機能は避けよう
しかし便利機能と思っていなくても分かりにくい罠も存在する

メソッドの直接渡しは暗黙的デリゲート生成
public class Foo
{
public void Bar()
{
// これは
ThreadPool.QueueUserWorkItem(RunInThreadPool);
// これに等しい
ThreadPool.QueueUserWorkItem(new WaitCallback(RunInThreadPool));
}
void RunInThreadPool(object _)
{
Console.WriteLine("foo");
}
}

可能ならフィールドにキャッシュで回避する
public class Foo
{
// もしstaticだったり、インスタンスメソッドでも何度も使うようなものなら
// フィールドにキャッシュしてあげるのが良い（ラムダ式の非クロージャの場合はそれを自動で行ってくれる）
static readonly WaitCallback CallBack = RunInThreadPool;
public void Bar()
{
ThreadPool.QueueUserWorkItem(CallBack);
}
static void RunInThreadPool(object _)
{
Console.WriteLine("foo");
}
}

Action<object>の使い方
public int X;
public void Bar()
{
// 「インスタンス変数」などを使いたい場合staticなキャッシュは使えない
// しかし勿論これではデリゲートを生成してしまっている
ThreadPool.QueueUserWorkItem(_ => Nanikasuru());
}
void Nanikasuru()
{
Console.WriteLine("Nanika Suru:" + X);
}

static readonly WaitCallback CallBack = RunInThreadPool;
public int X;
public void Bar()
{
// Action<object>のstateはそのためにある、thisを入れるのが頻出パターン。
// これはキャッシュされたデリゲートを使うためゼロアロケーション
ThreadPool.QueueUserWorkItem(CallBack, this);
}
static void RunInThreadPool(object state)
{
// stateからthisを引っ張ることでインスタンスメソッドを呼び出せる
var self = (Foo)state;
self.Nanikasuru();
}
void Nanikasuru()
{
Console.WriteLine("Nanika Suru:" + X);
}

ラムダ式のキャプチャ
static void Run(List<int> list, string format)
{
// ラムダ式のキャプチャ（外側の変数を中で使うこと）は暗黙的なクラス生成が入る
// 以下のようなコードが生成されるので、クラスとデリゲートの二つがアロケート対象。
// var capture = new { format };
// new Action<int>(capture.Run);
list.ForEach(x =>
{
Console.WriteLine(string.Format(format, x));
});
}

static void Run(List<int> list, string format, bool cond)
{
// does not use lambda, but...
if (cond)
{
Console.WriteLine("Do Nothing");
return;
}
// use capture path
list.ForEach(x =>
{
});
}

static void Run(List<int> list, string format, bool cond)
{
if (cond)
{
Console.WriteLine("Do Nothing");
return;
}
// キャプチャが存在するメソッドを分けることで回避
RunCore(list, format);
}
static void RunCore(List<int> list, string format)
{
list.ForEach(x =>
{
});
}

文字列の連結はString.Concatに化ける
ループなど複数回連結が発生するならStringBuilder
全て+で繋ぎきれるなら+で繋げてしまうのが良い
static void Foo(string a, string b, string c, string d)
{
// 以下の形に変換される
// var z = string.Concat(a, b, c, d);
var z = a + b + c + d;
}

static void Foo(string a, int b, string c)
{
var z = a + b + c;
}

static void Foo(string a, int b, string c)
{
var z = a + b.ToString() + c;
}

Chapter6:
MetaProgramming Hack

C#の言語的なポテンシャルは高い
フレームワークやライブラリも揃いつつあり、
確かなパフォーマンスを示せている
CPU拡張命令を利用した高速化への対応も
UnityはBurst Compiler
.NET CoreではSystem.Runtime.Intrinsicsなどで対応しつつある
C#の言語的なポテンシャルは高い
Linuxでの安定動作も含めて、いよいよ道具が揃いつつあり
真のC#元年の幕開けといっても過言ではない

OSSライブラリの開発と公開
C#を最前線で戦える言語にしていくため武器を磨く
最高のパフォーマンスで基盤を固め、余力を作り出す
現実世界で実証する
技術とプロダクトは両輪、何事も実証とともにあるべき
C#のへの投資が優れた結果を生み出せることを証明していく
緩やかな連合の形成
C#には情報がない、ではなく軸にして公開して協力していく
向かうべき視線は世界！と、堂々と行きましょう

CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する

Recommended

More Related Content

What's hot (20)

Similar to CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する (20)

More from Yoshifumi Kawai (20)

Recently uploaded (8)

CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する