公開日：2025/11/01

36th Season

#36-9　Blocklyの実行速度は？

　今回は、Blocklyを使って開発したプログラムの実行速度面に着目した実験がテーマです。

Blockly

　Blocklyは、Google社が提供する、グラフィカルにブロックを組み上げることでプログラムを開発できる、ビジュアルプログラミング開発環境です。

　見た目からして、「子供向け👦👧の教育用開発環境だな」、等と勘違いしてしまいますが、いざ使って見ると、ブロックを使ったプログラム開発は楽しいのです。本HPにてArduinoで作成している程度の、ちょっとしたプログラムであれば充分に実用的な開発環境として使うことができます。

　すごくお気に入りです^ｗ（１＾−＾）^ｗ。

　何しろ、自作オリジナル16ビットCPUコアMoscoviumの開発環境としてBlocklyを採用してしまった程です(下図)。




　Googleが提供する「Blocklyデモ」と言う環境には、JavaScriptやPython等、スクリプト系の言語に変換する機能が搭載されています。スクリプト系言語の多くは「インタープリタ(通訳)」と呼ばれる実行形態です。毎回、ソースリストを読み込んで解釈しては実行して行くため、一般に実行速度が遅いという特徴があります。
　中には、仮想マシンの中間コードにコンパイルして実行する物もありますが、こちらも仮想マシンのエミュレータなので、実行速度としては似たり寄ったりです。

Blocklyを採用した開発環境

　Blocklyを採用した開発環境は沢山あり、本HPでも以下の様な開発環境を使ってきました。

• UIFlow
• Blockly for Moscovium
• PICAXE

　PICAXEへの興味は失っている(※)ので、今回比較するのは、UIFlowとBlockly for Moscoviumの2つです。

※あぁ、興味を無くしたのは、Blocklyに対して、ではなく、PICと言うマイコンに対して、です。

UIFlow

　UIFlowは、M5StickC Plusの開発環境の一つです。
　恐らく、M5StickC Plus上でPython処理系を実行しており、UIFlowが変換したPythonソースリスト(または中間コード？)をM5StickC Plusへダウンロードして実行している物と推察します。恐らく、インタープリタ方式ですね。
　とは言え、M5StickC Plusのマイコンは、あのESP32 @240MHzです。Arduino DUE(Cortex-M3 @84MHz)と比較したベンチマークでは、圧倒的な処理速度を示していました。

Blockly for Moscovium

　我がオリジナル16ビットCPUコアMoscoviumの開発環境であるBlockly for Moscoviumは、コンパイラ方式を採用しています。Blocklyが出力したXML形式のソースリストを読み込んで、Moscoviumのアセンブラへ変換する、Blockly.XML→Moscovium.ASM変換スクリプトを有しています。
　プログラムの実行はMoscoviumのネイティブ機械語なので、高速に実行できるのが特徴です。

　と言っても、こちらは自作のオリジナルCPUである、Moscovium @24MHzです。Blockly for Moscoviumも、コンパイラ方式ではあるのですが、出力するコードは最適化されていません。

• UIFlow：
• インタープリタ方式だけど、ESP32 @240MHzのハードウェア性能。
• Blockly for Moscovium：
• コンパイラ方式だけど、Moscovium @24MHzのハードウェア性能。

　どっちが速いの？って言う比較実験をしてみましょう。

実行速度の比較

　実行速度の比較に用いるプログラムは、マンデルブロ集合の計算とします。マンデルブロ集合の計算アルゴリズムに関しては、過去解説済みですので、こちらの記事をご参照ください。

プログラム

　32ビット単精度浮動小数を使うので、オリジナル32ビットCPUコアNihonium用のプログラムとします。以下にリンクしておきます。

　　Blockly for Moscovium版：mandelbrot.bxml

　Blockly for MoscoviumのXMLタブに貼り付けて、ご利用ください。

　個人的には、こちらの方が本命なので、フルセットの機能を有しています。コンパイルしてMoscoviumマイコンに書き込むと、シリアルモニタから以下のコマンドを受け付けています。

　　シリアルモニタコマンド仕様：

• mdbr[,<center_r>,<center_i>,<size_r>[/<fixed_point>]]
• マンデルブロ集合を描画します。
• 描画するマンデルブロ集合の範囲を、中心座標(<center_r>，<center_i>)、大きさ(＝幅＝高さ)<size_r>とします。
• 実数成分＝<center_r>、虚数成分＝<center_i>です。
• 省略時は、<center_r>＝−700、<center_i>＝0、<size_r>＝3,000で描画します。
• 引数は全て整数ですが、通常、マンデルブロ集合の座標値は浮動小数です。
• そこで、<fixed_point>引数によって、分母を指定可能です。
• 例）<center_r>＝765、<fixed_point>＝1,000とした場合
• 浮動小数＝<center_r>÷<fixed_point>＝765÷1,000＝0.765となります。
• <fixed_point>は、全ての引数に共通な分母となります。
• 省略すると、<fixed_point>＝1,000と見なします。
• cond[,<n_iteration>,<n_infinite>]
• マンデルブロ集合の計算条件を指定します。
• <n_iteration>：　繰り返し回数です。
• <n_iteration>→大とすると、解像度→高、色→緑色→赤色と、なります。
• <n_iteration>→小とすると、解像度→低、色→青色→紫色と、なります。
• 基本的に、マンデルブロ集合の細部にズームアップして行くと、より高い解像度が必要となるため、<n_iteration>→大が求められます。
• と言って、大きければ良いかと言うと、そうでもありません。
• 完成画像が一番美しく見える様に、
• あるいは、全体の色合いを見ながら、
• 調整して見てください。
• <n_infinite>：
• <n_iteration>回の計算後、ベクタの大きさが<n_infinite>を超えると、「無限大に発散した」と見なします。
• 通常は<n_infinite>＝100程度で充分な気がしますが、場合によって調整可能としてあります。
• 引数を省略すると、現在の設定値を表示します。
• ただし、<n_infinite>は、二乗した単精度浮動小数のバイナリ値(32ビット16進数)で表示します。
• save
• 描画したマンデルブロ集合のデータをシリアルモニタ経由で吸い上げるコマンドです。
• 吸い上げたデータの形式は以下の通りです。
• BGR565,<size_h>,<size_v>
  <pixel_bgr565_hex4>
  　：
  END
  
• ヘッダBGR565で始まり、フッタENDで終わります。
• <size_h>×<size_v>[ドット]が、吸い上げる画像データの大きさです。
• BGR565〜ENDの間に、ピクセル値(16ビット16進数、4桁)が続きます。
• 画像左上座標(0，0)から始まって、
• 右横方向へスキャンしながら、右端に到達したら、
• 一行下の左端に移動します。
• この繰り返しで、画像右下座標まで、
• (<size_h>×<size_v>)個のデータが送信されます。
• Tera Term等、受信データのログを記録可能な通信ソフトウェアで読み込んだデータは、以下のスクリプトによってPC上で閲覧可能となります。
• 描画スクリプト：draw_packed_pixel.olv
• ※スクリプト(.olv)を実行するには拙作Olive+をWindowsにインストールしてください。
• sleep
• デュアルコア版Moscoviumマイコンを使う場合、サブCPU2の停止／稼働をトグルするコマンドです。
• シングルコア版で実行した場合、本コマンドは機能しません。
• サブCPU2が稼働状態の場合、2個のCPUに分散してマンデルブロ集合を計算するため、理論上は×2倍速で計算可能です。
• cls
• SPI-TFT画面をクリアするコマンドです。
• who
• help

　続いて、比較対象のUIFlow版プログラムを以下にリンクします。

　　UIFlow版：mandelbrot.m5f

　こちらは、処理速度比較用のサブセット版です。サブセットの理由は以下の通りです。

• 中華製のM5StickC Plus＋UIFlowは、何しろバグが多いです。
• コーディングしていてバグにぶち当たる度、回避して回るのが不愉快極まりありません。
• なので、フルセットのコーディングは、鼻から興味がありませんでした。

　実行速度の比較ができる、最低限のコーディングに留めてあります。

処理速度比較実験

　まずは、Moscoviumマイコンの装置を組み立ててみましょう。
　32ビットNihoniumコア、単精度浮動小数演算ユニットS-FPU、SPI-TFT制御ユニット等が必要で、かつ、デュアルコア版が望ましいので、マイコンとしてはNHOC113DB9808を使います。Cmod A7ボード等、XilinxのFPGAに書き込むのに必要な、Moscoviumマイコンの設計データ(Vivadoのプロジェクトファイル一式を含む)はGitHubで提供しています。以下バナーよりアクセスしてください。



　デザイン(回路)をCmod A7ボード(FPGA)に書き込む手順については、こちらをご確認ください。

　以下に実験中の様子を示します。




　実験サンプルに従って実験してみましょう。

　　実験サンプル：【 】内はシリアルモニタからの送信データ
　　【cond,32,100】
　　OK: cond 32, 0x461c4000

　　【mdbr,-500,0,2000】
　　OK+ start calculation
　　OK+ send any serial data to stop
　　OK+ CPU1:CPU2 = 64:64
　　OK: mdbr 1913[ms]

　上に示したデュアルコア版での実行結果より、画像サイズ128×128[ドット]の計算時間は1.913sでした。デュアルコアのメインCPU1とサブCPU2が、仲良く64ラインずつ分け合って計算した事が報告されています。尚、シングルコア版では3.680sかかった事を申し添えておきます。
　こちらの記事「#16-1　見せてもらおうか、Xtensa LX6コアの性能とやらを」でArduino DUEとESP32ボード用に作成したC言語版マンデルブロ集合計算ソフトウェア(mandelbrot.ino)と同等な範囲を同等な条件で描画しました(下図)。



　過去記事で計測したDUEおよびESP32の計算時間を含めて以下表にまとめ、考察してみましょう。

　　考察：

• Nihoniumは、128×128[ドット]の計測時間を、240×240[ドット]に換算した時間とした。
• DUEおよびESP32の結果と比較できるよう、同じ条件(画像サイズ)に換算した計算時間を使った。
• CPU動作周波数に優位があるので、やはり、ESP32 @240MHzが圧倒的に速い。
• Nihonium @24MHzがDUE @84MHzより高速な点に関しては、計測ミスではない。
• Nihoniumには浮動小数演算ユニットS-FPUを搭載したため、浮動小数演算が高速化されている。
• 84MHz：24MHzの周波数差をひっくり返して、Nihonium＋S-FPUの方が高速だった(ちょろいな、Thumb-ARM)。
• マンデルブロ集合の計算は浮動小数演算が支配的なので、FPU(ハードウェア)の有り／無しがそのまま結果に反映された。
• Nihonium @24MHzシングルコアとESP32 @240MHzシングルコアで比較すると、
• 12.94s÷1.95s≒×6.64倍速。
• CPU動作周波数差240MHz÷24MHz＝×10倍速程の差は付いていない(ちょろいなESP32)。
• ESP32の優位は、@240MHzと言うCPU動作周波数でごり押しした結果とも考えられる。

　CPU動作周波数の不利(ハンディキャップ)を乗り越えて、結構良い線行っているではないか、我がNihonium＋Blockly for Moscoviumは！

Blockly処理系の比較実験

　引き続き、M5StickC Plus＋UIFlowで実験装置を構築して行きます。
　M5StickC PlusでUIFlow環境を構築する方法に関しては、こちらの記事をご確認ください。立ち上げが済んだら、UIFlowでこちらのプログラムを読み込み、実行するだけです。

　今回の主題は「Blocklyの実行速度」ですから、UIFlowとBlockly for Moscoviumで、詳細に比較してみたいと思います。まずは、最初の実験と同様、Moscovium版でデータを取得します。

　　実験サンプル：【 】内はシリアルモニタからの送信データ
　　【cond,120,100】
　　OK: cond 120, 0x461c4000

　　【mdbr,-700,0,3000】
　　OK+ start calculation
　　OK+ send any serial data to stop
　　OK+ CPU1:CPU2 = 64:64
　　OK: mdbr 2413[ms]

　下図の様な画像が描画されたはずです。



　マンデルブロ集合として、よく見かける代表的な画像ですね。

• 黒い部分が、有限値に収束した領域です。
• N次の漸化式まで計算しても閾値を超えなかった領域なので、
• 実は一番計算時間を要する領域です。
• Nは【cond】コマンドの<n_iteration>です。
• 色の付いた部分は、無限大に発散した領域です。
• N次の漸化式を計算する途中のk次(0＜k＜N)で閾値を超えた領域です。
• kの値に応じて色が変化する様にして描画するので、カラフルな画像となります。

　上の実行結果はデュアルコア版の計算でした。シングルコアで計算させるため、【sleep】コマンドでサブCPU2を停止(スリープ)させてみましょう。

　　【sleep】
　　OK: CPU2: sleep=1

　　【mdbr,-700,0,3000】
　　OK+ start calculation
　　OK+ send any serial data to stop
　　OK+ CPU1:CPU2 = 128:0
　　OK: mdbr 4698[ms]

　処理時間を比較して見ると、デュアルコア：シングルコア＝2.413s：4.698sということで、デュアルコアの方が約×1.95倍速と言う結果です。理論値は×2.0倍ですので、少し届きませんが、満足な結果ではあります。円周率πの計算では、もう少しオーバヘッドが大きくて、約×1.78倍速止まりでしたから……。


　さて、漸く登場するM5StickC Plusのプログラムでも、同等な範囲を計算するような初期値が設定してあります。もし、条件や座標値を変更したい場合、UIFlowのエディタで以下の部分を変更してから実行してください。

• mdbr_size：　画像サイズ[ドット](M5StickC Plusでは、〜135まで設定可能)。
• mdbr_nitr：　繰り返し回数、【cond】コマンドの<n_iteration>に相当。
• mdbr_ninf：　無限大発散判定値、【cond】コマンドの<n_infinite>に相当。
• (posr，posi)：　中心座標、【mdbr】コマンドの(<center_r>，<center_i>)に相当。
• sizr：　大きさ(＝幅＝高さ)、【mdbr】コマンドの<size_r>に相当。
• posr，posi，sizrは、浮動小数で設定可能。

　実行すると、M5StickC PlusのTFTディスプレイにも画像が描画されます(下図)。



　上写真の通り、UIFlowでの描画時間は76.639sでした。計測した描画時間を以下表にまとめ、考察を続けます。

　　考察：

• 直接比較可能な様に、双方とも、条件や画像サイズ(128×128[ドット])を揃えてある。
• 主題であるBlocklyの実行速度に注目して見ると、
• UIFlowとBlockly for Moscoviumの実行速度は、
• 実動作周波数での比較でも、圧倒的にBlockly for Moscoviumの方が速い。
• インタープリタ方式って、こんなに遅いのか。
• @240MHzのESP32が、見る影もない。
• @24MHzのNihoniumが圧倒的に高速だった。
• シングルコアでも小指で押しつぶしてる様な感じ。
• 通常は、CPU動作周波数差のハンデを除去するため、「1MHz換算」で比較するのだけど、必要なし。
• Blockly for Moscoviumのコンパイラ方式(ただし最適化なし)が、
• UIFlowのPython処理系(インタープリタ方式)を、
• 24MHz：240MHzの圧倒的なCPU動作周波数差をひっくり返して、逆に圧倒。
• インタープリタ方式に対して、×10倍のCPU動作周波数差は、ハンデにもならなかった。
• デュアルコア
• UIFlowでは、ESP32 @240MHzのデュアルコアが活用できない。
• UIFlowがデュアルコアに対応していないため。
• ただのシングルコアCPUに成り果てている。
• 勿体ない。
• ※そもそも、Pythonというインタープリタ方式の処理系を採用した時点で、「勿体ない」事になっている。ここにデュアルコア対応したところで、高が知れていると言われれば、その通り。
• Blockly for Moscoviumでは、4.698s÷2.413s＝約×1.95倍速が確認できた。
• デュアルコアなのに×2.0倍に足りないのは、セマフォによる資源管理で、SPI-TFTへの描画が排他制御となっている関係で待ち時間が発生するため。
• SPI-TFTなどの共有リソースにアクセスしないよう、RAM上に計算データを保持するようなプログラムにすると、オーバヘッドを縮小可能。→ ×2.0倍速に漸近する。
• と言っても、×1.95倍速なら充分に合格点。
• これ以上を望んでも大した効果は得られないと推察。
• だって理論上、×2.0倍速が上限なんだから。

　さすがのESP32 @240MHzも、インタープリタ方式のPython処理系では、性能が引き出せない様ですね。UIFlowで少し凝ったプログラムを作った時、処理速度不足で、まともに動作できなかった経験が複数回在りました。こうしてデータで見てみると、「さもありなん」と言う感じです。

　バグだらけで不愉快なUIFlowを我慢して使って来た理由は、

• １）Blocklyでの開発が楽しいから。
• ２）Arduino環境(C言語)に比べて、気軽にプログラミングできるから。

等でした。
　１）楽しいBlocklyでの開発は、Moscoviumマイコンで心行くまで堪能できる様になったのだから、バグだらけのUIFlow(Blockly)を我慢して使う価値は無くなりました。これで心おきなく、UIFlowとは決別できそうです。
　M5StickC Plusの@240MHz＆デュアルコアは、Arduino開発環境で活用しないと勿体ないですしね。


　とか何とか言いつつも、UIFlowを使う理由２）は残っているので、まあ、本当に簡単なプログラムの場合は、今後もUIFlowを使う場合があるかも……(弱腰)。