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



скорость разница (11)

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

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

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

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

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

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

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

*** EDIT ***

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

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

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


Answers

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

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

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


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


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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

Так гранулированность !!!

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

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

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


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

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

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

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


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


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

SO вопросы по одной и той же / аналогичной теме:

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


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

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

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

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


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

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

Раньше атомизация выполнялась с использованием встроенных компиляторов или некоторой библиотеки более высокого уровня. Заборы были бы выполнены с использованием инструкций, специфичных для процессора (барьеров памяти).





c# c++ dll export