Подтвердить что ты не робот

Быстрая программа на С++, С# GUI, возможно?

Я изучаю разработку приложения, которое будет обрабатывать данные с камеры сканирования строк со скоростью около 2000 строк (кадров) в секунду. Для этого приложения в реальном времени я чувствую, что C/С++ - это путь. (Это мое чувство, и другие согласятся, что управляемый код просто не подходит для этой задачи.)

Однако, я сделал очень мало MFC или любой другой графический интерфейс С++. Я действительно очень хорошо делаю С# GUI.

Поэтому мне кажется естественным написать интенсивный для данных код в C/С++ и графический интерфейс на С#. GUI будет использоваться для настройки/калибровки/он-лайн мониторинга (и, возможно, вывода данных через UDP, потому что это проще в С#.

Итак, во-первых, я хотел бы посмотреть, согласен ли кто-нибудь с тем, что это будет путь. Основываясь на моем опыте программирования (хорошо на низкоуровневых алгоритмах C и высоком графическом дизайне С#), он просто чувствует себя хорошо.

Во-вторых, я не уверен, как правильно это сделать. Я просто собрал решение в VS2005, которое вызывает некоторые (внешние) C-DLL-функции из приложения С#. И чтобы убедиться, что я могу это сделать, я написал некоторые глобальные переменные в DLL и прочитал их:

test.h

int globaldata;
extern "C" __declspec(dllexport) void set(int);
extern "C" __declspec(dllexport) int  get();

test.cpp

extern int data=0;
__declspec(dllexport) void set(int num) {
    data = num;
}

__declspec(dllexport) int get() {
    return data;
}

test.cs

[DllImport("test")]
private static extern void set(int num);

[DllImport("test")]
private static extern int get();

Вызов get() и set() работает правильно (get() возвращает число, которое я передал в set()).

Теперь я знаю, что вы также можете экспортировать класс С++, но нужно ли это управлять? Как это работает? Правильно ли я делаю это?

Спасибо за вашу помощь!

*** EDIT ***

Прежде всего, СПАСИБО за ваши фантастические ответы! Я всегда невероятно впечатлен переполнением стека...

Я полагаю, что одна вещь, на которую я должен был наткнуться больше, не обязательно была необработанной скоростью (это может быть прототип и бенчмаркинг). Одна вещь, которая меня больше волнует, - это недетерминированное поведение Мусора. Это приложение не будет терпимым к задержке в 500 мс при выполнении сбора мусора.

Я все для кодирования и пробовал это в чистом С#, но если я заранее знаю, что GC и любое другое недетерминированное поведение .NET(?) вызовут проблему, я думаю, что мое время было бы лучше потрачено кодируя его на C/С++ и выясняя лучший интерфейс С#.

4b9b3361

Ответ 1

Нет причин, по которым вы не можете полностью писать код высокой производительности на С#.

SO вопросы по той же/подобной теме:

Другие статьи:

Ответ 2

На мой взгляд, ваше решение является звуковым:

  • Несмотря на то, что С# быстро, он никогда не может конкурировать с хорошо написанным неуправляемым C/С++, я сам сделал высокопроизводительные приложения, что доказывает это за крошечными примерами, которые люди всегда публикуют, когда кто-то публикует эти типы операторов
  • Программирование MFC или ATL UI является громоздким и медленным, С# - путь сюда, я НИКОГДА не буду выполнять программирование MFC/ATL UI заново, за исключением случаев, когда он вынужден

Ваше решение, если вы еще не выяснили его, называется "Смешанный режим", что в основном означает, что вы комбинируете Managed (С#) и Unmanaged (C/С++) код в тех же проектах, часто немного хлопот, чтобы запустить проект VS (LNK2020 errors..argh..), но когда вы найдете правильные настройки, он должен работать нормально.

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

Еще одна вещь, на которую вы можете обратить внимание, - это проект с открытым исходным кодом под названием SWIG. SWIG берет ваш код C/С++ и создает из него сборку .NET, я сам использовал его в своем TM ++ с открытым исходным кодом. См. Здесь для получения дополнительной информации о SWIG http://www.swig.org/.

Ответ 3

Для приложений реального времени: я рекомендую С++, вы будете более гибкими с управлением памятью, быстрее и даже мультиплатформенными в зависимости от того, какая структура используется...!

О структуре и графическом интерфейсе я рекомендую вам взглянуть на Qt. Qt - отличная платформа для разработки программного обеспечения на С++.

Я думаю, это решение вашей проблемы!

Ответ 4

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

Только после того, как у вас есть факты, вы можете принять решение о том, использовать ли C/С++ для управляемого решения.

Наряду с другими, кто комментировал, я подозреваю, что С#/управляемое решение будет прекрасно, особенно если вы используете .NET Parallel Extensions.

Если вы закончите маршрут C/С++, тогда есть два варианта re interop, а именно: pInvoke и COM-взаимодействие. Я не верю, что есть чистый способ доступа к неуправляемым классам С++ непосредственно из .NET; с этой целью вам придется рассмотреть реализацию управляемой/неуправляемой сборки С++.

Ответ 5

Моя компания делает что-то очень похожее, хотя с камерами CCD вместо камер линейного сканирования. Мы используем С# для графического интерфейса, сетевого общения, высокоуровневой "сантехники" и С++/CLI для низкоуровневых алгоритмов. Это работает очень хорошо. Вы никогда не сможете написать настоящую систему реального времени с гарантированным максимальным временем отклика на окнах, но, по моему опыту, GC будет наименьшим из ваших проблем здесь. Во-первых, GC работает только при распределении памяти; так и malloc/new в C/С++, и им тоже нужно время (подумайте о фрагментации памяти). Из проведенных измерений полный GC занимает 10-50 мс и не будет необходимости останавливать другие потоки за это время (если они не попытаются выделить управляемую память, я думаю), что подходит для нас. Но я не уверен, могут ли эти числа быть обобщены для любого приложения, вы, вероятно, должны сделать свое собственное профилирование, чтобы быть уверенным.

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

Второй вопрос заключался в том, следует ли использовать С++ или С# для реальных алгоритмов. Лично я чувствую себя более comforatble в С++, когда я пишу сложные алгоритмы обработки изображений. Я считаю, что язык лучше подходит для задачи, и для C/С++ существует гораздо больше библиотек с сокращением, чем для С#. Но это может быть вопросом личных предпочтений. С точки зрения производительности, С++ имеет то преимущество, что С++ inliner лучше, чем .NET JIT inliner (т.е. Он может встроить больше ваших небольших вызовов функций).

Если вы решите использовать С++, я бы предложил использовать С++/CLI: Таким образом, вы можете писать классы С++, которые скомпилированы в управляемый код. Оптимизатор С++ оптимизирует их, только последний шаг компиляции для собственного кода будет выполнен .NET JIT. Большим преимуществом является то, что вы можете напрямую обращаться к вашим .NET-классам из С++/CLI, и вы можете легко создавать управляемые классы в С++/CLI, к которым можно получить доступ с С#. Вам не нужно писать код обертки по обеим сторонам забора. (С++/CLI немного неуклюж, потому что он содержит языковые конструкции для управляемого и для неуправляемого программирования, но если вы уже знакомы с неуправляемыми С++ и С#, у вас, вероятно, не будет никаких проблем с пониманием этого.)

Ответ 6

Для С++ вы используете С++/CLI, что на самом деле не так уж плохо. Это намного лучше, чем старые управляемые расширения.

Прокомментировать производительность. Это действительно зависит. Сколько будет впереди и между вашим кодом на С++ и кодом С#? Будете ли вы получать фоновые потоки данных на С++ и периодически отправлять их на код С#? Если вы собираетесь взаимодействовать с устройством, будет ли он использоваться последовательный, USB, какой-либо API, который вам предоставлен?

Ответ 7

Я согласен с Митчем 100%.

Если после изучения его ресурсов вы все еще чувствуете, что вам нужно использовать какой-то неуправляемый код, вы можете написать "бизнес-уровень" на С++ (или, в данном случае, действительно функциональный), и написать свой интерфейс в С#. Используйте COM Interop для вызова из С#/управляемого кода в неуправляемый код.

Опять же, я чувствую, что вам не нужно это делать.

Ответ 8

Язык, который вы выберете, не повлияет на производительность (скажем, вы можете повлиять на скорость на 5/10%). Что будет иметь значение - это алгоритмы, которые вы будете использовать, как обрабатывать данные, профилировать ваше приложение и т.д. (Производительность может измениться с коэффициентом 10x).

Ответ 9

Я сделал это с С++. NET

Поскольку управляются как С++. NET, так и С#, я не понимаю, почему это невозможно. Дело в том, как вы это сделаете.

У моего сканера было до 3000 строк/сек, но ключевой стратегией было отображать блоки по 32 строки за раз. У меня не было жестких требований в реальном времени, поэтому иногда я мог немного отставать. Если для вас очень важно реальное время, вам следует рассмотреть возможность переключения платформы.

Существует решение в режиме реального времени под названием "InTime OS", но его очень больно использовать.

Еще один подход, который вы можете сделать, - отделить жесткое реальное время в отдельной DLL или библиотеке, а С# показать, что он может на своей собственной скорости. Действительно, пользователь никогда не сможет определить, имеет ли ваш интерфейс 2000 кадров в секунду или 500 кадров в секунду

Ответ 10

У меня есть опыт работы в системах с очень низкой задержкой в ​​C/С++ и С#.

  • в C/С++ 80% времени процессора теряется в детерминированных методах malloc, но собственный код в 10 раз быстрее, чем код msil

  • в распределении памяти С# быстрее, потому что это асинхронный процесс

Ваш выбор должен выполняться соотношением: время процесса/номер malloc

Итак, гранулярность!!!

Решением для C/С++ является предварительное выделение всех буферов в памяти (при необходимости используйте кеш-память предварительной выборки L2/L3)

Решение для С# минимизирует механизм преобразования P-Invoke

Поздравляем ваш проект, Пол

Ответ 11

Внешняя часть wpf и С++ backend (pinvoke) выполняется быстро, но когда вы работаете с графическим интерфейсом и в потоках, ваш поток графического интерфейса не блокируется вашим фоновым кодом. Когда вы это сделаете, ваша программа будет выглядеть быстрее и легко.

Ответ 12

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