Какой язык я должен использовать для приложения в реальном времени - PullRequest
2 голосов
/ 29 декабря 2008

Я собираюсь разработать приложение в режиме реального времени, которое будет получать данные о фондовом рынке и выполнять некоторую обработку, а затем распространять в клиентское приложение. Я решил разделить вычисления между сервером и клиентом, сервер сделает основные вычисления, а затем отправит основные данные клиенту, который вычисляет окончательные переменные.

Я решил разработать клиентское приложение (только GUI) с использованием C # и компонента, который будет вычислять конечные переменные (называемый: калькулятор переменных) с использованием C ++. Целью разработки «Калькулятора переменных» на С ++ является модульность. например, если я обнаружил, что вычисления переменных займут больше времени на стороне клиента, я смогу использовать тот же модуль на стороне сервера.

Также я буду разрабатывать серверную часть, используя стандарт C ++.

Примечания: Сервер должен обработать набор сообщений и отправить его клиенту менее чем за одну секунду. Максимальное количество сообщений приходит в начале рынка 100 000 сообщений

Есть предложения?

Ответы [ 11 ]

7 голосов
/ 29 декабря 2008

С каким именно ограничением в реальном времени вам приходится работать? Микросекунды, миллисекунды, секунды?

Нужно ли работать в режиме реального времени или просто с высокой производительностью?

Предполагая, что он действительно должен быть в режиме реального времени, язык вряд ли будет самой важной вещью в системе, и вы, скорее всего, будете ограничены остальной средой выполнения. Например: используемые вами библиотеки, сетевые стеки, сетевые протоколы, операционная система, архитектура процессора, память, кэш и т. Д.

Все это говорит о том, что C, вероятно, даст вам наилучшее сочетание простоты использования и знания того, что делает базовая система. Если вы очень хорошо знаете C ++, то это также подойдет, если использовать его со строгим стандартом кодирования. Если он чрезвычайно высокопроизводителен или имеет чрезвычайно высокие требования к предсказуемости, вам может потребоваться перейти на ассемблерный код, но это маловероятно, и есть вероятность, что компилятор гораздо лучше понимает конвейер ЦП, чем вы, и он было бы непрактично для всего, что превышает несколько тысяч строк кода.

Если, конечно, если вам просто нужно что-то относительно быстрое, то я не думаю, что актуальность в режиме реального времени должна быть вашим главным соображением при выборе языка, а скорее в наличии подходящих библиотек и инструментов, опыта команды разработчиков, пригодности для применение и т. д. были бы более важными соображениями.

6 голосов
/ 29 декабря 2008

Проработав в инвестиционных банках почти 30 лет. Я написал много приложений, как это. Вероятно, основная проблема, которую вам необходимо решить, - это не производительность в реальном времени, а задержка и пропускная способность.

Задержка в этом контексте касается сокращения сетевых задержек, и выбор языка не очень важен.

Пропускная способность - это большая вычислительная мощность, поддерживаемая в течение длительных периодов времени, тогда как производительность - очень большая вычислительная мощность в течение коротких периодов времени. Хотя выбор языка в этом контексте важнее, чем с задержкой, он обычно не так критичен, как вы думаете.

Из этих двух обычно лучше сначала спроектировать с минимально возможной задержкой. Проблемы пропускной способности могут быть решены позже при разработке с помощью различных приемов, но избавиться от высокой задержки, запекшейся в существующей конструкции, гораздо сложнее.

Так что я хотел бы использовать C # как на клиенте, так и на сервере, по крайней мере, для проверки концепции. Нет необходимости вводить дополнительную сложность (другой язык) для решения проблемы, которая вряд ли будет важной.

РЕДАКТИРОВАТЬ : я заметил, что вы отредактировали свой вопрос, сказав, что серверу необходимо обрабатывать до 100 КБ сообщений не более чем за 1 секунду. Я сомневаюсь, что вы можете достичь этого с помощью программного обеспечения, но вы можете сделать это, используя комбинацию программного и аппаратного обеспечения .

Если вам действительно нужен этот уровень низкой задержки (а я никогда не нуждался в этом в течение 30 лет в бизнесе), то опять же выбор языка не так важен, как наличие очень высокой пропускной способности вместе с супер оптимизированный и распараллеленный алгоритм. Но я бы сначала поставил под сомнение требование увидеть, что они на самом деле значат - держу пари, что это не то, что они сказали.

6 голосов
/ 29 декабря 2008

Я не согласен с тем, что «в реальном времени» - размытое определение. Скорее всего, люди просто не понимают, что имеется в виду. Реальное время означает, что время отклика системы такое же, как в реальном мире. На самом деле система может работать быстрее, чем в режиме реального времени, вызывая проблемы, подобные тому, что система работает медленнее, чем в режиме реального времени.

Таким образом, я не верю, что вы запрашиваете использование языка применительно к приложению «в реальном времени», так же как и к действительно быстрому приложению.

Проверьте языковую перестрелку и посмотрите, что лучше всего подходит для тех типов тестов, которые наилучшим образом соответствуют вашему дизайну; тем не менее, мой внутренний ответ - использовать C.

3 голосов
/ 29 декабря 2008

В наши дни определение приложения в режиме реального времени довольно размыто. Ваши ограничения в реальном времени могут составлять микросекунды месяцев, в зависимости от приложения, и ваш выбор языка, ОС и инструментов будет зависеть от этих вещей.

В этом случае я не понимаю, почему вы не должны также использовать C # на стороне сервера. Возможно, есть ограничения, о которых вы не упомянули, но из того, что вы сказали, я не вижу смысла вводить второй язык в вашу проблему.

2 голосов
/ 08 октября 2011

Скала, Эрланг или Ява. Но я настоятельно рекомендую Scala за его приятный синтаксис и высокую масштабируемость.

2 голосов
/ 29 декабря 2008

В наши дни выбор языка imo не так важен, как тот, который он использует, когда речь идет о клиент-серверных приложениях, которые не требуют больших вычислительных ресурсов. Java, C #, C / C ++ будут работать аналогично (очевидно, что родные языки будут иметь некоторое преимущество), если вы знаете, как создавать хорошие архитектуры. Я бы принял во внимание простоту использования и количество полезных библиотек, доступных для каждого языка, чтобы принять моё решение. Я не знаю, что именно требуют ваши расчеты или какую информацию вы обрабатываете, но изучите библиотеки и инструменты разработки графического интерфейса и переходите оттуда ...

1 голос
/ 29 декабря 2008

Я бы посмотрел на Эрланга! Их архитектура идеально подходит для таких приложений.

0 голосов
/ 29 декабря 2008

Я также внедрил такую ​​систему, и я думаю, что RoadWarrior на самом деле очень хорошо ее обобщает.

Это потрясающая область применения для очередей сообщений, и если вы используете хорошую базовую технологию MQ, я полагаю, что вы могли бы удовлетворить ваши требования к пропускной способности практически на любом языке программирования, даже на языках высокого уровня.

0 голосов
/ 29 декабря 2008

Если вы действительно хотите низкую задержку и высокую пропускную способность, я предлагаю вам удалить любую обработку данных на сервере (вычисления). Если вы действительно хотите / должны выполнять вычисления не на клиенте, я бы настроил другой сервер, который обеспечивает дополнительный поток данных производных данных. То есть ваши расчетные значения основаны на исходном / необработанном фиде.

О каких расчетах вы говорите?

Как вы планируете обрабатывать пропускную способность в сети и в сетевом стеке? У вас есть инструменты измерения задержки / снифферы / карта Endace?

0 голосов
/ 29 декабря 2008

Внутренний ответ Дэна неправильный, если посмотреть на опубликованный им сайт, ясно, как в настоящее время C ++ (реализация GNU / Intel) опережает реализацию C

...