Verdadero rendimiento de código inseguro

Question

Entiendo que el código no seguro es más apropiado para acceder a cosas como la API de Windows y hacer fundidos de tipo no seguro que escribir código de rendimiento, pero me gustaría preguntarle si alguna vez ha notado una mejora significativa en el rendimiento aplicaciones del mundo real al usarlo en comparación con el código C# seguro.

Answer 1

Un buen ejemplo es la manipulación de imágenes. Modificar los Píxeles mediante el uso de un puntero a sus bytes (que requiere un código inseguro) es bastante más rápido.

Ejemplo: http://www.gutgames.com/post/Using-Unsafe-Code-for-Faster-Image-Manipulation.aspx

Dicho esto, para la mayoría de los escenarios, la diferencia podría no ser tan notable. Por lo tanto, antes de usar un código no seguro, perfile su aplicación para ver dónde están los cuellos de botella de rendimiento y pruebe si el código inseguro es realmente la solución para hacerlo más rápido.

Answer 2

Como se indicó en otras publicaciones, usted puede usar código inseguro en contextos muy especializados para obtener un rendimiento significativo en la mejora. Uno de esos escenarios se itera sobre las matrices de tipos de valores. El uso de la aritmética de punteros inseguro es mucho más rápido que el patrón habitual de for-loop/indexador ..

struct Foo 
{ 
    int a = 1; 
    int b = 2; 
    int c = 0; 
} 

Foo[] fooArray = new Foo[100000]; 

fixed (Foo* foo = fooArray) // foo now points to the first element in the array... 
{ 
    var remaining = fooArray.length; 
    while (remaining-- > 0) 
    { 
     foo->c = foo->a + foo->b; 
     foo++; // foo now points to the next element in the array... 
    } 
} 

El beneficio principal aquí es que hemos reducido índice de matriz a cabo la comprobación del todo ..

Si bien es muy En rendimiento, este tipo de código es difícil de manejar, puede ser bastante peligroso (inseguro) y rompe algunas pautas fundamentales (estructura mutable). Pero sin duda hay escenarios donde esto es apropiado ...

Answer 3

algunas mediciones de rendimiento

Las ventajas de rendimiento no son tan grandes como se podría pensar.

Realicé algunas mediciones de rendimiento del acceso a arreglos gestionados normales frente a los indicadores inseguros en C#.

---

Los resultados de una acumulación de ejecutar fuera de Visual Studio 2010, .NET 4, utilizando un Cualquier CPU | Versión de compilación en la siguiente especificación para PC: PC basada en x64, 1 procesador de cuatro núcleos. Familia Intel64 6 Modelo 23 Stepping 10 GenuineIntel ~ 2833 Mhz.

Linear array access 
00:00:07.1053664 for Normal 
00:00:07.1197401 for Unsafe *(p + i) 

Linear array access - with pointer increment 
00:00:07.1174493 for Normal 
00:00:10.0015947 for Unsafe (*p++) 

Random array access 
00:00:42.5559436 for Normal 
00:00:40.5632554 for Unsafe 

Random array access using Parallel.For(), with 4 processors 
00:00:10.6896303 for Normal 
00:00:10.1858376 for Unsafe 

Tenga en cuenta que el lenguaje inseguro *(p++) realidad corrió más lento. Supongo que esto rompió una optimización del compilador que combinaba la variable de bucle y el acceso al puntero (generado por el compilador) en la versión segura.

Código fuente disponible en github.

Answer 4

Bueno, sugeriría leer este blog post: MSDN blogs: Array Bounds Check Elimination in the CLR

Esto aclara cómo grada controles se realizan en C#. Además, las pruebas de Thomas Bratts me parecen inútiles (mirando el código) ya que el JIT elimina en sus bucles de 'salvado' los controles encuadernados de todos modos.

Answer 5

Estoy usando un código no seguro para el código de manipulación de video. En dicho código, desea que se ejecute lo más rápido posible sin controles internos de valores, etc.Sin atributos inseguros, mi could no podría mantenerse al día con la transmisión de video a 30 fps o 60 fps. (dependiendo de la cámara usada).

Pero debido a la velocidad es ampliamente utilizado por personas que codifican gráficos.