Estoy escribiendo un programa de procesamiento de imágenes para realizar el procesamiento en tiempo real de fotogramas de vídeo. Es en C# usando el Emgu.CV de la biblioteca (C#) que envuelve la biblioteca OpenCV dll (no administrado C++). Ahora tengo que escribir mi propio algoritmo especial y tiene que ser lo más rápido posible.

Que será una implementación más rápida del algoritmo?

  1. Escribir un «inseguros», función en C#

  2. La adición de la función de la biblioteca OpenCV y llamadas a través de Emgu.CV

Supongo que C# inseguro es más lento porque va a través del compilador JIT, pero la diferencia sea significativa?

Edición:

Compilado por .NET 3.5 bajo VS2008

InformationsquelleAutor geometrikal | 2008-11-11

10 Comentarios

  1. 67

    debe ser lo más rápido posible

    Entonces usted está haciendo la pregunta equivocada.

    De código en ensamblador, con diferentes versiones para cada significativos de la arquitectura de la variante de apoyo.

    Usar como guía la salida de un buen compilador de C++ con la optimización, porque probablemente sabe algunos trucos con los que no. Pero probablemente va a ser capaz de pensar de algunas mejoras, ya que C++ no necesariamente transmitir al compilador toda la información que pueda ser útil para la optimización. Por ejemplo, en C++ no tiene la C99 palabra clave restringir. Aunque en este caso en particular, muchos compiladores de C++ (incluyendo MSVC) hacer ahora lo apoyan, así que úselo cuando sea posible.

    Por supuesto, si usted quiere decir, «yo quiero que sea rápido, pero no hasta el punto de ir fuera de C# o C++», entonces la respuesta es diferente 😉

    Yo esperaría C# para al menos acercarse al rendimiento de aspecto similar a C++ en un montón de casos. Supongo que, por supuesto, que el programa estará en funcionamiento el tiempo suficiente que el tiempo que el JIT se lleva es irrelevante, pero si estás mucho el tratamiento de vídeo, a continuación, que parece probable. Pero también me gustaría esperar ciertas cosas que si se hacen inseguros C#, será mucho más lento que el equivalente de la cosa en C++. No sé lo que son, porque toda mi experiencia de Jit es en Java, en lugar de CLR. También puede haber cosas que son más lentos en C++, por ejemplo, si el algoritmo hace que cualquier llama de vuelta en código C#.

    Por desgracia, la única manera de estar seguro de lo cerca que se está de escribir tanto y prueba de ellos, qué tipo de extraña el punto de que la escritura de C++ versión es un montón de esfuerzo extra. Sin embargo, usted puede ser capaz de obtener una idea aproximada de hacking rápida de código que se aproxima el procesamiento que se quiere hacer, sin necesariamente hacer todo esto o hacer lo correcto. Si el algoritmo se va a recorrer todos los píxeles y hacer un par de FP ops por píxel, luego de hacking juntos áspero de un punto de referencia debe tomar todas las de la mitad de una hora.

    Por lo general te aconsejo que empezar a pensar que «esto tiene que ser lo más rápido posible». Los requisitos deben ser alcanzables, y por definición «como la X como sea posible» es sólo el límite alcanzable. Requisitos también deben ser comprobables, y «como X como sea posible» no es comprobable a menos que de alguna manera saber un máximo teórico. Una más amigable requisito es «esto tiene para el proceso de fotogramas de vídeo de tal-y-tal resolución en tiempo real en tal-y-tal velocidad de la CPU», o «esto debe ser más rápido que nuestro principal competidor del producto». Si la versión de C# hace que, con un poco de sobra para dar cuenta de inesperados problemas menores en el usuario del programa de instalación, luego del trabajo realizado.

    • Que estaba muy bien escrito, cuidadosamente pensado y post informativo. Muchas gracias.
    • Gracias por su respuesta. Como un ingeniero en sistemas embebidos, no tengo mucho .NET experiencia en programación y tu post ha ayudado a mi comprensión.
    • No lo hago en assember – a menos que usted es un genio, VS 2008 se va a hacer un mejor trabajo en la optimización de usted. Uso de los elementos intrínsecos de indicar que el compilador debe utilizar de operaciones especiales (SSE, SSE2, etc) y compilar por separado para cada plataforma.
    • Códecs de vídeo y streaming de medios de comunicación, son áreas donde alguien que sabe que la CPU puede vencer compiladores de C. O al menos, eso es lo que piensan, y no voy a decirles que están equivocados. Tal vez mi respuesta no tiene claro que yo no creo que sea una buena opción para J. Azar programador de C a probarlo casualmente.
    • … aunque sólo sea porque el tiempo necesario para obtener en ensamblador de programación, si no que ya es una inversión significativa sin una garantía de resultados. Yo creo que no se necesita ser un genio, aunque, sólo persistentes.
    • para que quede claro, que yo no tengo .Experiencia en la RED, ya sea, yo voy en Java JIT rendimiento y rumores de que el .NET JIT no es horrible. Así que «espero que la C# al menos en el enfoque de C++» es deliberadamente vaga. Para Java, yo podría decir que yo saber un JIT puede pegar o golpear a C++ rendimiento.
    • Cuando trabajé con hardware embebido, una tarea común fue la de construir en C (que era una C/C++ de la tienda), construye, entonces, si una pieza necesaria una mayor optimización, hemos desmontado y tomó el compilado de la asm y la utilizó como base para la «nueva» versión del ensamblado de la función. A veces nos podría mejorar en ella – a veces no podíamos. Pero su gran línea de base para empezar con.
    • esta es una gran idea! Gracias por eso!

  2. 6

    Depende del algoritmo, la implementación, el compilador de C++ y el compilador JIT. Supongo que en la mayoría de los casos la implementación en C++ será más rápido. Pero esto puede cambiar.

    El compilador JIT se puede optimizar el código para la plataforma se ejecuta el código en lugar de un promedio para todas las plataformas de su código puede ejecutarse en como el compilador de C++ no. Esto es algo que las nuevas versiones del compilador JIT son cada vez más bueno y que en algunos casos puede dar JITted código de una ventaja. Así que la respuesta no es tan clara como se podría esperar. El nuevo Java hotspot compilador hace esto muy bien, por ejemplo.

    Otras situaciones en las que el código administrado puede hacer mejor que C++ es donde usted necesita para asignar y desasignar un montón de pequeños objetos. El .net preasigna grandes trozos de memoria que pueden ser reutilizados por lo que no necesita llamar al sistema operativo cada vez que usted necesita para asignar memoria.

    No estoy seguro inseguro C# se ejecuta mucho más rápido de lo normal C#. Vas a tener que probar esto.

    Si quieres saber cuál es la mejor solución para su situación, usted tendrá que probar ambos y medir la diferencia. Yo no creo que haya más de

    • <blockquote>no estoy seguro inseguro C# se ejecuta mucho más rápido de lo normal C#. Vas a tener que probar esto.</blockquote> Intentar rotar una imagen, primero en c# y, a continuación, el uso inseguro de c# en un Arm4vi se tarda 15 minutos en contra de 4 segundos 😉
    • Suena como algo que va mal en su caja de seguridad de código de ejemplo. Algo que se puede hacer en 4 segundos nunca debe tomar 15 minutos en código administrado.
    • En el procesamiento de vídeo no asignar y desasignar un montón de pequeños objetos. Esa es la manera de perder fotogramas.
    • Eggermont: Sí. Que fue, probablemente, el mal ejemplo para esta pregunta. @kentaromiura: Por el camino. Probablemente estabas con el .net micro framework derecho? Esto no incluye un compilador JIT para ahorrar memoria. El intérprete de bytecode es muy lento. C# vs C++ en el marco normal está más cerca.
  3. 6

    C# es típicamente más lento que C++. Hay verificaciones en tiempo de ejecución en el código administrado. Estos son los que hacen que logró, después de todo. C++ no tiene que comprobar si los límites de un array se han excedido por ejemplo.

    Desde mi experiencia, el uso de memoria fija de gran ayuda. Hay una nueva Sistema.IO.UnmanagedMemoryAccessor clase .NET 4.0 que puede ayudar en el futuro.

    • El uso de memoria fijo recibe alrededor de las verificaciones en tiempo de ejecución y permite la escritura de código similar a la de C++ para mejor y para peor.
    • El uso de memoria fija no ayuda, pero no eliminar todas las verificaciones en tiempo de ejecución.
    • En muchos casos, el JIT puede quitar la matriz de comprobación de límites en cada acceso, si se puede determinar que no excederá de los límites (como un bucle donde la condición de i < matriz.Longitud.) Incluso el Mono JIT no esta optimización.
  4. 5

    Lenguas no tienen una «velocidad». Depende del compilador y el código. Es posible escribir un código ineficaz en cualquier idioma, y un ingenioso compilador generará cerca de lo óptimo código no importa el idioma de la fuente.

    El único realmente inevitable factor en el rendimiento entre C# y C++ es que C# apps tienen que hacer más en el inicio (de la carga de la .NET framework y tal vez JIT algo de código), por lo que todas las cosas en igualdad de condiciones, que pondrá en marcha un poco más lento. Después de eso, depende, y no hay ninguna razón fundamental por la que un idioma debe ser siempre más rápido que el otro.

    Yo soy también consciente de las razones por las inseguras C# debe ser más rápido de lo que sea seguro. En general, seguro es bueno porque permite que el compilador para hacer algunos mucho más fuerte supuestos, y tan seguro podría ser más rápido. Pero de nuevo, depende del código que se está compilando, el compilador que se está utilizando y una docena de otros factores.

    En definitiva, renunciar a la idea de que se puede medir el rendimiento de un idioma. Usted no puede. Un idioma nunca es «rápido» o lenta». No tiene una velocidad.

    • Lo que puede (y debe en estos casos) que hacer es medir el rendimiento de un algoritmo particular/compilador/máquina triplete
    • En realidad, las lenguas tienen características que permiten o dissallow los compiladores para hacer optimizaciones. Un «perfecto» compilador de Fortran siempre va a vencer a un «perfecto» del compilador de C#.
    • onebyone.livejournal.com: Sí, pero que sólo elimina dos de las tres variables. Todavía depende de la particular código. Nemanja Trifunovic: yo no soy consciente de ninguna de las optimizaciones que C# prohíbe. El general compilador regla es que el código debe trabajar «como si» el lenguaje de especificación fue seguido.
    • En un mundo perfecto, el JIT debe ser capaz de hacer su caja fuerte de código tan rápido como su código inseguro. Pero la realidad es que algunos de los algoritmos de correr mucho más rápido cuando se escribe en términos de indicadores para el compilador.
    • Sin duda. Pero la realidad es también que otros algoritmos de correr más rápido cuando se escribe de ellos sin el uso de punteros, como el compilador esquiva todos los nasty, el rendimiento ponen los pelos de punta aliasing. O ¿por qué crees Fortran se utiliza en lugar de C/C++ para el alto rendimiento de computación científica? 😉
  5. 4

    Si se va a implementar el algoritmo de una manera estándar y creo que es irrelevante.
    Pero algunos idiomas tienen enlaces a la api o a las bibliotecas que se le puede dar un no standart impulso.

    1. Considerar si se puede usar el procesamiento de GPU – nvidia y ati proporcionar el CUDA y la CTM marcos y está en marcha un esfuerzo de estandarización de la khronos group (openGL). Una corazonada me dice también que amd va a agregar al menos un streaming de núcleo de procesador en sus futuros chips. Así que creo que hay una promesa en la zona.

    2. Intentar ver si se puede explotar las instrucciones SSE, hay bibliotecas de todo -la mayoría en C++ o C, que proporcionan a la mano api, verificación de Intel sitio para handy bibliotecas optimizadas recuerdo «de Rendimiento de Intel Primitivos» y un «Math Kernel».

    Pero en la política lado, ¿incorporar a su algoritmo en OpenCV para que otros puedan beneficiarse también.

    • He utilizado IPP cuando estaban libres – muy bonito, aunque el método nombres eran un buen bocado. Al parecer OpenCV puede hacer uso de IPP, si usted la tiene.
  6. 3

    Es una batalla que se ira para siempre. C frente a C++ frente a C# frente a lo que sea.
    En C#, la noción de la inseguridad es desbloquear «peligroso» de las operaciones. es decir, el uso de punteros, y ser capaz de echar a los punteros void etc, como se puede en C y C++.
    Muy peligroso, y muy potente! Pero derrotar a lo que C# se basa en.

    Usted encontrará que a día de hoy, Microsoft ha dado pasos en la dirección de rendimiento, especialmente desde el lanzamiento de .NET, y la próxima versión de .La RED realidad de soporte en línea métodos, como usted puede con C++. Esto aumentará el rendimiento para situaciones muy específicas. Odio que no va a ser un c#, pero una desagradable atributo el compilador se recoge en – pero no se puede tener todo.

    Personalmente, estoy escribiendo un juego con C# y managed DirectX (¿por qué no XNA?? más allá del alcance de este post). Estoy usando el código no seguro en la gráfica de situaciones, lo que conlleva un guiño en la dirección de lo que otros han dicho.

    Es sólo porque píxel de acceso es rediculously lento con GDI++ que me llevó a buscar alternativas. Pero, en conjunto, el compilador de c# es muy maldita buena, y para el código de comparaciones (usted puede encontrar los artículos) encontrará el rendimiento es muy similar a c++.
    Eso no quiere decir que no hay una mejor manera de escribir el código.

    Al final del día, personalmente veo C, C++ y C# como sobre la misma velocidad a la hora de la ejecución. Es sólo que en algunas situaciones dolorosas en la que desea trabajar muy estrechamente con el hardware subyacente o muy cerca de los píxeles, en la que encontrará notable ventaja a la C/C++ multitud.

    Pero para los negocios, y la mayoría de las cosas hoy en día, C# es un verdadero contendiente, y permanecer dentro de la «caja fuerte» el medio ambiente es definitivamente una ventaja.

    Al salir, usted puede obtener la mayoría de las cosas hechas con código inseguro, como yo – y el muchacho, he ido a algunos extremos! Pero valió la pena? Probablemente no. Personalmente me pregunto si debería haber pensado más a lo largo de las líneas de código en C++, y todo el Orientado a Objetos segura cosas en C#. Pero me tienen un mejor rendimiento que he pensado que me gustaría conseguir!!!

    Siempre y cuando usted tiene cuidado con la cantidad de interoperabilidad de las llamadas que usted está haciendo, usted puede obtener lo mejor de ambos mundos. Personalmente, he evitado, pero no sé a qué costo.

    Por lo que un enfoque no lo he probado, pero me encantaría escuchar aventuras, en el uso de C++.NET para desarrollar una biblioteca en la que sería más rápido que c#’s inseguro para estas gráficas especiales situaciones? Cómo es eso de comparar a los nativos de C++ de código compilado? Ahora hay una pregunta!

    Hmm..

  7. 2

    Si usted sabe que su entorno y utilizar un buen compilador (para el procesamiento de vídeo en windows, Intel C++ Compiler es probablemente la mejor opción), C++ va a vencer a C# las manos hacia abajo por varias razones:

    • El C++ runtime environment no tiene intrínseca verificaciones en tiempo de ejecución (la desventaja es que tienen vía libre para volar usted mismo). El C# entorno de tiempo de ejecución va a tener un poco de cordura comprobación pasando, al menos inicialmente.
    • Los compiladores de C++ están construidos para optimizar el código. Si bien es teóricamente posible implementar un C# compilador JIT utilizando todos los de la optimización de voodo que la CCI (o GCC) los usos, es dudoso que Microsoft JIT de forma fiable para hacerlo mejor. Incluso si el compilador JIT tiene tiempo de ejecución de las estadísticas, que todavía no es tan bueno como el perfil guiada por la optimización en la corte penal internacional o GCC.
    • C++ entorno le permite controlar su modelo de memoria mucho mejor. Si su solicitud se llega al punto de sobrecargando la memoria caché de datos o la fragmentación del montón, realmente apreciará el control extra sobre la asignación. Diablos, si usted puede evitar asignaciones dinámicas, ya estás mucho mejor (sugerencia: el tiempo de ejecución de malloc() o cualquier otra dinámica asignador no es determinista, y casi todos los no-nativos de idiomas de la fuerza más pesada el uso del montón, y por lo tanto más pesado de asignación).

    Si utiliza un pobre compilador, o si no puede orientar un buen chipset, todas las apuestas están apagadas.

    • La asignación en el CLR es O(1). Puntero siguiente ir. El gasto está en la colección, pero usando exactamente los mismos principios como C++ optimización se pueden hacer cosas muy elegante. Usted va a faltar a los punteros, que proporcionan el rendimiento, sin embargo. Mal mal punteros…
  8. 1

    Estoy un poco tarde para responder pero te puedo dar algunas anécdotas de la experiencia. Hemos tenido algunos multiplicación de la matriz rutinas que originalmente fueron codificados en C# usando punteros y código inseguro. Esto resultó ser un cuello de botella en nuestra aplicación y a continuación, utiliza la fijación+P/Invoke para llamar a una versión de C++ de la multiplicación de la Matriz de rutina y tiene un factor de 2 mejora. Esto fue hace un rato con el .NET 1.1, así que las cosas podrían estar mejor ahora. Como otros señalan, este demuestra nada, pero fue un ejercicio interesante.

    También estoy de acuerdo con thAAAnos, si usted algoritmo realmente tiene que ser «tan rápido como sea posible» apalancamiento IPL o, si es necesario, considere la posibilidad de una GPU aplicación.

  9. 1

    Para ser honesto, ¿en qué idioma escribes no es casi tan importante como lo que los algoritmos que utiliza (OMI, de todos modos). Tal vez por ir a código nativo que podría hacer su aplicación más rápido, pero también podría hacer más lento–se había dependen del compilador, cómo los programas se escriben, qué tipo de interoperabilidad de los costos que tendría que incurrir si usted está utilizando un entorno mixto, etc. Realmente no se puede decir sin el perfil. (y, para el caso, han perfila su aplicación? ¿Realmente sabes donde pasar el tiempo?)

    Un mejor algoritmo es completamente independiente del idioma que usted elija.

  10. -7

    Ejecutando en la CPU siempre va a ser más rápido que se ejecuta en una máquina virtual en la CPU. No puedo creer que la gente está tratando de argumentar lo contrario.

    Por ejemplo, tenemos algunos bastante pesada carga de trabajo de procesamiento de imágenes en nuestro servidor web que está en la cola. Inicialmente se trabaja para conseguirlo, utilizamos PHP GD funciones.

    Que eran lentos como el infierno. Hemos reescrito la funcionalidad que necesita en C++.

    • C# no se ejecuta en una máquina virtual, ya sea.
    • Los compiladores JIT son también llamadas máquinas virtuales. Aunque también creo que esta respuesta ineficiente, VM es se aceptan como sinónimo aquí.

Dejar respuesta

Please enter your comment!
Please enter your name here