VC ++ / Высокая производительность C++ Многопоточные соображения GUI для торговли

Я работал над графическим интерфейсом торгового приложения. В принципе, все, что локально (то есть не в Интернете), достаточно быстро. C ++, C # или Java подойдут. Главный недостаток использования C ++ заключается в том, что он устраняет естественный барьер между кодом расчета и пользовательским интерфейсом. Программисты до меня были немного небрежны, использовали C ++, и поэтому расчетный код и пользовательский интерфейс были несколько переплетены. Это усложнило перенос Qt.

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

Поскольку в комментарии вы упомянули проблему выбора C ++ или C #, я буду рекомендовать C # и особенно WPF (Windows Presentation Foundation). Теоретически приложение C ++ имеет более высокий потолок производительности, чем приложение .Net, поскольку у него нет накладных расходов на инфраструктуру .Net. Но это также займет больше времени на разработку (вероятно) и будет более подвержено ошибкам и утечкам памяти.

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

Вы ищете совершенно неправильные места. «Накладные расходы» архитектуры документа / представления находятся в наносекундном диапазоне (в основном, доступ к данным через указатель).

Для сравнения, абсолютная максимальная частота, с которой вы можете осмысленно обновлять экран, - это частота обновления монитора, которая обычно составляет 60 Гц (то есть один раз каждые 16,67 миллисекунды).

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

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

Edit: Что касается C ++ и C #, это зависит от обстоятельств. Я не сомневаюсь, что вы можете получить вполне адекватную производительность дисплея от любого из них. Настоящий вопрос в том, сколько вычислений вы выполняете за этими дисплеями. То, что вы упомянули, в основном отображает довольно близкие к необработанным данным (цена, объем и т. Д.). Для этого, вероятно, подойдет C #. Я предполагаю, что люди, с которыми вы разговаривали, выполняют значительно больше вычислений, чем это - и это настоящее ахиллесово исцеление .NET (или почти всего остального, что работает на виртуальной машине). Из того, что я видел, для действительно тяжелых вычислений C # и тому подобное на самом деле не очень конкурентоспособны.

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

Их ответ был, по сути, что они уже проделали эту дополнительную работу, и это было не просто «немного». Переписывание C # заняло примерно 3 1/2–4 месяца. Из того времени им потребовалось меньше месяца, чтобы скопировать особенности оригинала; все остальное время было потрачено на то, чтобы сделать его достаточно быстрым, чтобы его можно было использовать.

Я спешу предупредить, что 1) это только одна точка данных и 2) я понятия не имею, насколько она близка к чему-либо, что вы могли бы сделать. Тем не менее, это дает некоторое представление о том, с каким замедлением вы можете столкнуться, когда (и если) вы начнете выполнять реальные вычисления, а не просто передавать данные из сети на экран. В то же время беглый взгляд показывает, что это в целом соответствует результатам на веб-сайте Computer Language Shootout - хотя имейте в виду, что результаты относятся к Mono, а не к реализации Microsoft.

По крайней мере, для меня настоящий вопрос сводится к следующему: действительно ли ваша забота о производительности обоснована или нет? Примерно для 90% приложений важно просто то, что код делает то, что вы хотите, и скорость выполнения не имеет большого значения, пока она не получает резко медленнее (например, в сотни или тысячи раз медленнее). Если ваш код попадает в эту (большую) категорию, C # вполне может быть хорошим выбором. Если у вас действительно есть веские причины для беспокойства по поводу скорости выполнения, то мне кажется, что выбор C # был бы много более сомнительным.