題名の通り。
VS2017からVS2017.3に更新したところ発生しました。
これまでのVisual Studioでも同様の事例はありましたが、ここまできてもこのような現象が発生すると萎えます。
例のごとくStackoverflowで回答が。
ただ、最終的にAnswerにはなっておらず、一部のコメント投稿者は、後述の方法で解決した模様。
私が試したのは、MSTest.TestAdapter, MSTest.TestFramework というMicrosoft製のNugetパッケージを更新する方法でした。
どちらも1.1.18になっていればOKかと。
PythonのWindows用環境はAnacondaやMinicondaが有名ですが、初期パッケージの数が少ないMinicondaを専ら好んで使っています。
そんなMinicondaはPython 2.7とPython 3.6をインストールできるパッケージが用意されています。
これを使い分けて、Windowsの環境に共存させたいと思います。
実は、Anacondaでの2と3の共存については記事があります。
今回はこれを参考にさせてもらいました。
やることは変わりません。
私は、Python2をデフォルトにしました。3をデフォルトにしてはいませんが、多分大丈夫?
まず環境変数ですが、
とします。
ユーザーの環境変数 (システムの環境変数ではない!!) のPATHが、下記の順序で追加されているようにします。
最後に、コマンドプロンプトを立ち上げ、Miniconda3のインストールパスに移動します。
必要に応じて管理者権限は付与してください。
そして下記のコマンドを叩きます。
|
1 2 3 4 5 6 7 8 |
copy python.exe python3.exe cd Scripts move conda.exe conda3.exe move conda-script.py conda3-script.py move easy_install.exe easy_install3.exe move easy_install-script.py easy_install3-script.py move pip.exe pip3.exe move pip-script.py pip3-script.py |
コマンドプロンプトを立ち上げ直します。
そして、正しく共存できているかを確認します。
|
1 2 3 4 5 |
C:\Users\XXXXXX>python3 --version Python 3.6.1 :: Continuum Analytics, Inc. C:\Users\XXXXXX>python --version Python 2.7.11 :: Continuum Analytics, Inc. |
無事に共存できました!!
最新のCMake 3.9.2が悪いのか、Visual Studio CodeでCMakeを使おうとするとエラーになります。
WindowsのVisual Studio CodeでCmakeを使うという記事はたくさんあります。
が、それでも上手くいかない。
Lixnuでは既に自分でも試しており楽勝のはずだったのですが...
具体的には、
Started new CMake Server instance with PID 13456
Build program for generator Ninja is not found. Skipping...
Build program for generator Unix Makefiles is not found. Skipping...
None of preferred generators available on the system.
というエラーが出力されております。
CMake toolsのIssueにヒントがありました。
エラー出力にもありますが、Ninjaが存在しない、って言っているのでそれをインストールします。
Ninjaはスピードに特化した小型のビルドツールとのこと。
私はよくわからないので、詳しいことはググってください。
とりあえず、Githubのリリースから最新のバイナリをダウンロードして適当なフォルダに配置します。
続いて、Visual Studio Codeの設定に、下記のような内容を記述します。
|
1 2 3 4 5 6 |
{ "cmake.generator": "Ninja", "cmake.configureSettings": { "CMAKE_MAKE_PROGRAM": "D:/Works/Lib/Ninja/1.8.2/ninja.exe" } } |
設定後、Visual Studio Codeを再起動し、いつものようにCake: Quick Start的な感じで始めることが出来るようになっているはずです。
前回はdlibをCUDAを有効にしたバイナリ、無効にしたバイナリを生成しました。
具体的に、CUDAを有効にしている状態で、どれだけ性能差が出るのかを比較したいと思います。
まずは、実験に使う画像を用意します。
今回は下記を用意しました。
元画像: https://upload.wikimedia.org/wikipedia/commons/b/b7/G7_summit_at_Shimakan.jpg
4368x2912の大きなサイズです。
次に計測を行うソースです。
examples\face_detection_ex.cppという顔検出のサンプルがあります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
#include <dlib/image_processing/frontal_face_detector.h> #include <dlib/gui_widgets.h> #include <dlib/image_io.h> #include <iostream> using namespace dlib; using namespace std; // ---------------------------------------------------------------------------------------- int main(int argc, char** argv) { try { if (argc == 1) { cout << "Give some image files as arguments to this program." << endl; return 0; } frontal_face_detector detector = get_frontal_face_detector(); image_window win; // Loop over all the images provided on the command line. for (int i = 1; i < argc; ++i) { cout << "processing image " << argv[i] << endl; array2d<unsigned char> img; load_image(img, argv[i]); // Make the image bigger by a factor of two. This is useful since // the face detector looks for faces that are about 80 by 80 pixels // or larger. Therefore, if you want to find faces that are smaller // than that then you need to upsample the image as we do here by // calling pyramid_up(). So this will allow it to detect faces that // are at least 40 by 40 pixels in size. We could call pyramid_up() // again to find even smaller faces, but note that every time we // upsample the image we make the detector run slower since it must // process a larger image. pyramid_up(img); // Now tell the face detector to give us a list of bounding boxes // around all the faces it can find in the image. std::vector<rectangle> dets = detector(img); cout << "Number of faces detected: " << dets.size() << endl; // Now we show the image on the screen and the face detections as // red overlay boxes. win.clear_overlay(); win.set_image(img); win.add_overlay(dets, rgb_pixel(255,0,0)); cout << "Hit enter to process the next image..." << endl; cin.get(); } } catch (exception& e) { cout << "\nexception thrown!" << endl; cout << e.what() << endl; } } |
これに対して、上述の画像を認識させると
こうなります。
このソースを下記のように改造します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
#include <dlib/image_processing/frontal_face_detector.h> #include <dlib/gui_widgets.h> #include <dlib/image_io.h> #include <iostream> #include <chrono> using namespace dlib; using namespace std; // ---------------------------------------------------------------------------------------- int main(int argc, char** argv) { try { if (argc == 1) { cout << "Give some image files as arguments to this program." << endl; return 0; } frontal_face_detector detector = get_frontal_face_detector(); image_window win; std::chrono::system_clock::time_point start, end; start = std::chrono::system_clock::now(); // Loop over all the images provided on the command line. for (int c = 0; c < 100; c++) for (int i = 1; i < argc; ++i) { cout << "processing image " << argv[i] << endl; array2d<unsigned char> img; load_image(img, argv[i]); // Make the image bigger by a factor of two. This is useful since // the face detector looks for faces that are about 80 by 80 pixels // or larger. Therefore, if you want to find faces that are smaller // than that then you need to upsample the image as we do here by // calling pyramid_up(). So this will allow it to detect faces that // are at least 40 by 40 pixels in size. We could call pyramid_up() // again to find even smaller faces, but note that every time we // upsample the image we make the detector run slower since it must // process a larger image. pyramid_up(img); // Now tell the face detector to give us a list of bounding boxes // around all the faces it can find in the image. std::vector<rectangle> dets = detector(img); //cout << "Number of faces detected: " << dets.size() << endl; // Now we show the image on the screen and the face detections as // red overlay boxes. //win.clear_overlay(); //win.set_image(img); //win.add_overlay(dets, rgb_pixel(255,0,0)); //cout << "Hit enter to process the next image..." << endl; //cin.get(); } end = std::chrono::system_clock::now(); double elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(end-start).count(); //ミリ秒に変換 std::cout << std::fixed; cout << "Total: " << std::setprecision(4) << elapsed << endl; cout << "Average: " << std::setprecision(4) << elapsed / 100 << endl; } catch (exception& e) { cout << "\nexception thrown!" << endl; cout << e.what() << endl; } } |
要するに、入力した画像ファイルを100回認識させ、その処理に要した合計時間と平均時間を算出するようにしただけです。
下記がその結果です。
| Left align | Total(ms) | Average(ms) |
|---|---|---|
| w/o CUDA | 1007778.0000 | 10077.7800 |
| w/ CUDA | 997522.0000 | 9975.2200 |
正直微妙です。約10%しか差がありません。
前回は、自作のSharedライブラリに定義された関数をP/Invokeで呼び出してみました。
しかしながら、毎回毎回/usr/local/libとかにコピーするのってどうなんでしょう?
Windowsみたいに、実行ファイルと同じディレクトリにSharedライブラリを配置しても動作するのでしょうか?
Windowsの場合、exeが呼び出すdllは、実行ファイルから以下の順序で検索されます。
Linuxの場合、3,4以外は同じ条件で試すことができそうです。
ただ、.NET Coreの場合、dotnet runで動作する場合のカレントディレクトリに関して情報がないので、2もちょっと先送り。
最終的に下記の内容をテストしてみます。
サンプルは、.NETでLinuxと遊んでみる Visual Studio Code編 第7回と同じものを使います。
これは動かないはずです。
実行ファイルと同じディレクトリ、/usr/local/lib64にSharedライブラリが存在しないことを確認してから実行してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ sudo updatedb $ sudo locate libCppLib.so /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CppLib/build/libCppLib.so /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CsharpApp/bin/Debug/netcoreapp2.0/libCppLib.so.bak $ export | grep LD_LIBRARY_PATH $ pwd /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CsharpApp $ dotnet run 20 50 Unhandled Exception: System.DllNotFoundException: Unable to load DLL 'libCppLib.so': The specified module or one of its dependencies could not be found. (Exception from HRESULT: 0x8007007E) at CsharpApp.Program.Add(Int32 x, Int32 y) at CsharpApp.Program.Main(String[] args) in /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CsharpApp/Program.cs:line 15 |
Windowsと同じように、System.DllNotFoundExceptionがスローされました。
期待通りです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$ pwd /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CsharpApp $ ls -la bin/Debug/netcoreapp2.0/ 合計 32 drwxrwxr-x 2 xxxxxx xxxxxx 171 8月 21 23:50 . drwxrwxr-x 3 xxxxxx xxxxxx 27 8月 19 06:58 .. -rw-rw-r-- 1 xxxxxx xxxxxx 437 8月 19 07:41 CsharpApp.deps.json -rw-rw-r-- 1 xxxxxx xxxxxx 4608 8月 21 23:43 CsharpApp.dll -rw-rw-r-- 1 xxxxxx xxxxxx 568 8月 21 23:43 CsharpApp.pdb -rw-rw-r-- 1 xxxxxx xxxxxx 206 8月 19 07:41 CsharpApp.runtimeconfig.dev.json -rw-rw-r-- 1 xxxxxx xxxxxx 146 8月 19 07:41 CsharpApp.runtimeconfig.json -rwxr-xr-x 1 root root 8016 8月 19 07:56 libCppLib.so $ dotnet run 20 50 20 + 50 = 70 |
きちんと動作しました。
これは気になりますね。
別に.NET Coreに関係なく、Linuxの仕組みと同じような気がしますが...
実行時、どちらが呼び出されたかわかるように、Sharedライブラリ側を修正します。
実行ファイルに配置するSharedライブラリ
|
1 2 3 |
#include <iostream> extern "C" int Add(int x, int y){ printf("from executed directory\n");return x + y; } |
/usr/local/lib64に配置するSharedライブラリ
|
1 2 3 |
#include <iostream> extern "C" int Add(int x, int y){ printf("from /usr/local/lib64\n");return x + y; } |
これらをそれぞれビルドして、/usr/local/lib64、実行ファイルと同じディレクトリであるbin/Debug/netcoreapp2.0/にコピーします。
また、環境変数LD_LIBRARY_PATHに/usr/local/lib64を追加します。
一応、各ディレクトリにSharedライブラリがコピーされたことも確認しておきます。
そして、dotnet runで実行します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$ pwd /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CsharpApp $ export LD_LIBRARY_PATH=/usr/local/lib64 $ sudo updatedb $ locate libCppLib.so /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CppLib/build/libCppLib.so /home/xxxxxx/Work/Demo/DotNetCoreLinux6/CsharpApp/bin/Debug/netcoreapp2.0/libCppLib.so /usr/local/lib64/libCppLib.so $ dotnet run 20 53 from executed directory 20 + 53 = 73 $ rm bin/Debug/netcoreapp2.0/libCppLib.so $ dotnet run 20 53 from /usr/local/lib64 20 + 53 = 73 |
結果としては、実行フォルダのSharedライブラリが優先されました。
また、実行フォルダのSharedライブラリを削除しても、/usr/local/lib64のSharedライブラリが使用され、きちんと動作することもわかりました。
結論としては、Windowsと同じく、実行ファイルのあるディレクトリに配置されているライブラリが優先のようですね。