No content

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 DemoAsync() { // You can await Unity's AsyncObject var asset = await Resources.LoadAsync("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 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"

No content

using C

in 10 years

C#大統一理論 #とは

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

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

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

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Realtime Unity API Service

Performance of C#

速い？ 遅い？

速い？ 遅い？

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

No content

Motivation

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

No content

リアルな性能は基盤だけでは決まらない ウェブフレームワークやデータベースアクセス、シリアライゼー ション、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 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 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(obj);

// これを詳細にバラすと byte[] bin = MessagePackSerializer.Serialize(obj); // Sampleの子シリアライザを取得し var sampleFormatter = StandardResolver.Instance.GetFormatter(); // 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(); 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;

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(); 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 f = resolver.GetFormatter(); IMessagePackFormatter f = dict[typeof(string[])];

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

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

public class SampleResolver : IFormatterResolver { public static readonly IFormatterResolver Instance = new SampleResolver(); SampleResolver() { } public IMessagePackFormatter GetFormatter() { // Dictionaryのlookupのかわりに.fieldから取ってくる // 処理効率はJITコンパイラに委ねられ、C#のレイヤーでどうこうするより圧倒的に速い return Cache.formatter; } static class Cache { public static readonly IMessagePackFormatter 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 { public static readonly IMessagePackFormatter formatter; // この中身のコードはTが値型の場合、同じものが吐かれる(参照型ならば共有される) // 値型はPrimitiveだけじゃなくEnumなども含まれるため、場合によっては凄い量になる…… static Cache() { // もしこの中身が凄い多い場合かなりのことになる // 実際UnityのIL2CPPでDictionaryはバイナリサイズが膨らむ要因の一つ！ var t = typeof(T); if (t == typeof(int)) formatter = new Int32Formatter(); else if (t == typeof(string)) formatter = new NullableStringFormatter(); else .... } }

static class Cache { public static readonly IMessagePackFormatter formatter; static Cache() { var f = CacheHelper.CreateFormatter(typeof(T)); if (f != null) { formatter = (IMessagePackFormatter)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経由とい うオーバーヘッドがかなり大きい 直接呼び出しと、仮想メソッド呼び出しの性能差は確実にある 辞書が必要なら型を決め打って直接呼び出しにした 自家製のほうが性能面では明らかに良好 キーが非ジェネリックな辞書(Dictionary)や 文字列(Dictionary バイト配列(Dictionary)相当のものはよく作り使う

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

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

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

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

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

No content

No content

文字列は重い 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などもそう)

No content

No content

No content

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

No content

No content

No content

No content

No content

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

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

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

No content

No content

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 + 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#には情報がない、ではなく軸にして公開して協力していく 向かうべき視線は世界！と、堂々と行きましょう