Jupyter notebookをPython仮想環境で使う方法 Anaconda編

自分の憶えとして記録. Jupyterノートブックを pythonの仮想環境で動かす方法は以下のとおり。 (Anaconda3を使用している場合)

1. 仮想環境の準備
Anaconda3 の Anaconda Powershell Prompt で以下のコマンドを使い仮想環境を作成
$ conda create -n 仮想環境の名前 ipykernel

仮想環境に入って、おまじない
$ conda activate 仮想環境の名前
$ python -m ipykernel install --user --name 仮想環境の名前

仮想環境から出る
$ conda deactivate

2. Jupyterノートでの作業

2.1 Anaconda3 の Jupyter Notebook を開く
2.2 開いたブラウザーの画面で目的のノートブック (.ipynbファイル)を開く
2.3 開いたブラウザーの画面で、プルダウンメニューの Kernel > Change kernel > 仮想環境の名前 を選び、仮想環境に切り替える

なお、仮想環境でのおまじない無しでは、Change kernel の選択肢にその仮想環境が出てこない。

ESP32向けArduino開発環境の設定方法

ちょいとした電子工作で、昔のトラ技の付録でそのまま眠っていた IoT Express を使うことにした。

ということで、Arduino IDEのセットアップ。トランジスタ技術 2017年11月号のp46にはちょいと面倒くさい手順が書いてあるが、現時点ではもっと簡単。ちなみに、開発ホストは Windows 10。

Arduino IDE自身は、本家のダウンロードページで Windows app Win8.1 or 10 とある行をクリックすれば、寄付のお願いのページを経由してMicrosoft Storeにリダイレクトされて、そこからインストール。この場合、「ドキュメント」の下に、Arduinoフォルダが作られる。

次に、Arduino coore fo the ESP32だが、Arduino IDE を開き、ファイルのメニューから環境設定を選び、環境設定ウィンドウを開く。設定タブの下の方に「追加のボードマネージャのURL:」という欄があるので、そこに以下のURLを書けばよい。既に何か書いてある場合は、カンマで区切って書き足す。これでOK。　トラ技の記事のようにGithubから落としてごちょごちょとやる必要はもうない。

https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json

ちなみに、上記URLは、下記サイトに記載がある。

https://github.com/espressif/arduino-esp32/blob/master/docs/arduino-ide/boards_manager.md

そのあと、Arduino IDEのツールのメニューから、ボード > ボードマネージャ　でボードマネージャを開く。画面を下にスクロールしていって、esp32を探す。そこにマウスをあてるとインストールというボタンがあるので、それをクリックすれば、ESP 32の各種ボードを選べるようになる。

以上。

Tesla K80を動かしてみる

NVIDIAの TESLA K80で手始めにサンプルプログラムを動かすところまでの記録。ハマった原因は二つ。

1.  TESLA K80は、Kepler という今では4世代前の古いアーキテクチャ

2.  CPUの内蔵グラフィクスを利用

ハードウェアは CPUが 11700K (第１１世代 Core i7)で、マザーボードは ASUS TUF GAMING Z590 PLUS、グラボなしの構成。

ソフトウェアは、Windows 10 . ドライバーは、NVIDIAのサイトから入手.  (462.31-data-center-tesla-desktop-win10-64bit-international.exe). 　開発環境は、Microsoft Visual Studio Community 2019 にCUDA Toolkit 11.3.1 (cuda_11.3.1_465.89_win10.exe) をインストール。

#ちなみに、VS2019には、intel oneAPI ツールキットも先にインストールしていたが問題ないようだ。

Step 0. インストール

インストールに特別なことはなし。GPUカードを刺して立ち上げ、ドライバーをインストール。Visua Studioはインストール済みのところへ、CUDA Toolkit をインストール。

Step 1. hello.cu の実行

まず、これが正しく動作しなくて悩む。

こちら (https://www.kkaneko.jp/tools/win/cuda10.html#S2) に従って hello.cuを作成しコンパイル。

で、実行結果した結果はこうなるはずが...

C:\test>a.exe
Max error: 0.000000

下記のようになってしまった。

C:\test>a.exe
Max error: 2.000000

いろいろデバッグしてみた結果、GPU側のコードが動いていないようなので、下記のようにソースを書き換えてみると... エラーコード 209が起きていると判明。

------------

  // Perform SAXPY on 1M elements
  saxpy<<<(N+255)/256, 256>>>(N, 2.0f, d_x, d_y);

err = cudaGetLastError();
printf("LastError %d\n",err);

-------------

今回のケースだと、古いアーキテクチャのKeplerで動くようにはできてませんというエラー。nvcc のパラメータでターゲットを指定できるのではないかと調べると、やはりありました。

下記のように -arch sm_37 と指定すれば、「古いアーキテクチャだからそのうちサポートしなくなるよ」という警告が出るもののちゃんとコンパイルできる。

C:\test>nvcc -arch sm_37 hello.cu
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
hello.cu

これでOK. ちゃんと、a.exe は期待通りの動作をするようになった。

Step 2.  CUDA Toolkit のサンプルプログラム nbodyを動かす。

CUDA Toolkitにはサンプルプログラム一式もついてくる。そのうちnbodyのありかは下記.

C:\ProgramData\NVIDIA Corporation\CUDA Samples\v11.3\5_Simulations\nbody

ここにある　nbody_vs2019.sln を Visual Studio 2019で開き、ソリューションのビルドをすれば完了。

だが、Visual Studioから実行をかけると下記のように即終了してしまう。本来はウインドウが開いて質点が動き回わる様子が表示されるはずなのだが。

...(省略)...

CUDA error at C:\ProgramData\NVIDIA Corporation\CUDA Samples\v11.3\5_Simulations\nbody\bodysystemcuda_impl.h:188 code=304(cudaErrorOperatingSystem) "cudaGraphicsGLRegisterBuffer(&m_pGRes[i], m_pbo[i], cudaGraphicsMapFlagsNone)"

C:\ProgramData\NVIDIA Corporation\CUDA Samples\v11.3\bin\win64\Debug\nbody.exe (プロセス 13336) は、コード 1 で終了しま した。
デバッグが停止したときに自動的にコンソールを閉じるには、[ツール] -> [オプション] -> [デバッグ] -> [デバッグの停止時に自 動的にコンソールを閉じる] を有効にします。
このウィンドウを閉じるには、任意のキーを押してください...

 

この原因は、グラフィクス出力が必要だけど計算をしているTESLA K80にディスプレイ出力が無い、ということらしい。グラボでCUDAの場合はそのグラボにディスプレイを接続して解決だけど、K80にはもともとディスプレイ出力機能は無いし... 　で、はたと思いついた。グラフィクスはCPU側で行っているのだから nbodyのパラメータにある -hostmem を指定してデータをホスト側メモリにストアさせればいけるんでないかい。試してみるとビンゴ。無事に画面が開いた。DOS窓から実行形式を起動する場合のパラメータの指定方法は書くまでもないが、Visual Studioから起動する場合は、デバッグプロパティで指定する。

プルダウンメニューの デバッグ > nbodyのデバッグ プロパティ 　でプロパティページを開き、左のペーンにあるツリーで構成プロパティ>デバッグ　を選択。コマンド引数 のところの値が空だけど、そこに-hostmem と書いて OK をクリックする。　ReleaseとDebugの二つの構成のそれぞれに行っておく。

なお、Debug構成でビルドしたものとRelease構成でビルドしたものでは実行速度が格段に違う。Release だと光点がびゅうびゅん飛び回る.  K80の半分しか使っていないけど約 1TFLOPS.

以上はソフトの話だが、Tesla K80 の冷却で試行錯誤した話はこちら。

またもや熱に敗れる - 理乃美

横から風をあてて冷却をこころみたのがこちら。Tesla K80の熱は手ごわい - 理乃美

強力なファンに変えて、冷却はできたけど... というのがこちら。Tesla K80 の発熱に勝った..のか？ - 理乃美

20年前のプログラムに手間取った

昔のプログラムをコンパイルしなおそうとしてハマったお話。

きっかけはメインPCの突然の故障。こんなタイミングでPCを買い替える羽目になった。新しいマシンは第11世代のCorei 7搭載。

そうだな、ベンチマークでもするか。... とはいえ、グラボではなくCPU内蔵のグラフィクスなので、FF14とかのゲームのベンチは意味ないし、そうだ円周率でも計算してみるか。ということで、昔書いたプログラムを発掘して試した。

100万桁が、2秒。  ... あれ？   そんなもん？　それにCPUの使用率がえらく低いし...

あぁ、そういえばこれ32bitコードだったっけ。20年前に書いたプログラムだものなぁ。当時はOSも32bit OSだし。CPUのコアは一つしか考えられなかった。

まずは、開発環境としてVisual Studio 2019 と Intelの oneAPI Toolkits をダウンロードしてインストール。

# あの頃は、Visual Studioも intelのコンパイラーも大枚はたいて買ったっけ。まったく良い時代になったものだ。

Visual Studioで作ったCUIのプログラムなので、リビルド一発かと思いきやコンパイルエラーが... 曰く、iostream.h なんてありません、cout ってなんですかぁ。.... そういえば、昔は名前空間なんてなかったよな。ということで言語の進化にまず躓く。まあ、機械的な修正で済むけど。

で、ビルドはできたけど、これはまだターゲットがx86のままの場合。で、ターゲットをx64に変更してリビルドをかけたら、またもやコンパイルエラー。曰く、インラインアセンブラは使えません！　うぅぅむ。

C++での実装もコメントで残してあったので、そちらに切り替えてビルドする。結果は、100万桁が 3秒.      遅いぞ。

さてどうしたものかと、ググって対策を検討。インラインではなく、別ファイルに切り出した純粋のアセンブラコードにするという手もある様だが、組み込み関数 intrin.h  を選択。やはりコンパイラーに最適化を頑張って欲しいし。

ということで、今度は 100万桁が 1秒。　( 計測値が秒単位で荒いのは　difftime( ) で値を出しているから。)

で、.... ここでめげた。　このプログラム、データのキャッシュを利かせるために再帰をループに換えていたり、小さなループを手で展開したり、といった細かい細工を積み重ねてできているのでコードがむちゃ汚い。

マルチコアとかSIMDといった現代のアーキテクチャを活かすように書き換えるなら、チューニングする前のアルゴリズムに忠実な実装を発掘しないとちょっとつらい。

ということで、Visual Studio で作ったCUIのプログラムだからリビルドは造作もないだろうと思いきや、しっかりハマったというお話でした。