より良いエンジニアを目指して

1日1つ。良くなる!上手くなる!

.NET Conf in Tokyo 2019 〜 .NET Core 3.0 ! , .NET5 ! これからの.NET !

今年はまだかと思っていたのですが、今年も.NET Confが!

vsuc.connpass.com

このイベントがブログを始めたきっかけがこのイベントですので、思い入れがあり、是非とも参加したいイベントでした。

What’s New in .NET Core 3.0 and Visual Studio 2019 for .NET developers Steve Carroll

DirectorのSteve Carrollによる発表。

最初の挨拶は日本語でしてくださったのですが、発表は英語です。

日本語とうって変わって流暢な(そりゃそうだ)英語で、テンポ良く熱い説明が続きます。ついていけない。

本土からいらっしゃっただけあって内容は盛り沢山。

.NETはGitHubで勢いのあるOSSプロジェクトの一つになりつつあります。

Microserviceに向けてgRPC,WorkerService,WebAPI'sといった機能が提供されています。

WorkerServiceはWindows ServiceやLinuxDaemonのように長く動き続けるプロセス。これは初耳です。

デモはBlazorとgRPC,WorkerSerivce,swaggerと新しい技術をふんだんに盛り込んだコード。

プロジェクトを右クリックメニューからAdd - Service ReferenceでgRPCを追加することができます。

C# 8.0

  • Safe(Nullable / Non-nullable Reference。より明確に意図して宣言する)
  • Modern(非同期ストリーム、indexes、ranges)
  • Productive(パターンを使ってコードの書く量を抑える)

デモのコードは

Customer? customer

とこれまでのC#では見慣れない?が末尾についたコード。

Windows Desktop

  • Deployment Flexiblity (Side-by-side。自己完結型
  • Windows10 (WinFormsと WPFXAML islands)
  • Open Source

その他、Xamarin , Blazor, ML.NET, IoT。

C# create anything。C#で何でも出来る。目指して欲しい形です。

.NET 5

.NETのスケジュールから。今年の12にLTSである.NET Core3.1が出ます。

そして2020の11月に.NET 5。そこからは6.0,7.0と発展していくことになります。

Visual Studio 2019 for .NET devs

Live Share

推してますね。

Visual Studio CodeVisual Studio 2019でLive Shareするデモ。一人でも試す方法があったんですね。

コードレビューだけでなく、ターミナルも共有できるので、リモート操作を共有する時にも使える予感。

Kind

Visual Studioの使われているコードを参照するとKIndとしてRead,Writeとアクセス方法が表示されるようになったこと。

これは地味にあると助かると思います。この変数を代入しているのはどこだよ!とか探して回ることがありますので。

.NET の今と今後に思うこと (Tokyo Ver.) / Akira Inoue (@chack411)

www.slideshare.net

.NET Foundation

Google, Insight, Microsoft, Telerik, Pivotal, Unity,AWSといったスポンサー。

GoogleやTelerik,AWSは競合だが、.NETをやっていれば、様々なプラットフォームで活躍できることを意味する。

.NET Framework

4.8が最後のメジャーバージョンとなる予定。あくまでも予定なので、4.9も出る可能性はある。

既存の.NET Frameworkベースのアプリケーションはそのまま利用可能。

新規開発の場合は.NET Coreを推奨。新しいAPIへの対応については期待できない。

Visual Studio for App Dev

AppCenterを使ってのアプリの配布とクラッシュレポートの収集が出来るようになった。

AppCenterからWinFormsやWPFのアプリを作ることが出来る。

Distributeするとメールで通知され、メールのリンクからダウンロードする。

WinFormsとWPFオープンソース化による勢い

プルリクエストを比較するとWPFよりWinFormsの方が多い。

オープンソースになったことで、多くの不具合が見えて対応されていっている。

Blazor

いよいよ正式リリースされるBlazor。

ファイルがcshtmlとは分けて、.razorという拡張子になった。

ここでデモ。チャックさんのBlazorに対する思い入れは強いですね。

サーバーサイドだとVisual Studioデバッグするメリットがある。クライアントサイドではブラウザに頼るしかない。

ただし、サーバーサイドではオフラインでは動かない。

.NET Core 3.0でフルスタックなWeb開発環境が揃う。

  • Client ... Blazor, Components, SPA
  • Frontend .. MVC, WebAPIs, SignalR
  • Backend ... Worker services, gRPC

ML.NET

もうバージョンが1.3にもなったんですね。

ML.NET Model Builderにより、最適なアルゴリズムを自動的に決めてモデルを生成してくれるようになりました。

なんとチャックさんが、Buildのイベントで披露したデモを共有していただきました。

f:id:rimever:20191027141050p:plain
ML.NETのデモ

こちらもML.NETとBlazorで実装されたとのこと。

.NET 5

ASP.NET Web FormsはBlazorが代替。

WCFについてはgRPC for WCF server and remotingに代替。

移行ガイドドキュメント公開予定。

.NET Core移行についてはここがネックになってくるので、早めに移行ガイドドキュメントを公開してもらいたいところですね。

まとめ

この10年はクラウド革新。今後は?

技術を塩漬けするリスクと最新技術を使う意味。

毎回アップデートの度に最新というわけにはいかないが、LTSが出たタイミングで切り替えることで最新にする。

そうすれば最新のアプリケーションとなる。是非、今に目を向けて欲しい。

そして、何よりも楽しい。

.NET Core 3.0 + Windows 10 で WPF 開発 / Kazuki Ota (@okazuki)

WPF

DirectXで画面を自分で描画しているフレームワーク

WPFは基本的にWindowsだけがWindow。Windowハンドルを持っているのはWindowだけ。

凝ったコンポーネントが簡単に作れるのが良いところ。

最新のVisual Studioでは、デバッグ中にコードを書き換えると画面が変わるようになった。

.NET Coreのデメリット

ライフサイクルが短い。2,3年単位。

Windows組み込みではないためランタイム更新は考えないとならない。セキュリティパッチが出たら、自動更新されないので、こちらから提供されない。

Windows10 対応

説明を聞いていて思ったのが、.NET Core3.0はWindows7はサポートしているのか?と

Is .NET Core 3 compatible with Windows 7? - Stack Overflow

github.com

大丈夫そうですね。

.NET Core3.0はWindows10のAPIは呼べます。Microsoft.Windows.SDK.Contracts Packageを用います。

MSIX形式

ただし、MSIX形式については実質Windows10のみ対応です。

アプリケーションによっては実行時の動作が変わる

Inside FastEnum / Takaaki Suzuki (@xin9le)

以下のライブラリについてのお話。

github.com

.NET Coreが早くなっている。

2.2から3.0になってスループットが上がった。

それでもenumが遅いのはキャッシュしているが、キャッシュの持ち方が悪い。

都度、Reflectionしている箇所もある。

早くしたところのポイント

ラクリとしてはキャッシュしてるだけと思っていたのですが、そうではなく聞いていて奥深いなと。

  • 静的コンストラクタでReadonlyのリストにキャッシュすること。
  • 静的コンストラクタはスレッドセーフが保証されており、呼び出しコストが低減する。
  • Generic APIのみをサポート。Non GenericになるとBox化は避けられない。
  • カンマ区切り文字列は非サポート。ほとんど使わないので、そこは標準に任せて、対応しない。
  • IsDefinedはContainsKeyより範囲チェックの方が何倍も高速。
  • Parseは名前でも値でもパースできる。1文字目が数値かで判断する。C#は_かa-zでしか定義できない。数値や+/-はありえない。
  • string.Equals(OrdinalIgnoreCase)が最速。
  • ジェネリックの中で値の等号比較ができない。unsafeオプションを使わずにunsafeな処理を行う。
  • HasFlagはパフォーマンスで100倍の差で勝てなかったので、標準を使った方が良い。

紹介された参考資料

engineering.grani.jp

www.slideshare.net

learning.unity3d.jp

C#×LLVM=アセンブラ!? 〜詳説・Burstコンパイラー〜

部屋移動してUnityのセッションへ。ユニティテクノロジーズの方によるセッションです。

C#で速いコードを書きたい。そこでBurstコンパイラ

C#では、コンパイルするとILという中間言語を生成している。

UnityではIL2CPPという中間言語を生成する。WebGLJavaScript)でもUnityが動くようにしたかったので、こうした中間言語が必要になった。

現在では、このIL2CPPがベースとなってiOSなどの環境でも動作している。

そこでBurstコンパイラ。BurstコンパイラはDOTSの一種で、ILからIRに変換するコンパイラです。

LLVM

様々なプログラミング言語に対応可能なコンパイラ基盤。

Apple, Google, ARMも開発に参加している。

IR(Intermediate Representation)

LLVMが扱う中間言語

プログラミング言語・CPUアーキテクチャからは独立。LLVMはIRを対象に最適化する。

速い理由1:LLVMの最適化

LLVMの最適化が高性能であるため、これがコードの速度向上に貢献している。

C++ -> IR -(LLVMで最適化)> IR -> obj

C# -> IL -(Burst)> IR -(LLVMで最適化)> IR -> obj

LLVMでIRからIRに変換して、最適化されたIRを生成する。

速い理由2:SIMD(Single Instruction Multiple Data)

一つの命令で複数の計算を行う仕組み。

SSE(Intel CPU),NEON(ARM CPU)と名前は違えど同様の仕組み。

速い理由3:メモリの効率化

memcpy(src,dst,128);

一度で多くのメモリコピーを行う。ここでもSIMDを用いる。

ただし、コピー元とコピー先が被る時がある。

その場合、コンパイルでエラーが出る。

デメリット

Unityで書いたコードが全てBurstを通せるわけではない。Jobの中でしか使えない。

クラスは使えない。

  • クラスは構造体
  • 配列はNativeArray
  • 文字列はNativeString

また例外処理(try, catch, finally)はできない。ただし、throwは使える。

さらにベクタライズ

float4を使って、意識してコードを書くとベクタライズされてSIMDに乗るアセンブリとなる。4個ずつ処理される。

書きやすいようにUnity.Mathematicsで用意している。

とはいえ、LLVMだけでも速いコードになる。

設定について

ProjectSettingのBurst AOT Settingsで行う。

メインメニューのBurstではエディタの実行についての制御を行うのでビルドには関係ない。

エディタについて

エディタでの動作については、性能はあてにできない。

エラーチェックなどが走り安全に動作するため。

速度を見るのであれば、逐次ビルドしてプロファイラで見ること。

その他

これは参加したかった。見たいセッションの裏番組になっていましたので。

www.slideshare.net