Vengineerの戯言

人生は短いけど、長いです。人生を楽しみましょう！

AlibabaのMNN

@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

Alibabaもせめてきているから9か月。

vengineer.hatenablog.com

そこで最後の紹介した Alibaba の ディープ・ラーニングフレームワーク MNN の

論文がアップされていました。MNN は推論用ですね。

arxiv.org

この論文では、Model側 を upstream、Device 側を downstream と呼んでいるっぽ。

 

1)、Caffe、TensorFlow、PyTorch、ONNXのモデルを MNN のフォーマットに変換。

2)、オフラインのグラフ最適化 (モデル圧縮) 

3)、最適化後のモデルから計算グラフと Backend Abstraction (バックエンドの情報) から Pre-inference にて、最適な計算スキームを決める

4)、デバイス上で推論

 

 3)での、Pre-inference が MNN でのポイント。。。特に、MNNでは、CPUとGPUを上手く組み合わせて使う感じ。CPUでは、ARMとARM82、GPUではMetal、Vulkan、OpenCL、OpenGL ES。CPUとGPUのリソースに対して、最適化後のモデルにそれぞれのリソースで利用できる最適なもの(OPの実装)を使うというのがみそ。。

ARM82をサポートしたのは、半精度をサポートしているからっぽい。

Graph実行だけではなく、多少のComputerVisionもサポート。

MNNではまだ完全自動化(Automated Search)ではなく、Semi-automated Search の模様。

 

 論文の後半では、

・NCNN (Tencent)

・MACE (Xiaomi)

・CoreML (Apple)

・TensorFlow Lite (Google)

・MNN (Alibaba)

での、MobileNet-v1、SqueezeNet-v1.1、ResNet-19 でのCPUとGPUでの推論時間の比較をやっています。

これを見ると、MNN が速いというより、TensorFlow Lite がめっちゃ遅いのが分かります。CPU実行では、特にAndroidのMate 20 (Huawei) とMI6 (Xiaomi)。GPU実行では、TensorFlowのGPUは、OpenGL ES。

 

TensorFlow Lite。TensorFlowからサクッと持っていけて便利だけど、CPUもGPUも速くない。何故？遅いのだろうか。。。

 

MLIRベースのTensorFlow Runtime？

@Vengineerの戯言 : Twitter

SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

 このツイートで知った「TensorFlow Runtimeを再構築」

 ここに、MLIR Open Design Meeting March 19, 2020 でのスライドとビデオがアップされています。

TensorFlow DEV SUMMIT 2020 のビデオもありますね。

www.youtube.com

 

スライドでは、Host Runtime でのお話と BEF Executor (BEF Binary Executo Format) について書いてありまっす。

Page.16 に、

Host Program
  • Designed for low-level dispatch efficiency

とあり、low-level をと。

Graph Compilerによって、Graph を MLIR に変換し、その後、BEF に変換。一旦、BEF を Storage において、BEF Executor が Storage から取り出し、実行するというもの。

Page.22 に、

  • Low overhead: execute program by reading mmap’d byte array
  • Persistent and stable: Compile once offline, run many times online. Great for inference use-cases

とあります。

Page.23 に、

BEFExecutor
Key concepts:

  • BEF: dataflow graph
  • Kernel: dataflow node
  • AsyncValue: dataflow edge

 ともあります。

これに対して、「Devicde Runtime for Graph Execution」ということで、GPU Runtime をどうするかも説明しています。

Page.29に、CUDA in TFRT: Kernel Execution のコードがあります。以下、引用です。

// Allocate a buffer and make a GPU tensor
%b1 = crt.mem.alloc %stream %size %align
%t2 = crt.make_tensor %b1 %shape
// Launch some kernels. %t1 has some data on GPU. %ch0 is a chain
%ch1 = crt.launch %stream <sigmoid> %t1 %t2 %ch0 // t2 = sigmoid(t1)
%ch2 = crt.launch %stream <sqrt> %t2 %t2 %ch1 // t2 = sqrt(t2)
// Allocate pinned host memory, copy, and print
%hb = crt.mem.host_alloc %size %align
%ch3 = crt.mem.copy_dtoh %stream %t2 %hb %ch2
%ch4 = crt.mem.free %t2 %ch3 // can free immediately after launching
%ev = crt.event.create %flags
%ch5 = crt.event.record %stream %ev %ch4
%ch6 = crt.event.poll %ev %ch5 // %ch completes when event is reached
hex.print %hb2 %ch6

なんだか、CUDAのHost側のプログラムそのものっぽいですね。

次が (Page.30～37)が、「TFRT End-to-End Inference Workflow」

Mainstream CPU (Xeon Gold 6154) and GPU (NVIDIA TITAN V)、

CUDA 10.1, CuDNN 7.6.4, GPU driver 430.34

環境にて、ResNet-50 v1.5 (FP16 mixed precsion) の batch size =1, NHWC(1, 224,224,3)での推論時間は、現在のRuntimeに比べて、28％も速い( 3/4 になったと)

 

Page.38～の「Next Steps and Selected Challenges」では、「TFRT mobile support」があります。

Selected opportunities and challenges

  • On-device compiler with small binary size
  • AOC and interpreter modes
  • Running op scheduling that balances performance and power concerns

TensorFlowのgithub を眺めてみたら、

tfrt という キーワードがちらほら出てきています。たとえば、このファイル (tflite_api_dispatcher/BUILD) 。まだ、ファイルは無いのですが、BUILDファイルにいろいろありまっす。

cc_library(
    name = "tflite_api_dispatcher_with_kernels",
    hdrs = ["tflite_api_dispatcher.h"],
    deps = [
        ":tflite_api_dispatcher",
        "//tensorflow/lite:framework_lib",
    ] + tflite_experimental_runtime_linkopts(
        if_eager = [
            # "//tensorflow/lite/experimental/tf_runtime/opdef:tflrt_opdefs",
            # "//tensorflow/lite/experimental/tf_runtime/tfrt_ops:tfrt_tflite_ops_alwayslink",
    ],
        if_non_eager = [
            # "//tensorflow/lite/experimental/tf_runtime/tfrt_kernels:tfrt_tflite_interpreter_alwayslink",
            # "//third_party/tf_runtime:basic_kernels_alwayslink",
        ],
    ),
)

 EAGERモード と Graphモードがありますね。このファイル (tflite_api_dispathcer.h) によると、Graph モードの時のみ、BEFModel を使うみたいですね。

#elif TFLITE_EXPERIMENTAL_RUNTIME_NON_EAGER
using Interpreter = tflrt::TfLiteInterpreterAPI;
using InterpreterBuilder = tflrt::TfLiteInterpreterBuilderAPI;
using TfLiteModel = tflrt::BEFModel;
using TfLiteVerifier = tflrt::TfLiteVerifier;

 

Windows で、WSL(Ubuntu)、VSCode、Windows Terminal

@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

 

お仕事的には、Ubuntu があればいいんだけど、Ubuntu が入っているノートPCが売っていないので、Ubuntu をインストールしないといけない。Wifiのドライバ等を考えると結構面倒なのでやりたくない。。

しかしながら、Windows 10には、WSL (Windows Subsystem for Linux) がリリースされ、WSL にて Ubuntu が利用できるようになり、これでいいじゃんと思っています。

WSL + X Server を使えば、XEmacs も動くのでまたまたいいんじゃんと思っていましたが、お仕事で コードをいっぱい書くようになり、Visual Studio Code (VSCode) を入れて、キーバインドをEmacsにしたら、なかなか良かった。マウスを使って矩形領域を選択できるようになったので、コード変更の生産性も一気に上がりました。

VSCodeのShellにWSLのbashを割り当てれば、そのままUbuntu上で作業ができるものポイントです。

WSL(Ubuntu)のコンソールを使っていましたが、Windows TerminalでもVSCodeと同じようにマウスで矩形領域を指定できるようになったので、追加。。。

 

ということで、あたしのおしごととお仕事の両方のノートPCには、

・WSL (Ubuntu)

・VSCode

・Windows Terminal

を入れて、いろいろな作業をしています。。。

 

かなり、快適になりました。。。

 

 

OKR本を読んだ。。。

@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

 

OKR本を読んだ。これ。

www.amazon.co.jp

OKR本、いろいろあるみたいだけど、
OKRを広めたのはこの本の著者のジョン・ドーア さん。

買おうと思って、Amazonギフトカードを買って、次の日見たら、Kindle版半額の990円。超ラッキー。。。ということで、この本を読んでいる途中で紹介されていたアンディー・グローブの「HIGH OUTPUT PERFORMACE」も半額だったのでぽちった。

 

OKRについては、Googleのこのサイトに書いてあります。

rework.withgoogle.com

 

OKRとは、目標 (Objectives) と 主要な結果 (Key Results) のこと。

あれ、ドラッカーの目標管理と同じじゃんと思っていたら、10％ぐらい読んだら出てきたよ「ドラッカー」

 そうそう、ここで「HIGH OUTPUT MANAGEMENT」をぽちった。

 

ドラッカーの目標管理は、Management By Objectives and Self-Control なんだけど、日本語になった時に何故か？最後の「Self-Control」が無くなっちゃって、ノルマっぽくなってしまったのよね。

昔、富士通が導入して、残念な結果になりやめちゃった、あの「目標管理」。ドラッカーの「目標管理」はあくまでも自己管理なので、ノルマっぽいのはダメなんだけどね。

 

で、じゃー、OKR と ドラッカーの目標管理の違いはなんだろうと思いながら、読み進めたわけですよ。。。

で、何となくわかったのは、

1)、OKR の O を達成できる割合が70％ぐらいの目標にする

2)、その目標を達成するために、3～5個の KR を数値を入れたものにする

3)、OKR を全社員でシェアし、お互い助け合う

というのが、あたしの感想。

 

ドラッカーの目標管理はこのうち、1)と2)を自己管理でやるということ。

ということで、3)の全社員でシェアし、お互いに助け合うというのが、OKR のポイントだと思う。

(昔、同じようなことを職場で提案して、各自のやっていることをシェアすることまでできたが、あくまでもやっていることであって、OKR全体で無かったのでお互いに助け合うというのが出てこなかったんだなー。と)

お互い助け合うので、O と KR をキチンとしないと、助け合うにもできない。。

 

一般的な「目標管理」は評価に直結するけど、OKRは評価には使わない。

(じゃー、どうやって評価するのかまでは、かかれていなかった。。。)

評価に使われるのなら、確実にやれる O と KR を決めちゃうよね。

評価に使われないのなら、100％できそうもないけど、もしかしたら、できるかもしれない「ストレッチ目標」(これを「ストレッチOKR」呼ぶ)も可能だね。。。

 

それからもう一つ。。。Googleのサイトには書いてなかったのが、「コミットメントOKR」。こちらは「ストレッチOKR」と違って70％ではなく、100％が目標。。できないとダメなもの。。。こちらは一般的な「目標管理」と同じ感じかな。。。

 

最後に、OKR本に書いてあった「マズローの欲求5段階説」の最上位の「自己実現」。

自己実現を目指してやるような感じ。。じゃー、自己実現できちゃったらどうなる？どうするのって？思ったんだけど、あるんだよね。その先が。。。このブログの後半にかきましたので、読んでくださいね。

vengineer.hatenablog.com

Intel から oneAPI のソースコードがちらほら？

@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

IntelのoneAPIのソースコードが公開され始めました。

現時点では、次の2点

  • oneAPI Specification source files
  • oneAPI Level Zero Specification Headers and Loader

github.com

ここに ロードマップ がありますね。現在は、0.6 っぽい。

Intel(R) Graphics Compute Runtime for oneAPI Level Zero and OpenCL(TM) Driver

github.com


Interlaken Chip-to-Chip Interface

@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

確か、Xilinx か Altera の IP で知った、Interlaken Chip-to-Chip Interface。

その、Interlaken Chip-to-Chip Interface を SiFive がサポート？

www.chipestimate.com

サポートするのは、次の3つのタイプ。

  • Interlaken-1200
  • Interlaken-1000
  • Interlaken-600  

1.2Tbps の場合は、24 lanes x 56G SerDes または 48 lanes x 25G SerDes

ユーザー側のインターフェースは、128-bit or 256-bit 

128-bit で最大150Gbps、256-bit で最大100Gbps

8 x 256-bit で 1.2 Tbps 

 

24 lanes / 48 lanes の SerDes って、結構シリコン面積食いそう。

SiFiveのKamiって？

@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった 

記録のために

 github

github.com

The RiscvSpecKami package provides SiFive's RISC-V processor model.

github.com

プレゼンテーション資料

Using Kami in the field - experiences integrating Kami into SiFive's Chisel/
Scala-based design flow

Introducing Scalable New Core IP for Mission Critical Use

 

このプレゼン資料の発表者、Formal Method の研究者っぽい(MITで)

 

www.sifive.com