c++ - sistemas - pc de alto desempeño

¿Boost/STL es lento con respecto a la informática de alto rendimiento? (1)

boost y las librerías estándar de C ++ se usan para producir implementaciones de producción extremadamente rápidas. Por supuesto, uno podría mejorar esas implementaciones en escenarios específicos ; esto es análogo a escribir su propio asignador cuando sabe cómo difiere su ejecución de los asignadores de propósito general, y cómo optimizar ese uso. Por lo tanto, uno puede, por supuesto, analizar el problema y producir una implementación optimizada que sea más rápida que las implementaciones de propósito general (o impulsar).

Por supuesto, cualquier biblioteca también puede ser mal utilizada, lo que podría resultar en una ejecución comprometida. En resumen, las implementaciones boost (una gran colección de bibliotecas) son un excelente punto de partida para implementaciones rápidas. Si necesita que sea más rápido que aumentar, determine el problema y mejore.

Muchos desarrolladores de C ++ están preocupados por el rendimiento; en general, más que otros idiomas. boost es generalmente bien considerado, revisado por pares, y las implementaciones se utilizan para probar y formar la base de las funciones estándar de la biblioteca.

-----

Gracias a Justin por permitirme compartir su respuesta sobre la pregunta cerrada: ^{_{- Seth}}

Todo lo contrario.
Boost no se trata de cinturones de seguridad.
Boost se trata de componentes de software de alto nivel , con un alto nivel de abstracción. Esto evita el bloqueo de biblioteca habitual visto con otros marcos / bibliotecas ¹ .
Por ejemplo, su biblioteca de Boost Graph no requiere que cambie las estructuras de datos: puede usar / adaptar cualquier estructura de datos que tenga un buen rendimiento para su aplicación. En el peor de los casos, es posible que deba escribir una clase de rasgos para ayudar a Boost con la interpretación; Es precisamente este rasgo (común a las bibliotecas de plantillas modernas) lo que hace que Boost funcione como ninguna otra cosa en la práctica : no habrá tanta discrepancia en la impedancia de la biblioteca . Esto está directamente en línea con los nuevos conceptos de C ++ 11 sobre subprocesamiento y semántica de movimientos: evitando incluso los casos más elementales de copia de datos.
Además, todas estas bibliotecas respetan sus propias implementaciones de asignadores, lo que permite un rendimiento inigualable de administración de memoria. Puede alinear vectores int de 128 bits en C #, pero tendrá que pasar por muchos aros ² y no hay manera de que pueda funcionar con las API de marco.
En C ++ pagas solo por lo que usas, y Boost está completamente en ese espíritu.
Mmmm, creo que todavía no he enfatizado lo suficiente, pero ya terminé por ahora.
Permítanme cerrar mirándolo desde el otro lado: en C # es mucho más difícil escribir código de ejecución, porque es mucho más difícil ver lo que sucede detrás de escena.
Una vez que se pone detrás de las escenas ( modo inseguro , código IL ) posiblemente será menos seguro que en C ++, porque en C ++ hay una política transparente de qué sucede dónde y cómo. En C # no puedes confiar en un int* que tienes hace una línea (porque el recolector de basura pudo haber movido tu queso); No hay forma de saber qué harán el compilador y / o el motor JIT de su buen código genérico ³ .
En resumen: puedes escribir código incorrecto en cualquier lugar, pero no se puede culpar a Boost. Solo se puede culpar a STL por un desempeño en bruto insano ⁴ .
¹ PoCo, Qt, MFC, WTL, whatnot ....
² Mono SIMD
³ Incluye numerosas áreas que son casi patéticas y que violan el ''Principio de la menor sorpresa'' a lo grande (por ejemplo, cuando el blog vuelve a estar en línea )
⁴ Ese std::copy se traducirá estáticamente en la mejor implementación basada en SSE4, MOVSW o simplemente memcpy que el dinero puede comprar, y sin embargo, ni siquiera tiene que escribir una sola letra diferente de copiar un istream a un set , por así decirlo.

Disculpas por otra cita en el foro de Internet , pero pensé que era interesante y quería preguntar:

C ++ es más rápido si tira las características de "seguridad" de los lenguajes de programación y evita cosas como STL y Boost. En bytes sin formato a bytes, C ++ es más rápido, pero también lo es C.
En el momento en que agrega el equipaje de STL y Boost, es más lento que el código C # bien escrito. La ventaja que tienen C # JIT y Java jit es que esas características de seguridad están bien optimizadas. Las características de seguridad de C ++ se basan en la optimización del compilador.
Por lo tanto, si no tiene cuidado con su STL y el código de Boost, tendrá una falla en la aplicación.

Estoy de acuerdo en librarme de las características de seguridad, pero he visto muchos anuncios de trabajo de alta frecuencia y todos me piden la experiencia de Boost. Sin duda, Boost no puede ser algo malo para producir código rápido? ¿O esta persona simplemente está afirmando teóricamente si simplemente manipulaste a nivel de byte sería más rápido?

Editar: La cita es sobre STL y Boost, así que agregué la etiqueta STL.