Java — OpenCV (JavaCV) против OpenCV (C / C ++ интерфейсы)
Мне просто интересно, будет ли существенное преимущество в быстродействии относительно данного набора машин при использовании JavaCV, в отличие от реализации OpenCV на C / C ++.
Пожалуйста, исправьте меня, если я ошибаюсь, но я понимаю, что реализация opencv на языке c / c ++ ближе к машине, где реализация Java OpenCV, JavaC, имела бы небольшой недостаток в производительности (в миллисекундах), как это было бы. виртуальная машина, преобразующая ваш исходный код в байт-код, который затем преобразуется в машинный код. Принимая во внимание, что с помощью c / c ++ он преобразуется прямо в машинный код и, таким образом, не несет этот промежуточный шаг из-за издержек виртуальной машины.
Пожалуйста, не убивайте меня здесь, если я допустил ошибки; Я только учусь и приветствую конструктивную критику.
Спасибо
Решение
Я хотел бы добавить пару вещей к ответу @ ejbs.
Прежде всего, вы затронули 2 отдельных вопроса:
- Производительность Java против C ++
- OpenCV против JavaCV
Java против C ++ производительность это длинная, длинная история. С одной стороны, Программы на C ++ скомпилированы в высокооптимизированный нативный код. Они запускаются быстро и работают быстро все время, не делая пауз для сбора мусора или других функций виртуальной машины (как это делает Java). С другой стороны, после компиляции программа на C ++ не может измениться, независимо от того, на какой машине они запущены, пока Байт-код Java составленкак раз вовремяи всегда оптимизирован для архитектуры процессора они бегут дальше. В современном мире с таким количеством разных устройств (и процессорных архитектур) это может быть действительно значительным. Более того, некоторые JVM (например, Oracle Hotspot) могут оптимизировать даже код, который уже скомпилирован в собственный код! ВМ собирает данные о выполнении программы и время от времени пытается переписать код таким образом, чтобы он был оптимизирован для это конкретное исполнение. Таким образом, в таких сложных обстоятельствах единственный реальный способ сравнить производительность реализаций на разных языках программирования — просто запустить их и посмотреть результат.
OpenCV против JavaCV это другая история. Во-первых, вам нужно понять стек технологий, стоящих за этими библиотеками.
OpenCV изначально был создан в 1999 году в исследовательских лабораториях Intel и был написан на C. С того времени он несколько раз менял сопровождающего, становился открытым исходным кодом и достиг 3-й версии (готовится к выпуску). На данный момент ядро библиотеки написано на C ++ с популярным интерфейсом на Python и множеством оболочек на других языках программирования.
JavaCV — одна из таких оболочек. Так что в большинстве случаев, когда вы запускаете программу с JavaCV, вы на самом деле тоже используете OpenCV, просто вызывайте его через другой интерфейс. Но JavaCV предоставляет больше, чем просто один-к-одному обертку вокруг OpenCV. Фактически, он объединяет все библиотеки обработки изображений, включая FFmpeg, OpenKinect и другие. (Обратите внимание, что в C ++ вы также можете связывать эти библиотеки).
Так что, в общем, не имеет значения, что вы используете — OpenCV или JavaCV, вы получите примерно одинаковую производительность. Это больше зависит от вашей основной задачи — это Java или C ++, который лучше подходит для ваших нужд.
Есть еще один важный момент о производительности. Используя OpenCV (напрямую или через обертку), вы иногда обнаруживаете, что функции OpenCV превосходят другие реализации на несколько порядков. Это связано с интенсивным использованием низкоуровневых оптимизаций в его ядре. Например, OpenCV filter2D функция SIMD-ускоряется и, таким образом, может обрабатывать несколько наборов данных параллельно. И когда дело доходит до компьютерного зрения, такая оптимизация общих функций может легко привести к значительному ускорению.
Другие решения
JavaCV взаимодействует с OpenCV, поэтому при вызове чего-либо, связанного с OpenCV, могут возникнуть некоторые накладные расходы, но в целом большая часть тяжелой работы будет по-прежнему на стороне C ++, и поэтому не будет очень большого снижения производительности.
Вы должны сделать тесты производительности, чтобы узнать больше.
PS. Я здесь новичок, но уверен, что этот вопрос не подходит для StackOverflow.
Я хотел бы добавить еще несколько идей о Java в качестве интерфейса для библиотек C ++ …
A) разработки:
1) хотя java может быть проще для управления крупномасштабными проектами и чрезвычайно быстро компилируется, это очень очень сложно, и почти невозможно отладить нативный код из java …
когда код падает на нативной стороне … или происходит утечка памяти (что часто случается …), вы чувствуете себя беспомощным …
2) если вы сами не создадите привязки (это непростая задача, даже если вы используете swig или что-то в этом роде …), вы зависите от доброй воли / здоровья / времени строителя привязок ….
так что в этом случае я бы предпочел официальные привязки «рабочего стола Java» над Javacv …
Б) производительность.
1) в то время как привязки могут быть оптимизированы (передача памяти с использованием neobuffer), так как в случае с javacv все еще очень и очень небольшие издержки jni для каждого вызова собственной функции —
в нашем случае это не имеет смысла, так как большинство функций opencv потребляют циклы процессора X100000 ++ по сравнению с этими издержками jni …
2) БОЛЬШАЯ ПРОБЛЕМА —- остановить мир КОЛЛЕКТОР МУСОРА (GC)
java использует сборщик мусора, который останавливает все потоки процессора, делая его НЕОБХОДИМЫМ для приложений РЕАЛЬНОГО ВРЕМЕНИ, есть обходные пути, которые я слышал, например, о том, как перепроектировать ваше приложение, чтобы не производить мусор, использовать spaciel gc или использовать java в реальном времени (стоит денег …) все они кажутся лишними работами (и все, что вам нужно, — это простой и легкий путь к opencv ….)
Вывод — если вы хотите создать профессиональное приложение в реальном времени, — переходите на C ++
если у вас нет огромного модульного проекта для управления — просто придерживайтесь c ++ и предварительно скомпилированных заголовков (ускоряйте компиляцию …)
В то время как с Java приятно работать, когда дело доходит до освобождения АД родного связывания … я знаю, что я был там ….