Movatterモバイル変換

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

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

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

Reactive Extensions for Unityhttps://github.com/neuecc/UniRx/async/await(UniTask)async UniTask<string> DemoAsync(){// You can await Unity's AsyncObjectvar asset = await Resources.LoadAsync<TextAsset>("foo");// .ConfigureAwait accepts progress callbackawait SceneManager.LoadSceneAsync("scene2").ConfigureAwai// await frame-based operation(you can also await frame cawait UniTask.Delay(TimeSpan.FromSeconds(3));// like 'yield return WaitForEndOfFrame', or Rx's Observeawait UniTask.Yield(PlayerLoopTiming.PostLateUpdate);// You can await standard taskawait Task.Run(() => 100);// get async webrequestasync UniTask<string> GetTextAsync(UnityWebRequest req){var op = await req.SendWebRequest();return op.downloadHandler.text;}var task1 = GetTextAsync(UnityWebRequest.Get("http://googvar task2 = GetTextAsync(UnityWebRequest.Get("http://bingvar task3 = GetTextAsync(UnityWebRequest.Get("http://yaho// concurrent async-wait and get result easily by tuple svar (google, bing, yahoo) = await UniTask.WhenAll(task1,// You can handle timeout easilyawait 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.1Linuxで動く.NET実装(登場からかなり時間も経ち十分現実的です)OSS化により細かい性能向上PRを受け入れ、人海戦術でボトルネックが潰されていっている言語やランタイムにも手を入れ大きな性能向上を果たしている

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

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

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

Introduction to theHigh 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 MemoryStreamusing(var stream = new MemoryStream())// 2. データ生成時の内部ステートを保持するためのWriterのnewvar writer = new XxxWriter(stream);// 3. Int用子シリアライザの取得あるいはprimitiveの場合はswitchvar 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 MemoryStreamusing(var stream = new MemoryStream())// 2. データ生成時の内部ステートを保持するためのWriterのnewvar writer = new XxxWriter(stream);// 3. Int用子シリアライザの取得あるいはprimitiveの場合はswitchvar 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[]に変換するというAPIbyte[] 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でコードサイズが膨らむ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に使うと都度ボクシングが発生……

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 pathlist.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;}

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

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

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

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

More from Yoshifumi Kawai

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