2016/5/9「JXUGC #13 東京 緊急開催 Xamarin のすべて！」でLTしてきました
誰とも被らなそうなネタ(誰も興味が無いかもしれないネタ)ではあるんですが、ごく一部の人ぐらいには刺さるかなぁと思って、 C++ と C# を全部、Visual Studio だけでどこまで出来るんだ？っていう可能性を確かめてみたという話でLTしてきました。
www.slideshare.net
結論から言えば、割と面倒というか、そこまでして Visual Studio で全部やらなくてもいいじゃないか的な(誰もが分かってる)部分がありました。
箇条書きにすると、
- p/invoke でどんな DLL でも呼び出せる C# 神。
- Androidへのディプロイはかなり簡単(条件付き)
- iOS は、vcremote は使えるけど微妙に不安定
- universal-binary 化が正攻法では出来なさそう
です。やり方を考えないと、普通に使う分にはまだまだ問題がありますねぇという結論になってない感じの結論で終わった話です。
まぁ、LT で 10分だったので、本当は書きたかった話も割愛している部分が多いので、近いうちにフォローアップの記事を書くかもしれません。
しかし、17人もの方々が発表されたのにも関わらず(僕以外の発表はどれも素晴らしいものばかりでした。ライブコーディングとか心強すぎとかw)、驚異的なスケジューリングにより、時間ぴったりに終了できたのは、もう、運営さんスゲーとしか言えないですね。
# そして、懇親会で飲み過ぎ、日曜日を棒に振りました。
新しい VC++ のコンパイラを試す
ツイッターを見てたら、
Introducing a new, advanced Visual C++ code optimizer | Visual C++ Team Blog
こんなのがありまして、へー、でも試すの面倒くさいなぁと思っていたらですね、
こんなのもあって、要は、「nuget で簡単に最新コンパイラ試せるよ！」ってなってたわけです。
知りませんでした。簡単ですねー。
で、
ってあったんですが、コマンドラインから叩きたい。既に VS2015 入っているという僕には、いろいろ面倒そうなので、別の未知を模索してみました。
インストールしてみた(自己流)
とはいえ、やったことは簡単です。
http://dist.nuget.org/win-x86-commandline/latest/nuget.exe
をダウンロードして、適当なフォルダに配置して、
nuget install VisualCppTools -source http://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease
って実行しました。そうすると、 VisualCppTools.14.0.24104-Pre\lib\native に dll やら exe やらが沢山展開される。
このまま実行しても良いですけど、 CRT のヘッダ・ライブラリしかないよんって感じなので、どうにか Windows 系のヘッダとかも参照したい。
しばらく考えた末、
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" set PATH=C:\Users\kawasaki\Desktop\cl\VisualCppTools.14.0.24104-Pre\lib\native\bin\amd64;%PATH%
続続) 気づいたら、C# が C++ の速度を凌駕している！
先日の記事、
.NET Native だとどうよ？っていう話があったので、試してみました。
コードは趣旨を変更しない範囲で弄りました。
スレッドプールのプライオリティとかどうなってんの？っていう疑問はあるんですが、
実行した感じ、それらの影響はなさそうなので、結構適当です。
概要だけ提示できれば良いので、XAMLは提示しませんが、普通にバインドして表示しているだけです。
using System; using System.Collections.ObjectModel; using System.Diagnostics; using System.Threading.Tasks; using Windows.UI.Xaml.Controls; namespace App1 { public sealed partial class MainPage : Page { public ObservableCollection<double> Times { get; } = new ObservableCollection<double>(); public MainPage() { this.DataContext = this; this.InitializeComponent(); Loaded += (s, e) => workOnBackground(); } async Task workOnBackground() { double t1 = 0, t2 = 0; await Task.Factory.StartNew(() => { int w = 4321; int h = 6789; int stride = (w + 3) & ~3; var a = new byte[stride * h]; t1 = time(() => test1(a, w, h, stride)); t2 = time(() => test2(a, w, h, stride)); }); Times.Add(t1); Times.Add(t2); } static void test1(byte[] a, int w, int h, int stride) { for (int y = 0; y < h; y++) { int offset = y * stride; for (int x = 0; x < w; x++) { a[x + offset] = (byte)(x ^ y); } } } static unsafe void test2(byte[] a, int w, int h, int stride) { fixed (byte* p0 = a) { for (int y = 0; y < h; y++) { byte* p = p0 + y * stride; for (int x = 0; x < w; x++) { p[x] = (byte)(x ^ y); } } } } static long time(Action action, int count = 100) { var tw = new Stopwatch(); tw.Start(); for (int i = 0; i < count; i++) action(); tw.Stop(); return tw.ElapsedMilliseconds; } } }
結果
32-bit/64-bit で特に何の差も見れませんでしたので、そこに関しては割愛。
結局、ここにある、 "Compile with .NET Native tool chain" を ON/OFF した結果だけです。
OFF の時。
ON の時。
面白いですねー。
.NET Native が OFF の場合の速度の傾向はフルの .NET Framework 4.6 のコードと同じですね。配列は遅く、 unsafe は速い。ただ、前回調べた、 .NET Framework 4.6 や C++ と比べると、微妙に遅いですね。
ところが、 .NET Native を ON にすると、配列と unsafe の速度差がグッと縮む。速度的に、2～3%程度の差しかありません。この差だと、 unsafe コードを無理して使わないでも良いような気がする速度です。
この差を見せられると、時間をかけてコンパイルできる AOT コンパイラは馬鹿に出来ないなぁと思わざるを得ません。
.NET Framework 4.6 や C++ との速度差は、プライオリティの問題かもしれませんし、フレームワーク自体の問題かもしれませんし、その他のノイズかもしれません。調べるのが面倒なのでそこまでは追求しません。
続) 気づいたら、C# が C++ の速度を凌駕している！
先日のこの記事ですが、
メモリ確保を関数の中でやってるのが悪いんじゃね？疑惑がありまして、そうなのであれば・・・ということで書き直しました。モダンな感じで。
C# 版
// Compile: csc /o /unsafe speedtest.cs using System; using System.Diagnostics; class SpeedTest { static void test1(byte[] a, int w, int h, int stride) { for (int y = 0; y < h; y++) { int offset = y * stride; for (int x = 0; x < w; x++) { a[x + offset] = (byte)(x ^ y); } } } static unsafe void test2(byte[] a, int w, int h, int stride) { fixed (byte* p0 = a) { for (int y = 0; y < h; y++) { byte* p = p0 + y * stride; for (int x = 0; x < w; x++) { p[x] = (byte)(x ^ y); } } } } static void time(Action action, int count = 100) { var tw = new Stopwatch(); tw.Start(); for (int i = 0; i < count; i++) action(); tw.Stop(); Console.WriteLine(tw.ElapsedMilliseconds); } static void Main(string[] args) { int w = 4321; int h = 6789; int stride = (w + 3) & ~3; var a = new byte[stride * h]; time(() => test1(a, w, h, stride)); time(() => test2(a, w, h, stride)); } }
C++ 版
// Compile: cl /MD /Ox /EHsc speedtest.cpp #include <stdio.h> #include <windows.h> #include <functional> typedef unsigned char byte; static void test2(byte* a, int w, int h, int stride) { auto p0 = a; for (int y = 0; y < h; y++) { auto p = p0 + y * stride; for (int x = 0; x < w; x++) { p[x] = (byte)(x ^ y); } } } void time(std::function<void()> action, int count = 100) { auto start = GetTickCount(); for (int i = 0; i < count; i++) action(); printf("%u\n", GetTickCount() - start); } int main() { int w = 4321; int stride = (w + 3) & ~3; int h = 6789; auto a = new byte[stride * h]; time([=]() { test2(a, w, h, stride); }); delete[] a; }
気づいたら、C# が C++ の速度を凌駕している！
5年半程前に書いた、この記事。
C#というか、.NET Framework 4.6 は、 RyuJIT という新しい JIT の導入によって、64-bit 環境での実行が高速化されています。なので、さーて、少しは面白い結果が出るんじゃないかなぁーと。
で、環境は、
Windows 10 Pro Insider Preview Build 14332
.NET Framework 4.6.1
Visual Studio 2015 Update 2
CPU: Intel Core i7-3770S 3.1GHz
Memory: 32GB
という環境です。ここで、実行してみました。
まずは、C#版。
3091
2282
上が配列。下が unsafe コード。unsafe が速くなってます。74%ぐらいの時間で終わるようになってる。
unsafe コードを書くモチベーションが上がります。better C として考えると、モチベーション上がりますねー！
さて、C++版。
2344
んん？あれっ？実行するプログラム間違った？
いや、間違ってない。
遅いじゃないですかー。C#に負けてるじゃないですかー。これ、64-bit 版です。
32-bit だったら？
2343
変わんねー。
C++ 敗北。
もう、C++使う理由がなくなる感じなのでは・・・。
仕事によっては、C++指定、あるいは、そうせざるを得ないことってありますけど、この結果は予想外です。個人的には、嬉しいです。
