18

RTOS プラットフォームに小規模なデータ収集システムを実装することを計画しています。(QNX または RT-Linux システムのいずれか)。

私の知る限り、これらのジョブは C / C++ を使用して実行され、システムを最大限に活用しています。しかし、コーディング作業にやみくもに飛び込む前に、経験豊富な人々の意見を知りたいと思っており、Python ですべてを書くことが実現可能で賢明であるかどうか (光沢のあるグラフィカル ユーザー インターフェイスを介した低レベルの計測器のインターフェイスから) を知りたいと思っています。そうでない場合は、デザインのタイミングが重要な部分を "C" で混在させるか、すべてを C で記述し、Python コードを 1 行も配置しません。

または、少なくとも Python を使用して C コードをラップし、システムへのアクセスを容易にします。

どのような方法で作業するようアドバイスしていただけますか? 似たようなデザインの事例や参考文献なども教えていただければ幸いです。

ありがとうございました

注 1: QNX を強調する理由は、大気測定実験用にQNX 4.25 ベースのデータ収集システム ( M300 ) が既にあるためです。これは独自のシステムであり、内部にアクセスすることはできません。6.4 には無料のアカデミック ライセンス オプションがあり、Python 2.5 と最近の GCC バージョンが付属しているため、QNX をさらに検討することは私たちにとって有利かもしれません。私は RT-Linux システムをテストしたことがなく、安定性と効率の点で QNX にどの程度匹敵するかはわかりませんが、Python の生息地と非 Python ツール (Google Earth など) のすべてのメンバーが新しいシステムを使用していることは知っています。ほとんどの場合、すぐに使用できる作品で開発できます。

4

5 に答える 5

24

私は、すべてが Python のソフト リアルタイム (RT) システムをいくつか構築しました。プライマリ サイクル タイムは 1 ミリ秒から 1 秒です。途中で学んだ基本的な戦略と戦術がいくつかあります。

  1. スレッド化/マルチプロセッシングは、非 RT 作業をプライマリ スレッドからオフロードする場合にのみ使用します。スレッド間のキューが許容され、協調スレッド化が可能です (プリエンプティブ スレッドはありません!)。

  2. GILを避けてください。これは基本的に、スレッド化を回避するだけでなく、システム コールを可能な限り回避することも意味します。

  3. 実用的な場合は C モジュールを使用してください。C を使用すると、(通常は) 処理が速くなります! ただし、主に自分で作成する必要がない場合: 本当に代替手段がない場合を除き、Python にとどまります。C モジュールのパフォーマンスを最適化することは PITA です。特に、Python-C インターフェイスでの変換がコードの最もコストのかかる部分になる場合はそうです。

  4. Python アクセラレータを使用してコードを高速化します。私の最初の RT Python プロジェクトは、Psyco から大きな恩恵を受けました (ええ、私はこれをしばらく行ってきました)。今日私が Python 2.x を使い続ける理由の 1 つは PyPyです。

  5. 重要なタイミングが必要なときは、ビジー状態になることを恐れないでください。time.sleep() を使用して目的の時刻に「忍び寄る」と、最後の 1 ～ 10 ミリ秒の間ビジー待機します。約 10 マイクロ秒のセルフタイミングで再現性のあるパフォーマンスを得ることができました。Python タスクが最大 OS 優先度で実行されていることを確認してください。

  6. ナンピー ROCKS! 「ライブ」分析や大量の統計を行っている場合、Numpyを使用するよりも少ない作業 (少ないコード、少ないバグ) で、より多くの作業をより迅速に行う方法はありません。C/C++ を含む、私が知っている他の言語ではありません。コードの大部分が Numpy 呼び出しで構成されている場合、非常に高速になります。Numpy から PyPy への移植が完了するのが待ちきれません!

  7. Python がガベージ コレクションを行う方法と時期に注意してください。メモリの使用状況を監視し、必要に応じて GC を強制します。タイムクリティカルな操作中は、GC を明示的に無効にしてください。私の RT Python システムはすべて継続的に実行され、Python はメモリを大量に消費するのが大好きです。注意深くコーディングすることで、ほとんどすべての動的メモリ割り当てをなくすことができます。その場合、GC を完全に無効にすることができます!

  8. 可能な限りバッチで処理を実行するようにしてください。入力レートでデータを処理する代わりに、出力レートでデータを処理してみてください。これは多くの場合、はるかに低速です。また、バッチで処理すると、より高レベルの統計を収集するのがより便利になります。

  9. PyPy の使用について言及しましたか? さて、それは 2 回言及する価値があります。

RT 開発に Python を使用することには、他にも多くの利点があります。たとえば、ターゲット言語が Python ではないと確信している場合でも、Python でプロトタイプを開発およびデバッグし、それを最終的なシステムのテンプレートおよびテスト ツールの両方として使用すると、大きなメリットが得られます。私は何年もの間、Python を使用して、システムの「ハード パーツ」の簡単なプロトタイプを作成し、簡単なテスト GUI を作成していました。こうして、私の最初の RT Python システムが誕生しました。プロトタイプ (+Psyco) は、テスト GUI が実行されていても、十分に高速でした!

-ボブC

編集：クロスプラットフォームの利点について言及するのを忘れました：私のコードは、a）再コンパイル（またはコンパイラの依存関係、またはクロスコンパイラの必要性）がなく、b）プラットフォームに依存するコードがほとんどない（主にファイル処理とシリアル I/O)。私は Win7-x86 で開発し、Linux-ARM (またはその他の POSIX OS、最近ではすべて Python を使用しています) にデプロイできます。PyPy は現在のところ主に x86 ですが、ARM への移植は驚異的なペースで進化しています。

于 2013-02-21T20:52:00.080 に答える
15

そこにあるすべてのデータ取得セットアップについて話すことはできませんが、それらのほとんどは、データが来るのを待つ「リアルタイム操作」のほとんどを費やしています-少なくとも私が取り組んだもの.

次に、データが入ってきたら、すぐにイベントを記録するか、それに応答する必要があります。その後、待機中のゲームに戻ります。これは通常、データ取得システムの中で最もタイム クリティカルな部分です。そのため、データ取得の I/O 部分には C を使用するのが一般的だと思いますが、タイム クリティカルではない部分で Python を使用しないという特に説得力のある理由はありません。

要件がかなり緩い場合 (おそらくミリ秒単位の精度しか必要ない場合)、Python ですべてを実行することに重みが加わります。開発時間に関しては、すでに Python に慣れている場合は、Python ですべてを行い、ボトルネックが発生した場合にのみリファクタリングを行うと、完成品がかなり早く完成する可能性があります。大部分の作業を Python で行うと、コードを徹底的にテストすることも容易になります。一般的な経験則として、コードの行数が少なくなるため、バグが発生する余地が少なくなります。

特にマルチタスク(マルチスレッドではない)が必要な場合は、Stackless Pythonも有益かもしれません。マルチスレッドに似ていますが、スレッド (スタックレス用語ではタスクレット) は OS レベルのスレッドではなく、Python/アプリケーション レベルであるため、タスクレット間の切り替えのオーバーヘッドが大幅に削減されます。協調的またはプリエンプティブにマルチタスクを実行するようにスタックレスを構成できます。最大の欠点は、IO をブロックすると、通常、タスクレットのセット全体がブロックされることです。とにかく、QNX がすでにリアルタイム システムであることを考えると、Stackless を使用する価値があるかどうかを推測するのは困難です。

私の投票では、可能な限り Python を使用するルートを選択します。これは、低コストでメリットが大きいと考えています。C で書き直す必要がある場合は、作業を開始するためのコードが既に用意されています。

于 2009-09-10T02:17:38.703 に答える
7

一般に、リアルタイムコンテキストで高級言語を使用することに反対する理由は、不確実性です。ルーチンを1回実行すると、100usかかる場合があります。次に同じルーチンを実行すると、ハッシュテーブルを拡張してmallocを呼び出すことを決定する可能性があります。次に、mallocはカーネルにメモリの追加を要求します。これにより、即座に戻ることから数ミリ秒後に戻ること、数秒後にエラーが発生することまで、何もできません。コードからすぐに明らかになります（または制御可能になります）。理論的には、C（またはそれ以下）で書くと、クリティカルパスが「常に」（流星の攻撃を除いて）X時間で実行されることを証明できます。

于 2009-09-10T02:28:08.667 に答える
3

私たちのチームは、QNX で複数の言語を組み合わせるいくつかの作業を行い、このアプローチで多くの成功を収めました。Python を使用すると、生産性に大きな影響を与える可能性があり、SWIGや ctypes などのツールを使用すると、コードを最適化したり、さまざまな言語の機能を組み合わせたりすることが非常に簡単になります。

ただし、タイム クリティカルなものを作成する場合は、ほぼ確実に c で作成する必要があります。これを行うことは、GIL ( Global Interpreter Lock )のような解釈された言語の暗黙のコストと、多くの小さなメモリ割り当てでの競合を回避することを意味します。これらはどちらも、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。

また、QNX 上の python は、他のディストリビューションと 100% 互換性がない傾向があります (つまり、モジュールが欠落している場合があります)。

于 2009-09-10T02:16:02.980 に答える
0

1 つの重要な注意事項: Python for QNX は、通常、x86 でのみ使用できます。

ppc やその他のアーキテクチャ用にコンパイルできると確信していますが、そのままではうまくいきません。

于 2010-06-01T22:12:53.143 に答える