language-features - リアルタイムアプリケーションに使用する言語

Question

株式市場データを受信し、何らかの処理を行ってからクライアントアプリケーションに送信するリアルタイムアプリケーションを開発します。サーバーとクライアントの間で計算を分割することにしました。サーバーは基本的な計算を行い、最終的な変数を計算するクライアントに基本データを送信します。

C# を使用してクライアントアプリケーション (GUI のみ) を開発し、C++ を使用して最終的な変数 (変数計算機と呼ばれる) を計算するコンポーネントを開発することにしました。C ++で「変数計算機」を開発する目的は、モジュール性です。たとえば、クライアント側で変数の計算に時間がかかることがわかった場合は、サーバー側で同じモジュールを使用できます。

また、標準の C++ を使用してサーバーサイドを開発します。

注: サーバーは一連のメッセージを処理し、それを 1 秒以内にクライアントに送信する必要があります市場の開始時に最大数のメッセージが送信されます 100,000 メッセージ

助言がありますか？

score 6 · Accepted Answer

私は「リアルタイム」が曖昧な定義であることに同意しません。多くの場合、人々は意味を理解していません。リアルタイムとは、システムの応答時間が実際のシステムと同じであることを指します。実際には、システムをリアルタイムよりも高速にすることができ、システムをリアルタイムよりも遅くするのと同様の問題が発生します。

そのため、本当に高速なアプリケーションと同様に、「リアルタイム」アプリケーションを参照して言語の使用を求めているとは思いません。

言語のシュートアウトをチェックして、デザインスペースに最も近い種類のテストで何が最も効果的かを確認してください。しかし、私の直感的な答えはCを使用することです。

score 6 · Accepted Answer

投資銀行で30年近く働いてきました。私はこのような多くのアプリケーションを作成しました。解決する必要のある根本的な問題は、おそらくリアルタイムのパフォーマンスではなく、遅延とスループットです。

このコンテキストでの遅延は、ネットワーク遅延の削減に関するものであり、言語の選択はあまり重要ではありません。

スループットとは、長期間にわたって持続する大きな処理能力に関するものですが、パフォーマンスとは、短期間の非常に大きな処理能力に関するものです。このコンテキストでの言語の選択はレイテンシーよりも重要ですが、通常は思ったほど重要ではありません。

2つのうち、通常は、最初に可能な限り最小のレイテンシーを設計することをお勧めします。スループットの問題は、開発の後半でさまざまなトリックによって解決できますが、既存の設計に組み込まれている高遅延を取り除くことははるかに困難です。

したがって、少なくとも概念実証のために、クライアントとサーバーの両方でC＃を使用します。重要ではない可能性が高い問題を解決するために、追加の複雑さ（別の言語）を導入する必要はありません。

編集：サーバーが1秒以内に最大100Kのメッセージを処理する必要があるという質問を編集したことに気づきました。ソフトウェアでこれを実現できるかどうかは疑問ですが、ソフトウェアとハードウェアを組み合わせて使用することで実現できる可能性があります。

このレベルの低レイテンシーが本当に必要な場合（そして私がビジネスで30年間必要としたことはありません）、言語の選択は、超最適化および並列化された非常に高い帯域幅を持つことほど重要ではありませんアルゴリズム。しかし、私は最初に、それらが実際に何を意味するのかを確認するための要件に疑問を投げかけます-それは彼らが言ったことではないに違いありません。

score 6 · Accepted Answer

作業しなければならないリアルタイムの制約は正確には何ですか？マイクロ秒、ミリ秒、秒？

それは実際にリアルタイムである必要がありますか、それとも単に高性能である必要がありますか？

本当にリアルタイムである必要があると仮定すると、言語がシステムで最も重要なものになる可能性は低く、ほとんどの場合、残りのランタイム環境によって制約を受ける可能性があります。例：使用するライブラリ、ネットワークスタック、ネットワークプロトコル、オペレーティングシステム、CPUアーキテクチャ、メモリ、キャッシュなど。

そうは言っても、Cはおそらく、使いやすさと基盤となるシステムが何をしているのかを知ることの最良の組み合わせを提供するでしょう。C ++をよく知っている場合は、厳密なコーディング標準で使用する場合にも適しています。パフォーマンスが非常に高い場合、または予測可能性の要件が非常に高い場合は、アセンブラコードにドロップする必要がありますが、これはほとんどありません。コンパイラは、CPUパイプラインをあなたよりもはるかによく理解している可能性があります。数千行を超えるコードには実用的ではありません。

もちろん、比較的高速なものが必要な場合は、言語の選択においてリアルタイム性を第一に考慮する必要はありません。適切なライブラリとツールの可用性、開発者チームの経験、アプリケーションへの適合性などを考慮してください。より重要な考慮事項になります。

score 3 · Accepted Answer

「リアルタイム」アプリケーションとは何かの定義は、最近かなり曖昧になっています。リアルタイムの制約は、アプリケーションによっては数マイクロ秒になる場合があり、言語、OS、およびツールの選択はすべてそれらに依存します。

この場合、サーバー側でもC＃を使用すべきではない理由がわかりません。あなたが言及していない制約があるかもしれませんが、あなたが言ったことから、あなたの問題に第二言語を導入する理由はわかりません。

score 2 · Accepted Answer

最近では、言語の選択imoは、大量の処理能力を必要としないクライアント/サーバーアプリケーションに関しては、使用するものほど重要ではありません。優れたアーキテクチャを構築する方法を知っている限り、Java、C＃、C / C ++も同様に機能します（明らかにネイティブ言語にはいくつかの利点があります）。使いやすさと各言語で利用できる便利なライブラリの量を考慮して決定を下します。あなたの計算が正確に何を必要としているのか、あなたが処理している株式情報は何なのかわかりませんが、ライブラリとGUI開発ツールを調べてそこから進んでください...

score 2 · Accepted Answer

Scala、Erlang、または Java。しかし、素晴らしい構文と高いスケーラビリティを備えた Scala を強くお勧めします。

score 1 · Accepted Answer

Erlangを調べてみます！それらのアーキテクチャは、このようなアプリケーションに最適のようです。

score 0 · Accepted Answer

C++で高性能サーバーを作成するためのポータブルサーバーフレームワークである AdaptiveCommunicationsEnvironmentを見ることができます。このStackoverflowの投稿には、それを説明し、さまざまなリソースにファンアウトする一連のリンクがあります。

score 0 · Accepted Answer

ダンの直感的な答えは間違っています。彼が投稿したサイトを見ると、今日のC ++（gnu / Intel実装）がC実装よりも優れていることが明らかです。

score 0 · Accepted Answer

私もそのようなシステムを実装しました.RoadWarriorは実際にそれを非常にうまくまとめていると思います.

これは、メッセージキューの優れたアプリケーション領域です。基礎となる優れた MQ テクノロジを活用すれば、ほぼすべてのプログラミング言語、さらには高レベルのインタープリター言語でスループット要件を満たすことができると思います。

score 0 · Accepted Answer

低レイテンシと高スループットが本当に必要な場合は、サーバー内のデータ処理 (計算) を削除することをお勧めします。クライアントではない計算を本当にしたい/する必要がある場合は、派生データの補完的なデータストリームを提供する別のサーバーをセットアップします。つまり、元の/生のフィードに基づいて計算された値です。

どのような種類の計算について話しているのですか?

ネットワークおよびネットワークスタックのスループットをどのように処理する予定ですか? レイテンシー測定ツール/スニファー/Endace カードはありますか?

language-features - リアルタイム アプリケーションに使用する言語

11 に答える 11

Related

Reference

language-features - リアルタイムアプリケーションに使用する言語