しんさんのブログ

科学や技術のこと読書のことなど

Google Colabの使い方

機械学習 開発ツール TensorFlow GPU

Google colabを使えばTensorflowでプログラミングするのにローカル環境構築やGPUなどのハードの準備の必要なく
GPU/TPUを使って学習や推論も行うことができます。

Google colabとは

  • Googleのサーバークラウド上で動作するjupyter notebookの実行環境
  • juliayやRのサポートはない。Pythonのみをサポート　　

    Google colabの起動

    以下のいずれかの方法がお手軽

  • ブラウザでGoogle colabと検索する
  • Tensorflow公式サイト -> Learn -> For begginers -> Run code nowで mnistがColabで開く

Google colabの制限事項

  • 連続実行は12時間が上限.計算時間が12時間以上かかる際は途中で結果をセーブする必要がある。
  • アイドル状態が90分以上続くと自動停止する

    Tensorflow 2.0を使用する

  • 上記mnistサンプルの最初のセルでTF2.0のインストールを行っているんので参照すること

使用ハードウェアの変更方法

  • defaultではColab上のTFはCPUを使用するが、GPUを使用するように変更する
  • menu tabのランタイム-> ランタイムタイプを変更 -> ハードウェアアクセラレータ
    でGPUを選択する

Google Colab Runtimeのスペックの確認方法

  • ファイル -> Python3の新しいノートブックを開く
  • 右上の接続を押してGoogle ColabのVMに接続する
  • OSのバージョン確認: !cat /etc/issue
  • diskの割り当てと容量の確認: !df -h
  • メモリ容量の確認: !free -h
  • CPUの確認: !cat /proc/cpuinfo
  • GPUの確認: runtimeをGPUに変更する。 !ls /proc/driver/nvidia/gpus
    出てきたファイルを見る. !cat /proc/driver/nvidia/gpus/0000:00:04.0/information
  • GPUの詳細情報確認：

    • from tensorflow.python.client import device_lib

    • devece_lib.list_local_devices()

  • CUDAバージョンの確認: !nvcc -V
  • GPUカードのドライバのバージョン確認: !nvidia-smi

TensorFlow2.0への移行メモ

機械学習 開発ツール TensorFlow

TensorFlow2.0への移行メモ

いままでnativeのKerasと組み合わせて使っていたのですが、2.0からはtf.kerasを使うように変更しました。
また、TensorFlow2.0からはeager executionがdefaultになったようですのでそれにまつわることも含めて自分用のメモを書きます。

eager executionは便利なのですが、速度的にはgraph modeの方が早いので、できれば両対応できる方がいいなと思い調べると、
@tf.functionデコレータをつけるとgraphモード(TF1.x系デフォルト)になり、つけないとEagerモード(TF2.0デフォルト)で実行されることがわかりました。
今、どちらのモードで動いているのかを確認するには、
print(tf.executing_eagerly()) # true or false
で確認できます。
今は、@tf.functionを関数の定義の前につけています。
ただし困ったことに@tf.functionを付けてgraph modeにするとerrorが出てしまいます。
エラーの箇所は、model.fit関数です。
modelはkerasのfunctional APIのlayer modelで作成しているのですが、Sequentialモデルでレイヤーを重ねていても同じ問題は起きると思います。
エラーの理由はどうやら学習データの受け渡しのデータ形式がnumpyのndarrayの形式であることに由来しているようです。
そこでデータをtf.data.Datasetで変換して渡すようにしましたがまだerrorが残ります。
model.fitがgraphモードではうまく動かないのかもしれないです。
そもそもTF2.0でeager executionがデフォルトになったことでKerasとtensorflowのlow levl APIを組み合わせるおすすめの方法はないものかと思い始めました。
すべてKerasで書いて,eager exec modeで動かす限りはTF1.xとコードの書き方は変わらないのですが、速度の問題もあり一部graph modeで動かそうとするとKerasのAPIだけでは対応できないようです。
TF2.0でのコーディングに関しては以下のブログにまとまっています。
qiita.com
qiita.com
https://colab.research.google.com/drive/1UCJt8EYjlzCs1H1d1X0iDGYJsHKwu-NO#scrollTo=FjLI719fPfJi
結局、eager execとgraph modeを両対応したいと思えば、network のlayerはkerasを使い、学習はkerasのfitは使わずにtensorflowの低レイヤーで書くというのがよさそうです。

パターン1) modelの定義も学習もすべてkerasを使用して書く。
従来のkerasを使用した書き方。コードを書くのは簡単だが、eager executionでしか実行できないので、
学習に時間がかかる。
パターン2）modelの定義はkeras.model.layerをそのまま使用。学習はtfで書く。
メリットはデバッグ時は@tf.functionをコメントアウトしてeager execution modeでdefine by runの形で実行して
デバッグしやすくして置き、学習時は@tf.functionを有効にして速度重視でdefine and runのgraph mode で実行する。
パターン2の書き方だと上記の両対応が可能.
モデル定義はKeras APIをそのまま使用しますが、データセットをnumpyからtf.dataを使うように変更。
traing をkerasを使わずに書く時はnumpyのままでは入力できない。
Data Augmentationが複雑になってくる場合もtf.dataの形式の方が都合がよい。
tf.image以下が充実しているので、前処理が簡単にかける。
パターン3）modelの定義をkeras.model.layerを継承した独自のクラスで書く。学習はtfで書く。
このパターンが書きやすさとデバッグのしやすさ、パフォーマンスのバランスが一番よさそうですので今後はTF2.0ではこの書き方に
統一していこうと思います。

tensorflowのTFRecordに関しては以下の記事を参照
www.tdi.co.jp
www.tdi.co.jp

ちなみに、TensorFlow のtf.Tensorと NumPy の ndarray 間の変換は以下を参照
テンソルと演算  |  TensorFlow Core

TF2.0のコードの書き方とPytorchとの比較に関しては以下のブログを参照

www.hellocybernetics.tech

Google colabでPythonを簡単に試してみる

Python

Colabの開き方
1. Google Driveから
2. GitHubから
3. ローカルからアップロード


Google Colabのリソースの確認方法

file メニューから新しいノートブックを開き、
!cat /etc/issue
でUbuntuのバージョンを確認する。

ディスクの利用状況の確認
！df -h
disk free -humnan readable

メインメモリがどのくらいあるかの確認
!free -h

CPUのスペックについて確認
!cat /proc/cpuinfo

GPUのスペックについて確認
!ls /proc/driver/nvidia/gpus
エラーがでたら
run typeをGPUに変更する
!cat /proc/driver/nvidia/0000:00:04.0/information

GPUのメモリー容量を確認
from tensorflow.python.client import device_lib
device_lib.list_local_devices()

cuda バージョン確認
!nvcc -V

GPUカードのドライバの確認
!nvidia-smi

.pb

この拡張子はproto bufferの略で、tensorflowのモデルをテキスト形式で保存したもの

ハードディスク故障からのデータサルベージ

パソコン 雑談

今年の夏は暑かったということが関係しているのかどうかわかりませんが、
長年使っていたハードディスクが故障しましたのでその顛末を書きます。

  • 故障発覚

Windows10のマシンに２台のハードディスクを載せいていました。
起動ディスクはマシンを購入したときのWindows10起動ディスクでＣドライブで、
Ｄドライブは自分で追加したATA の１ＴＢディスクで以前使っていたマシンのwindowsが消去しないまま入っていました。
それ以外の空き部分をデータ領域として使っていました。
古いハードディスクなので若干不安だったので、最悪消えてもいいデータだけを置くようにしていました。
ある日、上記マシンが急に起動しなくなりました。
内部からハードディスクのアクセス音が、カチカチと一定のリズムでなっているのでディスクにトラブルが起きたのだとすぐにわかりました。
Ｃドライブのトラブルだと思い込んでいて、新しいマシンの選定まではじめました。
Ｃドライブは少し前に外付けドライブにバックアップを取っていました。
ひょっとするとＤドライブのトラブルかもとふと思い立ち、ケースを開けてＤドライブを外すと、ＰＣは何事もなく立ち上がり、Ｄドライブの故障ということが確定しました。
外付けのUSB接続のケースに入れて、Windowsのエクスプローラで見るとドライブすら見えなくて、この時点ではデータは厳しいかもという印象でした。

  • データ救出

ネットでサーチすると自分とよく似た症状の方が、Linuxを使ってドライブをコピーしている記事を目にして早速同じようにやってみました。
https://ameblo.jp/personwritep/entry-12346573971.html
この記事と同じようにGPartedでドライブを見てみると、ビックリマークはついていますがドライブは見えます。(故障したディスクは外付けのケースでUSB接続)
そこで、記事と同じようにddコマンドを使って、Linuxマシンの使っていない内臓１ＴＢハードディスクにコピーしようとしましたが。
読めない部分が多いためか、非常に時間がかかり、コピーの途中でいったん終了させました。
そこで、故障したディスクから無事なデータの部分を救い出すときによく使われる
ddrescueを使うことにしました。ddrescueについては以下の記事に解説あり。
https://wiki.archlinux.jp/index.php/%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E3%81%AE%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%B3#ddrescue_.E3.82.92.E4.BD.BF.E3.81.86

ddrescueについてはネットを調べると色々出てきます。
https://dspckn.blogspot.com/2017/10/ddrescue.html
https://qiita.com/ryuichi1208/items/76806a1547fb94da2bca
ポイントはきちんとlog fileをつくっておくことでしょうか。
log fileさえ作っておけば途中からの再開や、エラーのある部分だけ再度読み込みを試みることもできるようです。

以上、自分用のメモです。