visual studio - probable/improbable equivalente para MSVC
visual-studio gcc (5)
Yo digo solo punt
No hay nada como eso. Hay __assume() , pero no lo use, es un tipo diferente de directiva optimizadora.
Realmente, la razón por la cual el gnu builtin está envuelto en una macro es para que puedas deshacerte de ella automáticamente si __GNUC__ no está definido. No hay nada que sea necesario sobre esas macros y apuesto a que no notará la diferencia de tiempo de ejecución.
Resumen
Deshazte de (null out) *likely en un no-GNU. No te lo perderás.
El compilador de GCC admite la instrucción __builtin_expect que se usa para definir macros probables e improbables.
p.ej.
#define likely(expr) __builtin_expect(!(expr), 0)
#define unlikely(expr) __builtin_expect((expr), 0)
¿Hay una declaración equivalente para el compilador de Microsoft Visual C, o algo equivalente?
De acuerdo con http://www.akkadia.org/drepper/cpumemory.pdf (página 57), todavía tiene sentido utilizar la predicción de bifurcación estática incluso si la CPU predice correctamente de forma dinámica. La razón de esto es que la memoria caché L1i se usará aún más eficientemente si la predicción estática se hizo correctamente.
De acuerdo con Branch and Loop Reorganization to Prevent Mispredicts documento de Intel:
Para escribir de manera efectiva su código para aprovechar estas reglas, al escribir if-else o cambiar las declaraciones, marque primero los casos más comunes y trabaje progresivamente hasta llegar a los menos comunes.
Desafortunadamente no puedes escribir algo como
#define if_unlikely(cond) if (!(cond)); else
porque el optimizador de MSVC a partir de VS10 ignora tal "sugerencia".
Como prefiero lidiar con los errores primero en mi código, parece que escribo un código menos eficiente. Afortunadamente, la segunda vez que la CPU se encuentra con la sucursal, usará sus estadísticas en lugar de una pista estática.
El estándar C ++ 20 incluirá atributos de predicción de ramificación [[likely]] y [[unlikely]] .
La última revisión de la propuesta de atributo se puede encontrar en http://wg21.link/p0479
La propuesta de atributo original se puede encontrar en http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0479r0.html
Los programadores deberían preferir PGO. Los atributos pueden reducir el rendimiento fácilmente si se aplican incorrectamente o más tarde se vuelven incorrectos cuando cambia el programa.
__assume() debe ser similar.
Sin embargo, si desea hacer esto realmente bien, debería utilizar la Optimización guiada de perfil en lugar de sugerencias estáticas.