Me gustaría construir mi propia biblioteca de procesamiento de señales, y posiblemente otra sobre el algoritmo de gráficos. Encuentro C# muy útil y robusto en lo que respecta a posibles errores asociados con la asignación de memoria, punteros, roscado, etc ...procesamiento de señal: C++ vs C#
Pero me preguntaba cuánto voy a perder en términos de rendimiento. ¿Va a ser algo aceptable?
Gracias
Cuando comencé mi curso de DSIP, era un desarrollador de C# puro. Después de mirar por un tiempo, terminé usando librerías C++ y aprendiendo C++ que al final fue para mi beneficio ya que estaba haciendo procesamiento de imágenes en tiempo real y no hay forma de que C# pueda igualar el rendimiento.
De hecho, puede ejecutar una prueba rápida y ejecutar una ecuación matemática que consta de unas pocas multiplicaciones en C# y C++ un millón de veces y ver la gran diferencia que hay haciendo cálculos con números de coma flotante.
Si tiene suerte, obtendrá envoltorios en C# que es lo mejor de ambos mundos, cálculo rápido en C++ y fácil de usar en C#. Hay un contenedor C# para OpenCV y parece ser bastante bueno (http://www.emgu.com/wiki/index.php/Main_Page).
Recomiendo especialmente OpenCV especialmente para el procesamiento de señal 2D. Es excelente en rendimiento e hizo posible mi proyecto. Eche un vistazo a la demostración aquí: http://www.youtube.com/watch?v=NeQvcdRPxoI y http://www.youtube.com/watch?v=NqYPJELHkhA
Con el hardware adecuado, que no debería tener un problema.
Algo en lo que pensar: no tengo ningún problema tratando de encontrar una biblioteca para hacer procesamiento de señal en C++. Sin embargo, no puedo encontrar fácilmente mucha información relacionada con el procesamiento de señales para C#.
Si puede encontrar la manera de hacerlo funcionar, es posible que haya encontrado una forma de entrar en un área de desarrollo del que muchas otras personas puedan beneficiarse.
Sólo algo en que pensar. A menos que esté haciendo esto en algún sistema de misión crítica, probablemente no importe de ninguna manera. Simplemente iría con lo que creas que te beneficiará más a largo plazo.
+1. buena respuesta – Aliostad
+1 por considerar el aspecto "C# -niche". – Frank
A menudo veo el comentario de que "con el hardware correcto no deberías tener un problema", igualando algo así como "con el hardware correcto no debería haber una penalización de rendimiento. No estoy de acuerdo con esto simplemente porque cuesta dinero comprar PC, mantenerlas, proporcionar suficiente memoria, etcétera. Por lo tanto, desde este punto de vista real: cuesta dinero trabajar con idiomas y/o bibliotecas ineficientes. Por qué alguien querría decir que 'mejor hardware' resuelve que el problema no es ver el lado algorítmico del asunto, y eso es lo que la mayoría de la gente pregunta cuando pregunta sobre el desempeño. –
No se trata tanto de la pérdida de rendimiento en C# sino de la imprevisibilidad de cuando se realiza la recolección de basura. Durante el GC, todos los hilos gestionados se congelan hasta que se completa el GC. Durante ese tiempo no puede hacer ningún procesamiento, que para el 99% de las aplicaciones no será importante, pero para el procesamiento de la señal es fundamental. Esta es, por ejemplo, la razón por la que no ve una versión administrada sancionada por Microsoft de DirectShow u otras aplicaciones de procesamiento de señales en "tiempo real".
Similar a un recolector de basura, no se puede predecir cuándo malloc o nuevo caminará por la cadena libre y consolidará la memoria. Puedes controlar cuándo se ejecuta el GC si es absolutamente necesario. –
GC normalmente toma solo 20-30ms. Entonces no debería ser un problema. – Aliostad
Ankur: Esa es una de las razones por las que usarías una arena de memoria/preasignación en lugar de usar malloc regular, para que no cuente en mi mente. – BrokenGlass
+1 buen pensamiento en los envoltorios ... Ha pasado tanto tiempo desde que usé uno que tiendo a olvidar que existen. –
¿Existe algún estándar "de facto" para el procesamiento de señal en C++? – Bob