Бэкэнд C++ с интерфейсом C#?

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

У меня возникли проблемы с пониманием использования DLL для основной обработки сообщений на C++, но затем передачи информации в интерфейс C#. Может кто-нибудь заглушить его для меня? здесь?

кроме того , поскольку скорость будет приоритетом, мне было интересно, будет ли доступ через 2 разных уровня кода иметь больше производительности, что программирование проекта в целом на C# или, конечно, на C++, хотя я читал плохие вещи о программировании GUI на C++, в котором это приложение также должно выглядеть современным, чистым, профессиональным и т. д. поэтому я думал, что C# будет шагом вперед (возможно, XAML, wPF)

Спасибо за ваше время.

9
c# c++ performance user-interface wpf

5 ответов

самый простой способ взаимодействия между DLL C/C++ и сборкой .NET-через P / invoke. На стороне C/C++ создайте DLL, как и любой другой. На стороне C# вы создаете объявление P / invoke. Например, скажем, ваша DLL-это mydll.dll и экспортирует метод void Foo():

[DllImport("mydll.dll")]
extern static void Foo();

вот именно. Вы просто вызываете Foo как любой другой метод статического класса. Трудная часть - это сбор данных, и это сложная тема. Если вы пишете DLL, вы, вероятно, можете выйти вашего способа сделать экспортные функции легко упорядоченными. Для еще по теме п/вызвать сортировочных увидеть здесь: http://msdn.microsoft.com/en-us/magazine/cc164123.aspx.

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

вы должны знать, что все приложения .NET переполнены вызовами p/invoke. Ни одно приложение .NET не может избежать вызовов операционной системы, и каждый вызов ОС должен перейти в неуправляемый мир ОС. WinForms и даже графические приложения WPF делают это путешествие много сотен, даже тысяч раз в секунду.

Если бы это была моя задача, я бы сначала сделал это на 100% в C#. Я бы тогда профиль и настройки производительности по мере необходимости.

6

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

возможно, вы захотите взглянуть на этот вопрос для сравнения производительности.

разделение back-end и front-end-хорошая идея. Если вы получаете штраф за производительность от наличия одного в C++ и c#, зависит от того, сколько преобразования данных на самом деле необходимо.

Я не думаю, что программирование GUI-это боль в целом. MFC может быть болезненным, Qt нет (IMHO).

может быть, это дает вам некоторые моменты для начала!

6

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

4

Если у вас есть источник C / C++, рассмотрите возможность его связывания в сборку C++/CLI .NET. Такой проект позволяет смешивать неуправляемый код и помещать в него управляемые интерфейсы. Результатом является простая сборка .NET, которая тривиальна для использования в C# или VB.NET проекты.

на маршалинг простых типов, так что вы можете вызывать функции из управляемом C++ в неуправляемую сторону.

единственное, что вам нужно знать, это то, что когда вы Маршалл делегируйте в указатель функции, чтобы он не содержал ссылку, поэтому, если вам нужен C++ для хранения управляемых обратных вызовов, вам нужно организовать удержание ссылки. Кроме этого, большинство встроенных преобразований работают так, как ожидалось. Visual studio даже позволит вам отлаживать через границу (включить неуправляемую отладку).

Если у вас есть .lib, вы можете использовать его в проекте C++/CLI, пока он связан с C-Runtime динамически.

2

вы должны действительно прототип это в C#, прежде чем начать завинчивание с маршалингом и unmarshalling данных в небезопасные структуры, так что вы можете вызывать функции в DLL C++. C# очень часто быстрее, чем вы думаете. Прототипирование дешево.

1