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"

using C

in 10 years

C#大統一理論 #とは

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

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

Realtime Unity API Service

Performance of C#

速い？遅い？

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

Motivation

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;

Chapter1: Dictionary Hack

取得に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でコードサイズが膨らむ static class Cache<T> { public static readonly IMessagePackFormatter<T> formatter;
// この中身のコードは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 class Cache<T> { public static readonly IMessagePackFormatter<T> formatter; 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[], ...>)相当のものはよく作り使う

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に使うと都度ボクシングが発生……

Chapter2: JIT Hack

C# IL C++ JIT ASM

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

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

Chapter3: IL Hack

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 => { Console.WriteLine(string.Format(format, 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 => { Console.WriteLine(string.Format(format, 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; }

Chapter4: Binary Hack

Chapter5: async/await Hack

Chapter6: MetaProgramming Hack

Conclusion

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

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

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

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

More Decks by Yoshifumi Kawai

Featured

Transcript