OpenCV (JavaCV) vs OpenCV (interfaces C/C++))
je me demande simplement s'il y aurait un avantage significatif de performance de vitesse relativement sur un ensemble donné de machines en utilisant JavaCV par rapport à L'implémentation C/C++ D'OpenCV.
corrigez-moi si je me trompe, mais ma compréhension est que l'implémentation c/C++ d'opencv est plus proche de la machine où comme l'implémentation Java D'OpenCV, JavaC, aurait un léger inconvénient de performance de vitesse (en millisecondes) comme il y aurait une machine virtuelle convertir votre code source en bytecode qui est ensuite converti en code machine. Alors qu'avec c/c++, il est converti directement en code machine et ne supporte donc pas cette étape intermédiaire de la machine virtuelle.
S'il vous plaît ne me tuez pas ici si j'ai fait des erreurs; je suis juste en train d'apprendre et je serais heureux critique constructive.
Merci
3 réponses
j'aimerais ajouter quelques éléments à la réponse de @ejbs.
tout d'abord, vous avez concerné 2 questions distinctes:
- Java vs C++ de la performance
- OpenCV vs JavaCV
Java vs. C++ performance est une longue, longue histoire. D'une part, programmes C++ sont compilés en un hautement optimisé en code natif. Ils commencent rapidement et courent rapidement tout le temps sans s'arrêter pour la collecte des ordures ou autres tâches de VM (comme Java do). D'autre part, une fois compilé, le programme en C++ ne peut pas changer, peu importe sur quelle machine ils sont lancés, alors que Java bytecode est compilé " just-in-time" et est toujours optimisé pour l'architecture du processeur ils courent sur. Dans le monde moderne, avec autant d'appareils (et d'architectures de processeurs) différents, cela peut être très significatif. En outre, certaines JVM (par exemple Oracle Hotspot) peuvent optimiser même le code qui est déjà compilé au code natif! VM collecte des données sur l'exécution du programme et essaie de temps en temps de réécrire le code de telle manière qu'il soit optimisé pour cette exécution. Ainsi, dans des circonstances aussi compliquées, le seul moyen réel de comparer les performances des implémentations dans différents langages de programmation est de les exécuter et de voir le résultat.
OpenCV vs. JavaCV c'est une autre histoire. Tout d'abord, vous devez comprendre la pile de technologies derrière ces bibliothèque.
OpenCV a été créé à L'origine en 1999 dans les laboratoires de recherche Intel et a été écrit en C. Depuis ce temps, il a changé le responsable à plusieurs reprises, est devenu open source et atteint la troisième version (à venir). En ce moment, core of the library est écrit en C++ avec une interface populaire en Python et un certain nombre de wrappers dans d'autres langages de programmation.
JavaCV est l'un de ces emballages. Ainsi, dans la plupart des cas, lorsque vous exécutez un programme avec JavaCV, vous utilisez réellement OpenCV aussi, appelez-le via une autre interface. Mais JavaCV fournit plus qu'un seul emballage autour D'OpenCV. En fait, il regroupe l'ensemble des bibliothèques de traitement d'image, dont FFmpeg, OpenKinect et d'autres. (Notez qu'en C++ vous pouvez aussi lier ces bibliothèques).
donc, en général, peu importe ce que vous utilisez - OpenCV ou JavaCV, vous obtiendrez à peu près la même performance. Il dépend plus de votre tâche principale - est-il Java ou C++ qui est mieux adapté pour votre besoin.
il y a encore un point important à propos de la performance. En utilisant OpenCV (directement ou via wrapper), vous constaterez parfois que les fonctions OpenCV surmontent les autres implémentations par plusieurs ordres. Cela est dû à l'utilisation massive d'optimisations de bas niveau dans son cœur. Par exemple, Opencv's filter2D fonction SIMDaccélération et peuvent ainsi traiter plusieurs ensembles de données en parallèle. Et quand il s'agit de la vision informatique, de telles optimisations de les fonctions peuvent facilement conduire à une accélération significative.
JavaCV se connecte à OpenCV, donc quand vous appelez quelque chose lié à OpenCV, il y aura des frais généraux, mais en général la plupart du travail lourd sera toujours du côté c++ et donc il n'y aura pas de pénalité de très grande performance.
il faudrait faire des benchmarks de performance pour en savoir plus.
PS. Je suis assez nouveau ici mais je suis plutôt sûr que ce n'est pas une question appropriée pour StackOverflow.
j'aimerais ajouter quelques idées sur java en tant qu'interface pour les bibliothèques c++...
A)développement:
1)alors que java peut être plus facile à gérer des projets à grande échelle et compile extrêmement rapide, il est très très difficile, et presque impossible de déboguer le code natif de java...
lorsque le code écraser sur les côté...ou des fuites de mémoire( quelque chose qui arrive souvent... ) vous sentez un peu impuissant...
2) sauf si vous construisez vous-même les fixations( ce n'est pas une tâche facile, même avec swig ou autre... ) vous dépendez de la bonne volonté/Santé/temps du constructeur de reliures.... donc, dans ce cas, je préférerais les reliures officielles "Java desktop" à javacv...
B)la performance.
1) alors que les liaisons peuvent être optimisées( transfert de mémoire en utilisant neobuffer ) comme dans le cas de javacv il y a encore un très petit overhead jni pour chaque appel de fonction natif - cela n'a pas de sens dans notre cas puisque la plupart des fonctions opencv consommez x100000++ cycles cpu par rapport à ce JNI overhead...
2) The BIG-PROBLEM ---- stop the world GARBAGE COLLECTIOR( GC )
java utilise un collecteur de déchets qui stoppe tous les threads de cpu ce qui le rend impropre pour les applications en temps réel , il ya iv'e de travail autour iv'e entendu parler de comme la refonte de votre application pour ne pas produire de déchets, utiliser un spaciel gc, ou utiliser java temps réel( coût argent... ( et tout ce que vous vouliez, c'était un chemin facile pour opencv.... )
conclusion-Si vous voulez créer une application professionnelle en temps réel-alors allez avec c++ a moins que vous n'ayez un énorme projet modulaire à gérer - restez simplement avec c++ et des en-têtes précompilés( faites que les choses se compilent plus rapidement... ) alors que java est un plaisir de travailler avec , quand il s'agit de reliure natif L'enfer se déchaîne...je sais iv e été là....