質問

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

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

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

どの方法で作業することを勧めますか?似たようなデザインのケースと、さらに読み物を教えていただければ嬉しいです。

ありがとう

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

役に立ちましたか?

解決

データ収集のセットアップについてはすべて話せませんが、ほとんどは「リアルタイム操作」のほとんどを費やしています。データが入るのを待っています-少なくとも私が取り組んできたもの。

データが到着すると、 イベントをすぐに記録するか、それに応答する必要があります。その後、待機中のゲームに戻ります。これは通常、データ収集システムの最も時間的に重要な部分です。そのため、データ取得のI / O部分についてはCに固執することを一般的にと言いますが、非タイムクリティカルな部分にPythonを使用しない特別な理由はありません。

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

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

私の投票は、可能な限りPythonに近いルートを取ることです。私はそれを低コストで高い利益と考えています。 Cで書き直す必要がある場合は、作業用のコードが既に用意されています。

他のヒント

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

  1. スレッド/マルチプロセッシングを使用して のみ 、プライマリスレッドからRT以外の作業をオフロードします。スレッド間のキューは許容可能であり、協調スレッドは可能です(プリエンプティブなしスレッド!)。

  2. GILを避けます。これは基本的に、スレッド化を回避するだけでなく、システムコールを可能な限り回避することを意味します。特に、タイムクリティカルな操作の場合は、ブロックされない限り、回避します。

  3. 実用的な場合はCモジュールを使用します。物事は(通常)Cで速くなります!ただし、主に独自のコードを記述する必要がない場合は、他に選択肢がない場合を除き、Pythonのままにしてください。 Cモジュールのパフォーマンスを最適化することは、特にPython-Cインターフェースを介した変換がコードの最も高価な部分になる場合、PITAです。

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

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

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

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

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

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

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

-BobC

編集:クロスプラットフォームの利点について言及するのを忘れました:私のコードはほとんどすべての場所で実行されます。a)再コンパイル(またはコンパイラの依存関係、またはクロスコンパイラの必要性)、およびb)プラットフォームに依存するコードはほとんどありません(主にファイル処理やシリアルI / Oなどのその他のもの)。 Win7-x86で開発し、Linux-ARM(または最近Pythonを搭載した他のPOSIX OS)にデプロイできます。 PyPyは現在のところ主にx86ですが、ARMポートは驚くべきペースで進化しています。

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

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

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

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

重要な注意事項:Python for QNXは一般にx86でのみ利用可能です。

ppcやその他のarch向けにコンパイルできると確信していますが、それはそのままでは機能しません。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top