ついにDT+TraceもPython対応します。
リリースはもう少し先になりますが、なぜDT+TraceがPython対応に踏み切ったのか、DT+TraceはどうPythonに向き合おうとしているのか、開発秘話を交えながらご紹介していきたいと思います。
Pythonと組み込み開発
Pythonが流行っています。自分の使える開発言語でその人の年収がわかるといった記事もよく見かけます。その中でもPythonはここ数年ずっと上位ランクにいます。それだけ人気があるとも言えますが、Pythonを使えるデータサイエンティストの年収が大きく影響していることは容易に想像できます。みなさんご存知のように、PythonにはAIやAIを使ったビッグデータ解析に使用されるライブラリ群が充実しています。その技術が最も必要とされる分野がデータサイエンスの分野であれば納得の結果ですね。
では、組み込み業界ではどうでしょう。弊社が取り扱う製品の性質上、どうしても組み込み業界に目が行ってしまいがちですが、ここ2,3年でPythonを扱った開発やツールが急激に増えているのを肌で感じます。特に、昨今のコロナ禍で展示規模が小さくなっている組み込み系の展示会でもPythonが動くボードの展示やPythonにまつわるツールの展示も確実に増えてきています。また、「2,3年前はR&Dレベル止まりだったものがようやく製品開発のプロジェクトとしてスタートしました」なんていう話も弊社のお客様から見聞きすることが多くなってきています。
組み込み開発が全てPythonに置き換わることはさすがにあり得ませんが、「Pythonでも動くもの」を作っている組み込み開発エンジニアのPythonシフトは明らかに進んでいます。
プロファイラの必要性
これまでも「Pythonは取っ付きやすいけどパフォーマンスが・・・」なんていうことがよく言われて来ました。同時にその疑念を払拭するように様々な用途に向けてライブラリの細分化も進み、パフォーマンスとしても十分使用に耐え得るレベルになっていと言う人も増えてきているように見えます。また、昨今Pythonが多く使われる開発現場では、Pythonのパフォーマンスのことを含めて考えたとしても、Pythonを使うことによるローコード化の方が最終的に得られるメリットの方が大きいとも言われています。
組み込み業界でもPythonが使われるようになってきたとしても、当然のようにPythonのパフォーマンス問題はつきまといます。確かに、組み込みの分野で扱われるPythonのライブラリでも一般的なものであれば使用に耐え得るレベルになってきています。
しかしながら、組み込み特有の多種多様なプラットフォームが存在する中で、自身のプラットフォームに合うライブラリが少なかったり、そもそもチップの性能やボードのスペックが低くPythonを十分に動作させられなかったりするケースもまだまだありそうです。
Pythonの性質上やむを得ないことではありますが、Pythonを使う以上はこれらの課題とうまく付き合っていく必要があります。そこで、重要になるのがプロファイラです。特に、どの処理にどれだけ時間が掛かっているかを計測できるプロファイラは開発者にとっては不可欠なはずです。
Pythonには標準で「cProfile」というプロファイラが付属しています。「cProfile」だけでなく多くのPythonのためのプロファイラは存在していますが、これらのプロファイラは純粋にPythonのコードだけをプロファイリングするものがほとんどです。Pythonより下層のネイティブで書かれたコードも同時にプロファイリングできるプロファイラはかなりニッチな存在になるはずです。
Pythonとネイティブコードとの同時プロファイリングの必要性
そこで、「DT+Trace」はこのニッチな領域に目をつけました。PythonのコードそのものとPythonより下層のネイティブで書かれたコードを同時にプロファイリングできるプロファイラです。もともと「DT+Trace」は汎用性をウリにしているのでPython対応することは自然な流れではあるのですが、開発者の課題を解決できて初めて「役に立つツール」と言えますので、「DT+Trace」は組み込み開発でPythonを使おうとしたとき開発者が抱えることになるであろう課題を以下のように想定しました。
ネイティブコードをPythonに置き換えるときの課題
実績のあるネイティブコードを丸々Pythonに置き換えるケースはレアケースですが、アプリ層もしくはGUI層でPythonのライブラリを使うために一部のネイティブコードをPythonに置き換えるケースは意外と多いはずです。 当然、ネイティブコードによる処理速度を取るか、Pythonによるメンテナンス性を取るかのトレードオフが発生します。 そのとき開発者は、置き換える前と後でのパフォーマンスや処理コストの違いを把握しジャッジしなければならず、その違いをどうやって把握するかが課題になるはずです。
レガシーコードをラッピングしたときの課題
先にも述べましたが、Pythonのライブラリの充実化が進んだ背景には、パフォーマンスの改善と併せていかに開発者の負担を減らすかという観点において改善が進められるという点があると考えています。これと同様に、組み込み業界特有のレガシーコードをラッピングしPython側からうまく扱えるようにしておくことができれば、実績のあるレガシーコードの活用とメンテナンス性の向上を両立でき、特にエンハンス開発への効果が大きいと考えています。しかしながら、これを実現するためには、開発者の適確なアーキテクト設計スキルは必須です。また、そのスキル以上に、ネイティブコード側とPython側の双方のコードが思惑通りに動いているかを把握するための手立てが必要になります。異なる言語であっても同時に動きがわかれば作業効率が断然上がりますので、シームレスな検証方法の確率やそれを実現するツール選定も開発者の課題になるはずです。
PythonとDT+Trace
前述のように、異なる言語体系のコードのパフォーマンス測定を一つのプロファイラで完結でき、かつ異なる言語どうしの動きを同時にトレースすることができれば、ツールとしても大きなアドバンテージが得られます。
そこで、「DT+Trace」では、今後新たな言語体系のコードや複雑化が進んだ言語にも柔軟に対応できるよう、コード解析エンジンを刷新しました。新しいコード解析エンジンは、独立したアプリケーション “DTxBuilder” として提供する予定です。
最後に
カメラから入力した画像データをAIを使って解析するとか、ディープラーニングさせて新たなデータを生み出すといったような、今となってはすでに完成された領域では、もしかしたら「DT+Trace」の出番は少ないかもしれません。
ですが、近年の組み込み開発において、レガシーコードのメンテナンス性を考慮して一部をPythonに置き換えるような動きが加速していることも事実です。
DT+Traceの進化は止まりません。
新しい「DT+Trace」が、Pythonでの組み込み開発を考えている開発者の方にとって、少しでもお役に立つのであれば幸いです。
リリース時の実際の仕様とは異なる場合がございますので、予めご了承ください。
なお、ご不明な点につきましては、弊社サポートチームまでお問い合わせください。
お問い合わせはこちら
動的テストの事例紹介ウェビナーやります！
組込み機器開発特有のソフトウェアデバッグ、テストにお困りではありませんか？
初期化処理や処理時間、複数CPUのシーケンス処理など、どのようにテストしていますか？
複数の機器で構成されたシステムでは、
「機器同士のやりとりを把握することができない」
「デバッガを使ってブレークをかけることができない」
といった問題にぶつかり、ソフトウェア内部の動きを把握することは困難です。
そこで今回は、動的テストツールDT+ユーザー様を講師にお迎えし、
このような課題に対する活用事例をご紹介させていただきます。
ぜひお気軽にご参加ください！
