Quería saltar aquí entre estas respuestas ya excelentes y admitir que he tomado el enfoque feo de trabajar realmente hacia atrás al antipatrón de cambiar el código polimórfico switcheso if/elseramas con ganancias medidas. Pero no hice esto al por mayor, solo para los caminos más críticos. No tiene que ser tan blanco y negro.
Como descargo de responsabilidad, trabajo en áreas como el trazado de rayos donde la corrección no es tan difícil de lograr (y a menudo es borrosa y aproximada de todos modos), mientras que la velocidad es a menudo una de las cualidades más competitivas buscadas. Una reducción en los tiempos de renderizado es a menudo una de las solicitudes más comunes de los usuarios, con nosotros constantemente rascándonos la cabeza y descubriendo cómo lograrlo para los caminos medidos más críticos.
Refactorización polimórfica de condicionales
Primero, vale la pena entender por qué el polimorfismo puede ser preferible desde un aspecto de mantenimiento que la ramificación condicional ( switcho un conjunto de if/elsedeclaraciones). El principal beneficio aquí es la extensibilidad .
Con el código polimórfico, podemos introducir un nuevo subtipo en nuestra base de código, agregar instancias de él a alguna estructura de datos polimórficos y hacer que todo el código polimórfico existente siga funcionando automáticamente sin más modificaciones. Si tiene un montón de código disperso en una base de código grande que se asemeja a la forma de, "Si este tipo es 'foo', hágalo" , puede encontrarse con una carga horrible de actualizar 50 secciones dispares de código para introducir un nuevo tipo de cosas, y todavía terminan perdiendo algunas
Los beneficios de mantenimiento del polimorfismo naturalmente disminuyen aquí si solo tiene un par o incluso una sección de su base de código que necesita hacer tales verificaciones de tipo.
Barrera de optimización
Sugeriría no mirar esto desde el punto de vista de ramificar y canalizar tanto, y mirarlo más desde la mentalidad de diseño del compilador de las barreras de optimización. Hay formas de mejorar la predicción de rama que se aplica a ambos casos, como ordenar los datos según el subtipo (si encaja en una secuencia).
Lo que difiere más entre estas dos estrategias es la cantidad de información que el optimizador tiene de antemano. Una llamada de función que se conoce proporciona mucha más información, una llamada de función indirecta que llama a una función desconocida en tiempo de compilación conduce a una barrera de optimización.
Cuando se conoce la función que se llama, los compiladores pueden borrar la estructura y reducirla a fragmentos, alineando llamadas, eliminando posibles sobrecargas de alias, haciendo un mejor trabajo en la asignación de instrucción / registro, posiblemente incluso reorganizando bucles y otras formas de ramas, generando LUT en miniatura codificadas cuando sea apropiado (algo que GCC 5.3 recientemente me sorprendió con una switchdeclaración al usar una LUT codificada de datos para los resultados en lugar de una tabla de salto).
Algunos de esos beneficios se pierden cuando comenzamos a introducir incógnitas en tiempo de compilación en la mezcla, como en el caso de una llamada de función indirecta, y ahí es donde la ramificación condicional puede ofrecer una ventaja.
Optimización de memoria
Tomemos un ejemplo de un videojuego que consiste en procesar una secuencia de criaturas repetidamente en un ciclo cerrado. En tal caso, podríamos tener algún contenedor polimórfico como este:
vector<Creature*> creatures;
Nota: por simplicidad, evité unique_ptraquí.
... donde Creaturees un tipo de base polimórfica. En este caso, una de las dificultades con los contenedores polimórficos es que a menudo desean asignar memoria para cada subtipo por separado / individualmente (por ejemplo: usar el lanzamiento predeterminado operator newpara cada criatura individual).
Eso a menudo hará que la primera prioridad para la optimización (en caso de que la necesitemos) se base en la memoria en lugar de ramificarse. Una estrategia aquí es utilizar un asignador fijo para cada subtipo, fomentando una representación contigua al asignar en grandes fragmentos y agrupando la memoria para cada subtipo que se asigna. Con tal estrategia, definitivamente puede ayudar clasificar este creaturescontenedor por subtipo (así como por dirección), ya que eso no solo mejora la predicción de ramas sino que también mejora la localidad de referencia (permitiendo el acceso a múltiples criaturas del mismo subtipo) desde una sola línea de caché antes del desalojo).
Desvirtualización parcial de estructuras de datos y bucles
Digamos que realizó todos estos movimientos y aún desea más velocidad. Vale la pena señalar que cada paso que aventuramos aquí está degradando la mantenibilidad, y ya estaremos en una etapa de molienda de metales con rendimientos de rendimiento decrecientes. Por lo tanto, debe haber una demanda de rendimiento bastante significativa si pisamos este territorio, donde estamos dispuestos a sacrificar la capacidad de mantenimiento aún más para obtener ganancias de rendimiento cada vez más pequeñas.
Sin embargo, el siguiente paso para intentar (y siempre con la voluntad de respaldar nuestros cambios si no ayuda en absoluto) podría ser la desvirtualización manual.
Consejo de control de versiones: a menos que sea mucho más experto en optimización que yo, puede valer la pena crear una nueva sucursal en este punto con la voluntad de deshacerse de ella si nuestros esfuerzos de optimización fallan, lo que muy bien puede suceder. Para mí, todo es prueba y error después de este tipo de puntos, incluso con un perfilador en la mano.
Sin embargo, no tenemos que aplicar esta mentalidad al por mayor. Continuando con nuestro ejemplo, digamos que este videojuego consiste principalmente en criaturas humanas, con mucho. En tal caso, podemos desvirtualizar solo criaturas humanas al izarlas y crear una estructura de datos separada solo para ellas.
vector<Human> humans; // common case
vector<Creature*> other_creatures; // additional rare-case creatures
Esto implica que todas las áreas de nuestra base de código que necesitan procesar criaturas necesitan un bucle de casos especiales separado para las criaturas humanas. Sin embargo, eso elimina la sobrecarga dinámica de despacho (o quizás, más apropiadamente, la barrera de optimización) para los humanos, que son, con mucho, el tipo de criatura más común. Si estas áreas son numerosas y podemos pagarlo, podríamos hacer esto:
vector<Human> humans; // common case
vector<Creature*> other_creatures; // additional rare-case creatures
vector<Creature*> creatures; // contains humans and other creatures
... si podemos permitirnos esto, los caminos menos críticos pueden permanecer como están y simplemente procesar todos los tipos de criaturas de forma abstracta. Las rutas críticas pueden procesarse humansen un bucle y other_creaturesen un segundo bucle.
Podemos extender esta estrategia según sea necesario y potencialmente exprimir algunas ganancias de esta manera, sin embargo, vale la pena señalar cuánto estamos degradando la mantenibilidad en el proceso. El uso de plantillas de funciones aquí puede ayudar a generar el código para humanos y criaturas sin duplicar la lógica manualmente.
Desvirtualización parcial de clases
Algo que hice hace años que fue realmente asqueroso, y ya ni siquiera estoy seguro de que sea beneficioso (esto fue en la era C ++ 03), fue la desvirtualización parcial de una clase. En ese caso, ya estábamos almacenando un ID de clase con cada instancia para otros fines (se accede a través de un descriptor de acceso en la clase base que no era virtual). Allí hicimos algo análogo a esto (mi memoria es un poco confusa):
switch (obj->type())
{
case id_common_type:
static_cast<CommonType*>(obj)->non_virtual_do_something();
break;
...
default:
obj->virtual_do_something();
break;
}
... donde virtual_do_somethingse implementó para llamar a versiones no virtuales en una subclase. Es asqueroso, lo sé, hacer un downcast estático explícito para desvirtualizar una llamada de función. No tengo idea de cuán beneficioso es esto ahora, ya que no he probado este tipo de cosas en años. Con una exposición al diseño orientado a datos, descubrí que la estrategia anterior de dividir las estructuras de datos y los bucles de manera fría / caliente es mucho más útil, abriendo más puertas para estrategias de optimización (y mucho menos fea).
Venta al por mayor Desvirtualización
Debo admitir que nunca he llegado tan lejos aplicando una mentalidad de optimización, por lo que no tengo idea de los beneficios. He evitado las funciones indirectas en previsión en los casos en que sabía que solo habría un conjunto central de condicionales (por ejemplo: procesamiento de eventos con solo un evento de procesamiento de lugar central), pero nunca comencé con una mentalidad polimórfica y optimizado por completo Hasta aquí.
Teóricamente, los beneficios inmediatos aquí podrían ser una forma potencialmente más pequeña de identificar un tipo que un puntero virtual (por ejemplo, un solo byte si puede comprometerse con la idea de que hay 256 tipos únicos o menos) además de eliminar por completo estas barreras de optimización .
También podría ayudar en algunos casos escribir código más fácil de mantener (en comparación con los ejemplos optimizados de desvirtualización manual anteriores) si solo usa una switchdeclaración central sin tener que dividir sus estructuras de datos y bucles según el subtipo, o si hay un pedido -dependencia en estos casos donde las cosas tienen que ser procesadas en un orden preciso (incluso si eso hace que nos ramifiquemos por todos lados). Esto sería para casos en los que no tienes muchos lugares que necesiten hacer switch.
En general, no recomendaría esto incluso con una mentalidad muy crítica de rendimiento a menos que sea razonablemente fácil de mantener. "Fácil de mantener" tendería a depender de dos factores dominantes:
- No tener una necesidad de extensibilidad real (por ejemplo, saber con seguridad que tiene exactamente 8 tipos de cosas para procesar, y nunca más).
- No tener muchos lugares en su código que necesiten verificar estos tipos (ej .: un lugar central).
... sin embargo, recomiendo el escenario anterior en la mayoría de los casos e iterando hacia soluciones más eficientes mediante la desvirtualización parcial, según sea necesario. Le da mucho más espacio para respirar para equilibrar las necesidades de extensibilidad y mantenibilidad con el rendimiento.
Funciones virtuales frente a punteros de función
Para colmo, noté aquí que había una discusión sobre las funciones virtuales frente a los punteros de función. Es cierto que las funciones virtuales requieren un poco de trabajo extra para llamar, pero eso no significa que sean más lentas. Contra-intuitivamente, incluso puede hacerlos más rápidos.
Aquí es contra-intuitivo porque estamos acostumbrados a medir el costo en términos de instrucciones sin prestar atención a la dinámica de la jerarquía de memoria que tiende a tener un impacto mucho más significativo.
Si estamos comparando un classcon 20 funciones virtuales versus un structque almacena 20 punteros de función, y ambos se instancian varias veces, la sobrecarga de memoria de cada classinstancia en este caso 8 bytes para el puntero virtual en máquinas de 64 bits, mientras que la memoria la sobrecarga del structes de 160 bytes.
El costo práctico puede haber muchos más errores de caché obligatorios y no obligatorios con la tabla de punteros de función frente a la clase que usa funciones virtuales (y posiblemente errores de página en una escala de entrada lo suficientemente grande). Ese costo tiende a eclipsar el trabajo ligeramente adicional de indexar una tabla virtual.
También he tratado con bases de código C heredadas (anteriores a las que tengo) en las que convertirlas en structspunteros de funciones, e instanciarlas en numerosas ocasiones, en realidad proporcionó ganancias de rendimiento significativas (más del 100% de mejoras) al convertirlas en clases con funciones virtuales, y simplemente debido a la reducción masiva en el uso de la memoria, el aumento de la capacidad de almacenamiento en caché, etc.
Por otro lado, cuando las comparaciones se vuelven más acerca de manzanas con manzanas, también he encontrado que la mentalidad opuesta de traducir de una mentalidad de función virtual C ++ a una mentalidad de puntero de función de estilo C es útil en este tipo de escenarios:
class Functionoid
{
public:
virtual ~Functionoid() {}
virtual void operator()() = 0;
};
... donde la clase estaba almacenando una única función invalidable (o dos si contamos el destructor virtual). En esos casos, definitivamente puede ayudar en los caminos críticos para convertir eso en esto:
void (*func_ptr)(void* instance_data);
... idealmente detrás de una interfaz de tipo seguro para ocultar los lanzamientos peligrosos void*.
En aquellos casos en los que estamos tentados a usar una clase con una sola función virtual, puede ayudar rápidamente usar punteros de función en su lugar. Una gran razón no es necesariamente el costo reducido de llamar a un puntero de función. Es porque ya no enfrentamos la tentación de asignar cada funciónoide separada en las regiones dispersas del montón si los estamos agregando en una estructura persistente. Este tipo de enfoque puede hacer que sea más fácil evitar la sobrecarga de fragmentación de memoria asociada con el montón si los datos de la instancia son homogéneos, por ejemplo, y solo varía el comportamiento.
Así que definitivamente hay algunos casos en los que el uso de punteros de función puede ayudar, pero a menudo lo he encontrado al revés si comparamos un montón de tablas de punteros de función con una única tabla virtual que solo requiere que se almacene un puntero por instancia de clase . Esa vtable a menudo estará sentada en una o más líneas de caché L1 también en bucles estrechos.
Conclusión
De todos modos, ese es mi pequeño giro sobre este tema. Recomiendo aventurarse en estas áreas con precaución. Confíe en las medidas, no en el instinto, y dada la forma en que estas optimizaciones a menudo degradan la capacidad de mantenimiento, solo llegan tan lejos como puede permitirse (y una ruta inteligente sería errar por el lado de la capacidad de mantenimiento).
