Movatterモバイル変換

C# 7.2with .NET Core 2.1岩永信之

今日の話• .NET Core 2.xでのパフォーマンス改善の話• C# 7.x• .NET Core 2.xのパフォーマンス改善の流れに同調• 去年リリースされたけど、.NET Core 2.1が出てからが本番

.NET Core 2.1• https://blogs.msdn.microsoft.com/dotnet/2018/02/27/announcing-net-core-2-1-preview-1/• Global Tools• Build Performance Improvements• Minor-Version Roll-forward• Sockets Performance and HTTP Managed Handler• Span<T>, Memory<T> and friends ←今日の話これ• Windows Compatibility Pack

C# 7.2• http://ufcpp.net/study/csharp/cheatsheet/ap_ver7_2/• 数字区切り• 非末尾名前付き引数• private protected• ref readonly/ref拡張メソッド/ref演算子• ref構造体/Span<T>対応 ←今日の話これ

前振り:C#/.NETのパフォーマンス

ベンチマーク• 英語で「language benchmark」とかでググると…• こんな感じのサイトが

ベンチマーク(注意点)• 英語で「language benchmark」とかでググると…• https://benchmarksgame.alioth.debian.org/• 注意点• 言語をまたいだベンチマークは、言語の差だけじゃなくて「どのくらい本気の人が参加してるか」による• 実際、C#はちょっと前までいまいちなコードでだいぶ遅かった• レギュレーション難しい• C++は環境依存な関数を容赦なく使ってたりすることが

ベンチマーク(現状)おおむねC, C++ > Rust > Java, Swift, C#, Go > 関数型言語 >>> スクリプト言語横並び

ベンチマーク(現状からいえること)C#は….NET Core 2.0でちょっと速くなった• C, C++基準で2～3倍遅い• ここを縮めたいという要望は昔から多い• 特定CPU向け最適化• GC対策• スクリプト言語基準で3～5倍速い• にもかかわらず「Node.jsと比べてそんなに速くない」と思われてる• 文字列処理の速度が大差ない• 言語的な差よりも、内部のHTTP処理とかの方がネックになったりする

要するに、こんな要望になる特定CPU向け最適化Web高速化GC削減UTF-8Hardware Intrinsics参照と構造体活用Span<T>バイナリ処理C# 7.0, 7.1.NET Core 2.1以降.NET Core 2.1

ということで今日のテーマ• Span<T> (.NET Core 2.1)• Hardware Intrinsics (.NET Core 2.1より後)• おまけ: .NET Core 2.0での細かい最適化

• Span<T> (.NET Core 2.1)• Hardware Intrinsics (.NET Core 2.1より後)• おまけ: .NET Core 2.0での細かい最適化軽い方から先に

例えばこんなリファクタリング(1)• uint比較• 効果• 比較が1回減る• 1命令と言えど、ループで頻繁に呼ばれる処理なので塵も積もるif ((uint)x < length)元後if (0 < x && x < length)

例えばこんなリファクタリング(2)• Common Path Optimization (よく通る場所だけ優先最適化)• 効果• よく通る場所だけはインライン化が効いて速くなる• (長かったり、throw文があるとインライン化されない)if (9割方true)短い処理else長い処理をメソッド抽出();if (9割方true)短い処理else長い処理元後

Q & A (1)• Q. 「この手の細かい改善で5%くらい速くなります」といわれて、やる？• A. 5%でもやりたい人という人は「世の中にはいる」• こういうものは、限られた人数では最適化されづらい• コミュニティ貢献が多いらしい• ほんと細かい積み重ねはオープンソース強い

Q & A (2)• Q. いまさら？• A 1. .NET Frameworkからの移行で手一杯だったから…• A 2. ほんと、いまさら• 前述のとおり、こういうのはコミュニティ貢献が結構大きい• 「いまさら」というなら、オープン化のタイミングが…• 方針転換• 最適化はコンパイラーの仕事ではないか → ホットパスは手作業してでも高速化

• Span<T> (.NET Core 2.1)• Hardware Intrinsics (.NET Core 2.1より後)• おまけ: .NET Core 2.0での細かい最適化2.1から外れちゃったんで…おまけ程度に

C# 対 C言語• 遅いのはガベージコレクション(GC)？• → No• スタックの方が速いけどC#でもスタックを主体にしたコードは書ける• そのための機能も年々増えてる(C# 7の構造体活用)• 根本的に(Cでも)ヒープが必要なら、むしろGCは無茶苦茶速い• じゃあ、あと、何が遅いのか？• → 特定CPU向け最適化(CPU専用命令)• 一番犠牲にしてるのはポータビリティ• 要するに、速くしたければ#ifdefだらけ

CPU専用命令の例• 例: SIMD• single instruction multiple data• Vector命令とか言われたり• 例えばSSE(Pentium IIIの頃に導入された原始的なやつ)ですら• 128ビットレジスターを持ってて• float×4の四則演算を1命令でできる• 単純に考えて個別に4回計算する場合の4倍速い• オーバーヘッドの分を差し引いても倍は速い単一命令で複数データを一気に処理

Hardware Instrinsics• 専用命令の使い方• 普通のコードを書いて、コンパイラーの最適化に任せる？• 案外、その手のコードを生成してくれない• コンパイラーが特殊な関数を用意• 「この関数呼び出しは、この命令に置き換える」みたいなコンパイルを行う#include <immintrin.h>__m128 c = _mm_mul_ps(a, b)コンパイラーによって提供されるライブラリCPU専用命令に置き換わる

Hardware Instrinsics• 専用命令の使い方• 普通のコードを書いて、コンパイラーの最適化に任せる？• 案外、その手のコードを生成してくれない• コンパイラーが特殊な関数を用意• 「この関数呼び出しは、この命令に置き換える」みたいなコンパイルを行う#include <immintrin.h>__m128 c = _mm_mul_ps(a, b)こういう関数のことをintrinsicsという• Intrinsic: 内在的な• Hardware Intrinsics: 特定のCPUが内在的に持っている機能

C#でHardware Intrinsics (1)• パッケージ参照• .NET Core 2.1 preview 1までは、標準に組み込まれる予定だった• 2.1リリースには間に合わず、現状は• パッケージ参照が必要• 2.1リリース時点では「プレビュー」なパッケージになる予定

C#でHardware Intrinsics (2)• コードの書き方using System.Runtime.Intrinsics;using System.Runtime.Intrinsics.X86;result = Sse.Multiply(Sse.Shuffle(a, a, 0x00), Sse.LoadVector128(presult = Sse.Add(result, Sse.Multiply(Sse.Shuffle(a, a, 0x55), Sseresult = Sse.Add(result, Sse.Multiply(Sse.Shuffle(a, a, 0xaa), Sseresult = Sse.Add(result, Sse.Multiply(Sse.Shuffle(a, a, 0xff), Sse・・・命令セットの名前のクラス命令に対応するメソッド

もちろんCPU依存…• 当然、C言語だと#ifだらけになる• C#でもifだらけになるif (Sse.IsSupported){return SseAdd(a, b);}else{return Add(a, b);}この命令セットを使える環境の時だけtrueJIT時定数(falseの側は最適化で完全に消える)使える場合と使えない場合の2つの実装が必要かなり速くできるけど、「ifだらけ」「2重実装」の覚悟が必要

デモ• 行列の積和でベンチマーク• SIMD命令を使うか使わないかでどのくらい速度差が出るか• https://github.com/ufcpp/UfcppSample/tree/master/Demo/2018/SpanPerformance/MatrixBenchmark

• Span<T> (.NET Core 2.1)• Hardware Intrinsics (.NET Core 2.1より後)• おまけ: .NET Core 2.0での細かい最適化本題。というか今日の話題で2.1の話題なのはこれだけに

C#対スクリプト言語• ベンチマーク上は3~5倍は速いはずなのに• Webサーバーとして使うとなんかそこまで差がつかない？• 3~5倍速いのは主に数値計算とか• 文字列処理の速度が大差ない• 言語的な差よりも、内部のHTTP処理(C#やスクリプト言語ではなく、ネイティブで書かれてる)とかの方がネックになったりする• WebがUTF-8で、C#のstringがUTF-16なのが問題に

Webでの文字列処理の例• 例えばこんな感じのHTTP GETをしたとして• (アップローダーからJSONをダウンロード)• idとnameの値だけを取り出そうとしたとき… ちなみに、こういうJSON

文字列処理の現状• Stream + stringでの処理… 7B 0D 0A 20 20 22 69 64 22 3A 20 31 2C 0D 0A 20 20 22 6E 61 6D 65 22 3A 20 22 F0 9F 91 A6 F0 9F 8F BD 22 0D 0A 7D …7B 0D 0A 20 20 22 69 64 22 3A 20 31 2C 0D 0A 20 20 22 6E 61 6D 65 22 3A 20 22 F0 9F 91 A6 F0 9F 8F BD 22 0D 0A 7DStream.Read(byte[] buffer, int offset, int count)Encoding.GetString(byte[] bytes)… 22 00 69 00 64 00 22 00 3A 00 20 00 31 00 2C 00 0D 00 0A 00 20 00 20 00 22 00 6E 00 61 00 6D 00 65 00 22 00 3A 00 20 00 …string.Substring string.Substring31 00122 00 3D D8 66 DC 3C D8 FD DF 22 00"👦🏽"UTF-8UTF-16

文字列処理をどうしたいか(1)• Nativeヒープを直接参照… 7B 0D 0A 20 20 22 69 64 22 3A 20 31 2C 0D 0A 20 20 22 6E 61 6D 65 22 3A 20 22 F0 9F 91 A6 F0 9F 8F BD 22 0D 0A 7D …IPipeReader.TryRead(out ReadResult result)OwnedBuffer参照管理のための小さいクラス

文字列処理をどうしたいか(2)• UTF-8のままで処理… 7B 0D 0A 20 20 22 69 64 22 3A 20 31 2C 0D 0A 20 20 22 6E 61 6D 65 22 3A 20 22 F0 9F 91 A6 F0 9F 8F BD 22 0D 0A 7D …OwnedBuffer Utf8Stringnew Utf8String(buffer.Span)

文字列処理をどうしたいか(3)• 部分参照でコピーを作らない… 7B 0D 0A 20 20 22 69 64 22 3A 20 31 2C 0D 0A 20 20 22 6E 61 6D 65 22 3A 20 22 F0 9F 91 A6 F0 9F 8F BD 22 0D 0A 7D …OwnedBuffer Utf8Stringnew Utf8String(buffer.Span)SubstringUtf8StringUtf8String1 "👦🏽"スタックしか使わないSubstringもコピーを作らない直接intにParseすればヒープ不要ToString時に初めてヒープ確保

何が必要か• メモリの一部分を参照• Nativeヒープを直接• stringの一部分• 参照を前提にしたI/O• UTF-8を直接読み書きSpan<T>型PipelinesUtf8String.NET Core 2.1その後依存関係C# 7.0~7.2• ref戻り値• ref安全ルールSpan<T>型PipelinesUtf8String今ここ

Span<T>: 「範囲」を参照• 論理的には、参照+長さ… 7B 0D 0A 20 20 22 69 64 22 3A 20 31 2C 0D 0A 20 20 22 6E 61 6D 65 22 3A 20 22 F0 9F 91 A6 F0 9F 8F BD 22 0D 0A 7D …1struct Span<T>{ref T Pointer;int Length;}どこから何要素例ここから1バイトここから10バイト" "

Span<T>: いろんなところ参照• Managedヒープも、Nativeヒープも、スタックも参照できるSpan<byte> span = new byte[N];Span<byte> span = stackalloc byte[N];var p = Marshal.AllocHGlobal(N);Span<byte> span = new Span<byte>((byte*)p, N);普通の配列 = Managedヒープstackalloc = スタックP/Invokeやunsafe = Nativeヒープ同じ型で参照できる= 同じロジックで扱える

C# 7.2: Span安全ルール• スタック(ローカル変数)の参照を外に返してはいけないref int Ok(ref int x){return ref x;}ref int Ng(){int x;return ref x;}Span<int> Ok(Span<int> x){return x;}Span<int> Ng(){Span<int> x = stackalloc int[1];return x;}ref安全ルール(C# 7.0) Span<T>※安全ルール(C# 7.2)ローカル変数(メソッドを抜けると消える)消えるものの参照(返そうとするとエラー)※ 正確にはSpan<T>専用ではなくて、ref構造体に対して掛かる制限

C# 7.2: 安全なstackalloc• 例: 頻出数字の検索static int MostFrequentDigit(string s){var digits = new int[10];foreach (var c in s){var d = c - '0';if ((uint)d < 10) ++digits[d];}var max = 0;for (int i = 1; i < 10; i++)if (digits[max] < digits[i]) max = i;return max;}0~9の文字の頻度をカウントするための一時バッファー配列のせいでヒープ確保(あんまり好ましくない)

C# 7.2: 安全なstackalloc• 例: 頻出数字の検索static int MostFrequentDigit(string s){Span<int> digits = stackalloc int[10];foreach (var c in s){var d = c - '0';if ((uint)d < 10) ++digits[d];}var max = 0;for (int i = 1; i < 10; i++)if (digits[max] < digits[i]) max = i;return max;}一時バッファーをnewからstackallocに変更ヒープ確保がなくなる(速い)unsafe不要実際、安全• 範囲チェックあり• 外に返せないルールあり

デモ• Substring• ヒープ確保をなくせば無条件に速くなるというものでもない• GCはほんとに速い• Span<T>があるとだいぶ速い• https://github.com/ufcpp/UfcppSample/tree/master/Demo/2018/SpanPerformance/SubstringBenchmark

デモ• Split → Join• string.Splitやstring.Joinは一時的なオブジェクトを確保しまくる• Span<T>でヒープ確保なくSplit, Join• (ただし、使い勝手はあまり良くない)• https://github.com/ufcpp/UfcppSample/tree/master/Demo/2018/SpanPerformance/StringManipulation

まとめ• 2.0~2.1、細かい最適化だらけ• 2.0で実際あったのをちょっと紹介• Hardware Intrinsics• 2.1から外れちゃったけど• 2.1時点で、プレビュー公開• Span/UTF-8• GC速いけど、「ヒープなし」にはさすがに敵わない• そのためのref、Span<T>• C# 7.2で関連機能すでに入ってる/.NET Core 2.1からが本番

Movatterモバイル変換

Change Language

C# 7.2 with .NET Core 2.1

Embed presentation

Recommended

More Related Content

What's hot

Similar to C# 7.2 with .NET Core 2.1

More from 信之岩永

C# 7.2 with .NET Core 2.1

Editor's Notes

Movatterモバイル変換

C# 7.2 with .NET Core 2.1

Recommended

More Related Content

What's hot

Similar to C# 7.2 with .NET Core 2.1

More from 信之 岩永

C# 7.2 with .NET Core 2.1

Editor's Notes

More from 信之岩永