ミーティングとか発表時に持ってるとスゲー便利な接続ケーブル
最近は、 MacBook Pro は言うに及ばず、 Surface、ThinkPad の全てに Mini DisplayPort が標準搭載されています。
普通は、こいつらを使ってる限り、プロジェクターに接続できなくても誰かがケーブル持ってるよねぇ的な気持ちにもなるんですが、それでも、会社によっては、未だにアナログRGBしかなかったり、まぁ、変換ケーブル持ち歩くにも相手の都合によっていろいろ持ち歩かないとイケないのはダルいし、そもそも、Apple 純正品なんて買おうものなら金がいくらあっても足らない。
Amazon は良いんですけどね、玉石混淆で、どれが正解なのかさっぱり分からん。
そんな中で、僕が何度も購入してる(たまにどっかに忘れてくるw)奴を紹介しておきます。
Mini DisplayPort オス to HDMI/DVI/VGA メス 3-in-1変換アダプタケーブル 黒
VGA、HDMI(4K対応)、DVI、これだけ生えてれば客先でケーブルの形が違って困るとかもほぼないはずです。
これだけの機能からすると激安ですし。
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; }