OpenCV (JavaCV) и OpenCV (интерфейсы C/С++)

Мне просто интересно, будет ли значительное преимущество в скорости работы относительно заданного набора машин при использовании JavaCV в отличие от реализации OpenCV на C/С++.

Пожалуйста, исправьте меня, если я ошибаюсь, но я понимаю, что реализация opecv c/С++ ближе к машине, где, как реализация Java OpenCV, JavaC, будет иметь небольшой недостаток производительности (в миллисекундах), поскольку будет виртуальная машина, преобразующая ваш исходный код в байт-код, который затем преобразуется в машинный код. В то время как с c/С++ он преобразуется прямо в машинный код и, таким образом, не несет этот промежуточный шаг накладных расходов виртуальной машины.

Пожалуйста, не убивайте меня здесь, если я ошибаюсь; Я просто учусь и буду приветствовать конструктивную критику.

Спасибо

Ответ 1

Я хочу добавить пару вопросов в ответ @ejbs.

Прежде всего, вы затронули два отдельных вопроса:

Производительность Java и С++
OpenCV vs JavaCV

Производительность Java против С++ - долгая, длинная история. С одной стороны, программы на C++ скомпилированы в высокооптимизированный собственный код. Они запускаются быстро и быстро работают быстро, не делая паузы для сбора мусора или других обязанностей VM (как это делает Java). С другой стороны, после компиляции программа на С++ не может измениться, независимо от того, на какой машине они запущены, тогда как байт-код Java скомпилирован "точно в срок" и всегда оптимизирован для архитектуры процессора, на которой они работают. В современном мире с таким количеством различных устройств (и процессорных архитектур) это может быть действительно значительным. Более того, некоторые JVM (например, Oracle Hotspot) могут оптимизировать даже код, который уже скомпилирован на собственный код! VM собирает данные о выполнении программы и время от времени пытается переписать код таким образом, чтобы он оптимизировался для этого конкретного выполнения. Поэтому в таких сложных условиях единственный реальный способ сравнить производительность реализации на разных языках программирования - просто запустить их и увидеть результат.

OpenCV vs. JavaCV - это еще одна история. Сначала вам нужно понять стек технологий за этими библиотеками.

OpenCV был первоначально создан в 1999 году в исследовательских лабораториях Intel и был написан на C. С того времени он несколько раз менял сопровождающего, стал открытым исходным кодом и достиг третьей версии (предстоящий выпуск). На данный момент ядро библиотеки написано на С++ с популярным интерфейсом в Python и несколькими обертками на других языках программирования.

JavaCV - одна из таких оболочек. Поэтому в большинстве случаев, когда вы запускаете программу с JavaCV, вы фактически используете OpenCV, просто вызывайте ее через другой интерфейс. Но JavaCV обеспечивает более чем один-к-одному обертку вокруг OpenCV. Фактически, он объединяет в себя все библиотеки обработки изображений, включая FFmpeg, OpenKinect и другие. (Обратите внимание, что в С++ вы также можете связать эти библиотеки).

Итак, в общем, неважно, что вы используете - OpenCV или JavaCV, вы получите примерно такую же производительность. Это больше зависит от вашей основной задачи - это Java или С++, который лучше подходит для ваших нужд.

Есть еще один важный момент в производительности. Используя OpenCV (напрямую или через обертку), вы иногда обнаружите, что функции OpenCV преодолевают другие реализации несколькими порядками. Это связано с интенсивным использованием низкоуровневых оптимизаций в своем ядре. Например, функция OpenCV filter2D SIMD - ускорена и, следовательно, может обрабатывать несколько наборов данных параллельно, И когда дело доходит до компьютерного зрения, такая оптимизация общих функций может легко привести к значительному ускорению.

Ответ 2

JavaCV-интерфейсы к OpenCV, поэтому, когда вы вызываете что-то связанное с OpenCV, будут некоторые накладные расходы, но в целом большая часть тяжелой работы будет по-прежнему находиться на стороне С++, и поэтому не будет очень большого штрафа за производительность.

Вам нужно будет выполнить тесты производительности, чтобы узнать больше.

PS. Я здесь довольно новый, но я уверен, что это не подходящий вопрос для StackOverflow.

Ответ 3

Я хотел бы добавить несколько дополнительных сведений о java в качестве интерфейса для библиотек С++...

А) развивается:

1), в то время как java может быть проще управлять крупномасштабными проектами и компилироваться очень быстро, очень сложно, а рядом невозможно отладить собственный код из java...

когда сбой кода на родной стороне... или утечки памяти (что-то происходит много...), вы чувствуете себя беспомощным...

2), если вы сами не создаете привязки (не простая задача даже при использовании swig или что-то еще...), вы зависите от хорошей воли/здоровья/времени создателя привязок.... так что в этом случае я бы предпочел официальные привязки "desktop java" к javacv...

В) производительности.

1), в то время как привязки могут быть оптимизированы (передача данных с использованием neobuffer), как в случае с javacv, все еще очень маленькие jni-служебные данные для каждого вызова нативной функции - это бессмысленно в нашем случае, поскольку большинство opencv-функций потребляют циклы X100000 ++ cpu по сравнению с этими jni-служебными данными...

2) БОЛЬШАЯ ПРОБЛЕМА ---- прекратите мир КОЛЛЕКЦИОНЕР СОХРАНЕНИЯ (GC)

java использует сборщик мусора, который останавливает все потоки cpu, что делает его неприемлемым для приложения REAL-TIME, есть работа, о которой я слышал, например, о том, чтобы перепроектировать ваше приложение, чтобы не производить мусор, использовать файл spaciel gc или использовать java-приложение в реальном времени (стоить деньги...) все они кажутся лишней работой (и все, что вам нужно, - это хороший легкий путь к opencv....)

заключение - если вы хотите создать профессиональное приложение в реальном времени - тогда перейдите к С++ если у вас нет огромного модульного проекта для управления - просто придерживайтесь С++ и предварительно скомпилированных заголовков (делайте вещи быстрее компиляции...) в то время как java с удовольствием работает, когда дело доходит до нативного связывания. HELL ломается... я знаю, что там было...