c# - ejemplo - El operador ternario es dos veces más lento que un bloque if-else?
return operador ternario (9)
EDITAR: Todo cambio ... ver más abajo.
No puedo reproducir sus resultados en el CLR x64, pero puedo hacerlo en x86. En x64 puedo ver una pequeña diferencia (menos del 10%) entre el operador condicional y if / else, pero es mucho más pequeño de lo que está viendo.
He hecho los siguientes cambios potenciales:
- Ejecutar en una aplicación de consola
- Construya con
/o+ /debug-, y ejecute fuera del depurador - Ejecuta ambas piezas de código una vez para JIT, luego muchas veces para mayor precisión
- Utilizar
Stopwatch
Resultados con /platform:x64 (sin las líneas "ignorar"):
if/else with 1 iterations: 17ms
conditional with 1 iterations: 19ms
if/else with 1000 iterations: 17875ms
conditional with 1000 iterations: 19089ms
Resultados con /platform:x86 (sin las líneas "ignorar"):
if/else with 1 iterations: 18ms
conditional with 1 iterations: 49ms
if/else with 1000 iterations: 17901ms
conditional with 1000 iterations: 47710ms
Los detalles de mi sistema:
- x64 i7-2720QM CPU a 2.20GHz
- Windows 8 de 64 bits
- .NET 4.5
Así que, a diferencia de antes, creo que estás viendo una diferencia real, y todo tiene que ver con el JIT x86. No me gustaría decir exactamente qué está causando la diferencia. Puedo actualizar la publicación más adelante con más detalles si puedo molestarme en entrar en cordbg :)
Curiosamente, sin clasificar primero el arreglo, termino con pruebas que demoran aproximadamente 4.5 veces, al menos en x64. Mi conjetura es que esto tiene que ver con la predicción de la rama.
Código:
using System;
using System.Diagnostics;
class Test
{
static void Main()
{
Random r = new Random(0);
int[] array = new int[20000000];
for(int i = 0; i < array.Length; i++)
{
array[i] = r.Next(int.MinValue, int.MaxValue);
}
Array.Sort(array);
// JIT everything...
RunIfElse(array, 1);
RunConditional(array, 1);
// Now really time it
RunIfElse(array, 1000);
RunConditional(array, 1000);
}
static void RunIfElse(int[] array, int iterations)
{
long value = 0;
Stopwatch sw = Stopwatch.StartNew();
for (int x = 0; x < iterations; x++)
{
foreach (int i in array)
{
if (i > 0)
{
value += 2;
}
else
{
value += 3;
}
}
}
sw.Stop();
Console.WriteLine("if/else with {0} iterations: {1}ms",
iterations,
sw.ElapsedMilliseconds);
// Just to avoid optimizing everything away
Console.WriteLine("Value (ignore): {0}", value);
}
static void RunConditional(int[] array, int iterations)
{
long value = 0;
Stopwatch sw = Stopwatch.StartNew();
for (int x = 0; x < iterations; x++)
{
foreach (int i in array)
{
value += i > 0 ? 2 : 3;
}
}
sw.Stop();
Console.WriteLine("conditional with {0} iterations: {1}ms",
iterations,
sw.ElapsedMilliseconds);
// Just to avoid optimizing everything away
Console.WriteLine("Value (ignore): {0}", value);
}
}
Leí en todas partes que se supone que el operador ternario es más rápido que, o al menos el mismo que, su equivalente en el bloque else .
Sin embargo, hice la siguiente prueba y descubrí que no es el caso:
Random r = new Random();
int[] array = new int[20000000];
for(int i = 0; i < array.Length; i++)
{
array[i] = r.Next(int.MinValue, int.MaxValue);
}
Array.Sort(array);
long value = 0;
DateTime begin = DateTime.UtcNow;
foreach (int i in array)
{
if (i > 0)
{
value += 2;
}
else
{
value += 3;
}
// if-else block above takes on average 85 ms
// OR I can use a ternary operator:
// value += i > 0 ? 2 : 3; // takes 157 ms
}
DateTime end = DateTime.UtcNow;
MessageBox.Show("Measured time: " + (end-begin).TotalMilliseconds + " ms./r/nResult = " + value.ToString());
Mi computadora tomó 85 ms para ejecutar el código de arriba. Pero si comento el fragmento if - else , y descomente la línea del operador ternario, tomará aproximadamente 157 ms.
¿Por qué está pasando esto?
Ejecutar sin depurar ctrl + F5 parece que el depurador ralentiza tanto el ifs como el ternario significativamente, pero parece que ralentiza mucho más al operador ternario.
Cuando ejecuto el siguiente código aquí están mis resultados. Creo que la pequeña diferencia de milisegundos se debe a que el compilador optimiza max = max y lo elimina, pero probablemente no esté haciendo esa optimización para el operador ternario. Si alguien pudiera revisar el ensamblaje y confirmar esto, sería increíble.
--Run #1--
Type | Milliseconds
Ternary 706
If 704
%: .9972
--Run #2--
Type | Milliseconds
Ternary 707
If 704
%: .9958
--Run #3--
Type | Milliseconds
Ternary 706
If 704
%: .9972
Código
for (int t = 1; t != 10; t++)
{
var s = new System.Diagnostics.Stopwatch();
var r = new Random(123456789); //r
int[] randomSet = new int[1000]; //a
for (int i = 0; i < 1000; i++) //n
randomSet[i] = r.Next(); //dom
long _ternary = 0; //store
long _if = 0; //time
int max = 0; //result
s.Start();
for (int q = 0; q < 1000000; q++)
{
for (int i = 0; i < 1000; i++)
max = max > randomSet[i] ? max : randomSet[i];
}
s.Stop();
_ternary = s.ElapsedMilliseconds;
max = 0;
s = new System.Diagnostics.Stopwatch();
s.Start();
for (int q = 0; q < 1000000; q++)
{
for (int i = 0; i < 1000; i++)
if (max > randomSet[i])
max = max; // I think the compiler may remove this but not for the ternary causing the speed difference.
else
max = randomSet[i];
}
s.Stop();
_if = s.ElapsedMilliseconds;
Console.WriteLine("--Run #" + t+"--");
Console.WriteLine("Type | Milliseconds/nTernary {0}/nIf {1}/n%: {2}", _ternary, _if,((decimal)_if/(decimal)_ternary).ToString("#.####"));
}
El código ensamblador generado contará la historia:
a = (b > c) ? 1 : 0;
Genera:
mov edx, DWORD PTR a[rip]
mov eax, DWORD PTR b[rip]
cmp edx, eax
setg al
Mientras:
if (a > b) printf("a");
else printf("b");
Genera:
mov edx, DWORD PTR a[rip]
mov eax, DWORD PTR b[rip]
cmp edx, eax
jle .L4
;printf a
jmp .L5
.L4:
;printf b
.L5:
Por lo tanto, el ternario puede ser más corto y más rápido simplemente porque usa menos instrucciones y no salta si está buscando verdadero / falso. Si usa valores distintos de 1 y 0, obtendrá el mismo código que if / else, por ejemplo:
a = (b > c) ? 2 : 3;
Genera:
mov edx, DWORD PTR b[rip]
mov eax, DWORD PTR c[rip]
cmp edx, eax
jle .L6
mov eax, 2
jmp .L7
.L6:
mov eax, 3
.L7:
Que es lo mismo que el if / else.
En cuanto a la IL generada, hay 16 operaciones menos en eso que en la sentencia if / else (copiar y pegar el código de @SonSkeet). Sin embargo, eso no significa que deba ser un proceso más rápido!
Para resumir las diferencias en IL, el método if / else se traduce a casi lo mismo que lee el código C # (realizando la adición dentro de la rama) mientras que el código condicional carga 2 o 3 en la pila (dependiendo del valor) y luego lo agrega al valor fuera del condicional.
La otra diferencia es la instrucción de bifurcación utilizada. El método if / else utiliza un brtrue (rama si es verdadero) para saltar sobre la primera condición, y una rama incondicional para saltar desde la primera de la instrucción if. El código condicional usa un bgt (rama si es mayor que) en lugar de un brtrue, lo que podría ser una comparación más lenta.
También (habiendo leído recientemente sobre la predicción de la rama) puede haber una penalización de rendimiento para la rama que es más pequeña. La rama condicional solo tiene 1 instrucción dentro de la rama pero el if / else tiene 7. Esto también explicaría por qué hay una diferencia entre usar long y int, porque el cambio a un int reduce el número de instrucciones en las ramas if / else en 1 (haciendo la lectura anticipada menos)
En el siguiente código, si / else parece ser aproximadamente 1.4 veces más rápido que el operador ternario. Sin embargo, descubrí que la introducción de una variable temporal reduce el tiempo de ejecución del operador ternario aproximadamente 1,4 veces:
Si / Else: 98 ms
Ternario: 141 ms
Ternario con temp var: 100 ms
using System;
using System.Diagnostics;
namespace ConsoleApplicationTestIfElseVsTernaryOperator
{
class Program
{
static void Main(string[] args)
{
Random r = new Random(0);
int[] array = new int[20000000];
for (int i = 0; i < array.Length; i++)
{
array[i] = r.Next(int.MinValue, int.MaxValue);
}
Array.Sort(array);
long value;
Stopwatch stopwatch = new Stopwatch();
value = 0;
stopwatch.Restart();
foreach (int i in array)
{
if (i > 0)
{
value += 2;
}
else
{
value += 3;
}
// 98 ms
}
stopwatch.Stop();
Console.WriteLine("If/Else: " + stopwatch.ElapsedMilliseconds.ToString() + " ms");
value = 0;
stopwatch.Restart();
foreach (int i in array)
{
value += (i > 0) ? 2 : 3;
// 141 ms
}
stopwatch.Stop();
Console.WriteLine("Ternary: " + stopwatch.ElapsedMilliseconds.ToString() + " ms");
value = 0;
int tempVar = 0;
stopwatch.Restart();
foreach (int i in array)
{
tempVar = (i > 0) ? 2 : 3;
value += tempVar;
// 100ms
}
stopwatch.Stop();
Console.WriteLine("Ternary with temp var: " + stopwatch.ElapsedMilliseconds.ToString() + " ms");
Console.ReadKey(true);
}
}
}
Hice lo que hizo Jon Skeet y ejecuté 1 iteración y 1,000 iteraciones y obtuve un resultado diferente tanto de OP como de Jon. En la mía, el ternario es un poco más rápido. A continuación se muestra el código exacto:
static void runIfElse(int[] array, int iterations)
{
long value = 0;
Stopwatch ifElse = new Stopwatch();
ifElse.Start();
for (int c = 0; c < iterations; c++)
{
foreach (int i in array)
{
if (i > 0)
{
value += 2;
}
else
{
value += 3;
}
}
}
ifElse.Stop();
Console.WriteLine(String.Format("Elapsed time for If-Else: {0}", ifElse.Elapsed));
}
static void runTernary(int[] array, int iterations)
{
long value = 0;
Stopwatch ternary = new Stopwatch();
ternary.Start();
for (int c = 0; c < iterations; c++)
{
foreach (int i in array)
{
value += i > 0 ? 2 : 3;
}
}
ternary.Stop();
Console.WriteLine(String.Format("Elapsed time for Ternary: {0}", ternary.Elapsed));
}
static void Main(string[] args)
{
Random r = new Random();
int[] array = new int[20000000];
for (int i = 0; i < array.Length; i++)
{
array[i] = r.Next(int.MinValue, int.MaxValue);
}
Array.Sort(array);
long value = 0;
runIfElse(array, 1);
runTernary(array, 1);
runIfElse(array, 1000);
runTernary(array, 1000);
Console.ReadLine();
}
La salida de mi programa:
Tiempo transcurrido para If-Else: 00: 00: 00.0140543
Tiempo transcurrido para ternario: 00: 00: 00.0136723
Tiempo transcurrido para If-Else: 00: 00: 14.0167870
Tiempo transcurrido para ternario: 00: 00: 13.9418520
Otra carrera en milisegundos:
Tiempo transcurrido para If-Else: 20
Tiempo transcurrido para ternario: 19
Tiempo transcurrido para If-Else: 13854
Tiempo transcurrido para ternario: 13610
Esto se está ejecutando en XP de 64 bits, y corrí sin depurar.
Editar - Ejecutando en x86:
Hay una gran diferencia con x86. Esto se hizo sin depurar y en la misma máquina xp de 64 bits que antes, pero construido para CPU x86. Esto se parece más a OP''s.
Tiempo transcurrido para If-Else: 18
Tiempo transcurrido para el ternario: 35
Tiempo transcurrido para If-Else: 20512
Tiempo transcurrido para ternario: 32673
La diferencia realmente no tiene mucho que ver con if / else vs ternary.
Mirando los desensamblamientos ininteligibles (no lo rechazaré aquí, por favor vea la respuesta de @ 280Z28), resulta que está comparando manzanas y naranjas . En un caso, crea dos operaciones diferentes += con valores constantes y la que elija depende de una condición, y en el otro caso, crea un += donde el valor a agregar depende de una condición.
Si realmente quieres comparar si / else vs ternary, esta sería una comparación más justa (ahora ambos serán igualmente "lentos", o incluso podríamos decir que ternary es un poco más rápido):
int diff;
if (i > 0)
diff = 2;
else
diff = 3;
value += diff;
contra
value += i > 0 ? 2 : 3;
Ahora el desmontaje de if/else convierte en como se muestra a continuación. Tenga en cuenta que esto es un poco peor que el caso ternario, ya que también dejó de usar los registros para la variable de bucle ( i ).
if (i > 0)
0000009d cmp dword ptr [ebp-20h],0
000000a1 jle 000000AD
{
diff = 2;
000000a3 mov dword ptr [ebp-24h],2
000000aa nop
000000ab jmp 000000B4
}
else
{
diff = 3;
000000ad mov dword ptr [ebp-24h],3
}
value += diff;
000000b4 mov eax,dword ptr [ebp-18h]
000000b7 mov edx,dword ptr [ebp-14h]
000000ba mov ecx,dword ptr [ebp-24h]
000000bd mov ebx,ecx
000000bf sar ebx,1Fh
000000c2 add eax,ecx
000000c4 adc edx,ebx
000000c6 mov dword ptr [ebp-18h],eax
000000c9 mov dword ptr [ebp-14h],edx
000000cc inc dword ptr [ebp-28h]
Para responder a esta pregunta, examinaremos el código de ensamblaje producido por los JIT X86 y X64 para cada uno de estos casos.
X86, si / entonces
32: foreach (int i in array)
0000007c 33 D2 xor edx,edx
0000007e 83 7E 04 00 cmp dword ptr [esi+4],0
00000082 7E 1C jle 000000A0
00000084 8B 44 96 08 mov eax,dword ptr [esi+edx*4+8]
33: {
34: if (i > 0)
00000088 85 C0 test eax,eax
0000008a 7E 08 jle 00000094
35: {
36: value += 2;
0000008c 83 C3 02 add ebx,2
0000008f 83 D7 00 adc edi,0
00000092 EB 06 jmp 0000009A
37: }
38: else
39: {
40: value += 3;
00000094 83 C3 03 add ebx,3
00000097 83 D7 00 adc edi,0
0000009a 42 inc edx
32: foreach (int i in array)
0000009b 39 56 04 cmp dword ptr [esi+4],edx
0000009e 7F E4 jg 00000084
30: for (int x = 0; x < iterations; x++)
000000a0 41 inc ecx
000000a1 3B 4D F0 cmp ecx,dword ptr [ebp-10h]
000000a4 7C D6 jl 0000007C
X86, ternario
59: foreach (int i in array)
00000075 33 F6 xor esi,esi
00000077 83 7F 04 00 cmp dword ptr [edi+4],0
0000007b 7E 2D jle 000000AA
0000007d 8B 44 B7 08 mov eax,dword ptr [edi+esi*4+8]
60: {
61: value += i > 0 ? 2 : 3;
00000081 85 C0 test eax,eax
00000083 7F 07 jg 0000008C
00000085 BA 03 00 00 00 mov edx,3
0000008a EB 05 jmp 00000091
0000008c BA 02 00 00 00 mov edx,2
00000091 8B C3 mov eax,ebx
00000093 8B 4D EC mov ecx,dword ptr [ebp-14h]
00000096 8B DA mov ebx,edx
00000098 C1 FB 1F sar ebx,1Fh
0000009b 03 C2 add eax,edx
0000009d 13 CB adc ecx,ebx
0000009f 89 4D EC mov dword ptr [ebp-14h],ecx
000000a2 8B D8 mov ebx,eax
000000a4 46 inc esi
59: foreach (int i in array)
000000a5 39 77 04 cmp dword ptr [edi+4],esi
000000a8 7F D3 jg 0000007D
57: for (int x = 0; x < iterations; x++)
000000aa FF 45 E4 inc dword ptr [ebp-1Ch]
000000ad 8B 45 E4 mov eax,dword ptr [ebp-1Ch]
000000b0 3B 45 F0 cmp eax,dword ptr [ebp-10h]
000000b3 7C C0 jl 00000075
X64, si / entonces
32: foreach (int i in array)
00000059 4C 8B 4F 08 mov r9,qword ptr [rdi+8]
0000005d 0F 1F 00 nop dword ptr [rax]
00000060 45 85 C9 test r9d,r9d
00000063 7E 2B jle 0000000000000090
00000065 33 D2 xor edx,edx
00000067 45 33 C0 xor r8d,r8d
0000006a 4C 8B 57 08 mov r10,qword ptr [rdi+8]
0000006e 66 90 xchg ax,ax
00000070 42 8B 44 07 10 mov eax,dword ptr [rdi+r8+10h]
33: {
34: if (i > 0)
00000075 85 C0 test eax,eax
00000077 7E 07 jle 0000000000000080
35: {
36: value += 2;
00000079 48 83 C5 02 add rbp,2
0000007d EB 05 jmp 0000000000000084
0000007f 90 nop
37: }
38: else
39: {
40: value += 3;
00000080 48 83 C5 03 add rbp,3
00000084 FF C2 inc edx
00000086 49 83 C0 04 add r8,4
32: foreach (int i in array)
0000008a 41 3B D2 cmp edx,r10d
0000008d 7C E1 jl 0000000000000070
0000008f 90 nop
30: for (int x = 0; x < iterations; x++)
00000090 FF C1 inc ecx
00000092 41 3B CC cmp ecx,r12d
00000095 7C C9 jl 0000000000000060
X64, ternario
59: foreach (int i in array)
00000044 4C 8B 4F 08 mov r9,qword ptr [rdi+8]
00000048 45 85 C9 test r9d,r9d
0000004b 7E 2F jle 000000000000007C
0000004d 45 33 C0 xor r8d,r8d
00000050 33 D2 xor edx,edx
00000052 4C 8B 57 08 mov r10,qword ptr [rdi+8]
00000056 8B 44 17 10 mov eax,dword ptr [rdi+rdx+10h]
60: {
61: value += i > 0 ? 2 : 3;
0000005a 85 C0 test eax,eax
0000005c 7F 07 jg 0000000000000065
0000005e B8 03 00 00 00 mov eax,3
00000063 EB 05 jmp 000000000000006A
00000065 B8 02 00 00 00 mov eax,2
0000006a 48 63 C0 movsxd rax,eax
0000006d 4C 03 E0 add r12,rax
00000070 41 FF C0 inc r8d
00000073 48 83 C2 04 add rdx,4
59: foreach (int i in array)
00000077 45 3B C2 cmp r8d,r10d
0000007a 7C DA jl 0000000000000056
57: for (int x = 0; x < iterations; x++)
0000007c FF C1 inc ecx
0000007e 3B CD cmp ecx,ebp
00000080 7C C6 jl 0000000000000048
Primero: ¿por qué el código X86 es mucho más lento que X64?
Esto se debe a las siguientes características del código:
- X64 tiene varios registros adicionales disponibles, y cada registro es de 64 bits. Esto permite que el J64 de X64 realice el bucle interno completamente usando registros aparte de la carga
idesde la matriz, mientras que el JIT de X86 coloca varias operaciones de pila (acceso a la memoria) en el bucle. -
valuees un entero de 64 bits, que requiere 2 instrucciones de máquina en X86 (addseguido deadc) pero solo 1 en X64 (add).
Segundo: ¿por qué el operador ternario es más lento tanto en X86 como en X64?
Esto se debe a una sutil diferencia en el orden de las operaciones que afectan al optimizador de JIT. Para JIT el operador ternario, en lugar de codificar directamente 2 y 3 en las instrucciones de la máquina de add , el JIT crea una variable intermedia (en un registro) para mantener el resultado. Este registro se extiende luego desde 32 bits a 64 bits antes de agregarlo a value . Dado que todo esto se realiza en los registros de X64, a pesar del aumento significativo en la complejidad para el operador ternario, el impacto neto se minimiza en cierta medida.
El X86 JIT, por otro lado, se ve afectado en mayor medida porque la adición de un nuevo valor intermedio en el bucle interno hace que se "derrame" otro valor, lo que resulta en al menos 2 accesos de memoria adicionales en el bucle interno (consulte los accesos). a [ebp-14h] en el código ternario X86).
Editar:
Se agregó un ejemplo que se puede hacer con la instrucción if-else pero no con el operador condicional.
Antes de la respuesta, eche un vistazo a [ ¿Cuál es más rápido? ] en el blog del Sr. Lippert. Y creo que la respuesta del Sr. Ersönmez es la más correcta aquí.
Estoy tratando de mencionar algo que debemos tener en cuenta con un lenguaje de programación de alto nivel.
En primer lugar, nunca he escuchado que se supone que el operador condicional es más rápido o el mismo rendimiento con la instrucción if-else en C♯ .
La razón es simple: ¿qué pasa si no hay ninguna operación con la instrucción if-else?
if (i > 0)
{
value += 2;
}
else
{
}
El requisito del operador condicional es que debe haber un valor con cualquier lado, y en C♯ también requiere que ambos lados de : tengan el mismo tipo. Esto solo lo hace diferente de la sentencia if-else. Por lo tanto, su pregunta se convierte en una pregunta que pregunta cómo se genera la instrucción del código de la máquina para que la diferencia de rendimiento.
Con el operador condicional, semánticamente es:
Cualquiera que sea la expresión que se evalúa, hay un valor.
Pero con la sentencia if-else:
Si la expresión es evaluada como verdadera, haz algo; Si no, haz otra cosa.
Un valor no está necesariamente involucrado con la instrucción if-else. Tu suposición solo es posible con la optimización.
Otro ejemplo para demostrar la diferencia entre ellos sería como el siguiente:
var array1=new[] { 1, 2, 3 };
var array2=new[] { 5, 6, 7 };
if(i>0)
array1[0]=4;
else
array2[0]=4;
el código anterior compila, sin embargo, reemplace la instrucción if-else con el operador condicional simplemente no compilará:
var array1=new[] { 1, 2, 3 };
var array2=new[] { 5, 6, 7 };
(i>0?array1[0]:array2[0])=4; // incorrect usage
El operador condicional y las sentencias if-else son conceptuales de la misma manera cuando se hace lo mismo, posiblemente incluso más rápido con el operador condicional en C , ya que C está más cerca del ensamblaje de la plataforma.
Para el código original que proporcionó, el operador condicional se usa en un bucle foreach, lo que desordenaría las cosas para ver la diferencia entre ellos. Así que estoy proponiendo el siguiente código:
public static class TestClass {
public static void TestConditionalOperator(int i) {
long value=0;
value+=i>0?2:3;
}
public static void TestIfElse(int i) {
long value=0;
if(i>0) {
value+=2;
}
else {
value+=3;
}
}
public static void TestMethod() {
TestConditionalOperator(0);
TestIfElse(0);
}
}
y las siguientes son dos versiones de la IL de optimizado y no. Como son largas, estoy usando una imagen para mostrar, el lado derecho es el optimizado:
En ambas versiones de código, el IL del operador condicional parece más corto que la sentencia if-else, y aún existe una duda sobre el código de máquina generado finalmente. Las siguientes son las instrucciones de ambos métodos, y la imagen anterior no está optimizada, la última es la optimizada:
Instrucciones no optimizadas: (Haga clic para ver la imagen a tamaño completo.)
Instrucciones optimizadas: (Haga clic para ver la imagen a tamaño completo.)
En este último, el bloque amarillo es el código que solo se ejecuta si i<=0 , y el bloque azul es cuando i>0 . En cualquier versión de instrucciones, la instrucción if-else es más corta.
Tenga en cuenta que, para instrucciones diferentes, el [ CPI ] no es necesariamente el mismo. Lógicamente, para la instrucción idéntica, más instrucciones cuestan un ciclo más largo. Pero si también se tuvieron en cuenta el tiempo de obtención de instrucciones y la tubería / caché, entonces el tiempo total real de ejecución dependerá del procesador. El procesador también puede predecir las ramas.
Los procesadores modernos tienen incluso más núcleos, las cosas pueden ser más complejas con eso. Si era usuario de un procesador Intel, es posible que desee consultar el [ Manual de referencia de optimización de arquitecturas Intel® 64 e IA-32 ].
No sé si hubo un CLR implementado en el hardware, pero si es así, es probable que obtenga un operador condicional más rápido porque el IL es obviamente menor.
Nota: Todos los códigos de máquina son de x86.