c# - para - mono sdk 5.12 0 linux
Proyecto Mono: ¿Por qué es mono más rápido que.NET? (4)
Bueno, no me sorprende que ejecute el mismo bytecode más rápido.
Si prueba la versión de Mono para Windows, esperaría una diferencia de rendimiento menor, excepto en los casos que involucran operaciones optimizadas de SIMD.
Me sorprende observar que el mono es más rápido que .NET. ¿Alguien sabe por qué es así? Esperaba que el mono fuera más lento que .NET, pero no fue el caso al menos con mis experimentos.
Tengo un ordenador portátil Windows XP con .NET Framework. Estoy ejecutando CentOS en vmware vmplayer en la parte superior de Windows XP. Quería probar el mono. Así que tomó las fuentes de Mono 2.6.1 y las instaló en CentOS en vmplayer. He escrito una aplicación de prueba de servicio web utilizando .Net 2.0, la ejecuté en wndows, funcionó, transfirí el binario a los centos en el vmplayer sin ninguna recompilación y lo ejecuté en centos. ¡Hurra funcionó! La vida es buena, pero entonces algo más atrajo mi atención. La ejecución de la aplicación en centos parecía ser más rápida. No me creí mis ojos.
Para confirmar mi observación, eliminé la red de la ecuación porque la respuesta de la red depende de muchos factores externos.
Tomé un pequeño código ficticio de Internet, lo compilé en un estudio visual ejecutado en Windows y en CentOS, los resultados son los siguientes
Output on windows console is HelloConsole/bin/Debug>HelloConsole.exe
Result =2.66666664666712E+24
37443.6077769661 ms
Output on Centos console is [rupert@bagvapp Math.Pow]$ mono HelloConsole.exe
Result =2.66666664666712E+24
28790.6286 ms
Si alguien puede explicar este comportamiento, sería genial. el entendimiento de mi lego es que la implementación de Mono es más eficiente que el framework .NET. Incluso si asumo que la implementación matemática de Mono es solo eficiente. Pero muchas implementaciones, como el procesamiento de datos financieros, los cálculos gráficos dependen mucho de la biblioteca matemática. Sería más interesante realizar la prueba en Mono / Centos directamente sin vmware pero eso requiere algo de tiempo. Voy a intentarlo puede ser el próximo fin de semana.
public static void DummyLoop()
{
double sumOfPowers = 0;
int count = Convert.ToInt32(ConfigurationManager.AppSettings["count"]);
for (int i = 0; i < count; i++)
{
sumOfPowers += Math.Pow(i, 2);
}
Console.WriteLine("Result =" + sumOfPowers);
}
static void Main(string[] args)
{
Stopwatch stopWatch = new Stopwatch();
stopWatch.Start();
DummyLoop();
stopWatch.Stop();
double ms = (stopWatch.ElapsedTicks * 1000.0) / Stopwatch.Frequency;
Console.WriteLine(string.Concat(ms.ToString(), " ms"));
Console.ReadLine();
}
Esta fue una discusión sobre esto en la lista de correo de Mono no hace mucho tiempo. El razonamiento que proporcionaron es que Mono está extremadamente optimizado en Linux (exactamente cómo no se mencionó). Pero Mono no es la única variable aquí, si está ejecutando Mono en Linux. Es un sistema operativo diferente, diferentes programadores de procesos y varios subsistemas de nivel de kernel pueden tener efectos marcadamente diferentes en el rendimiento, independientemente del trabajo del equipo Mono. Mono también hace un uso intensivo de los intrínsecos del compilador , que .NET puede o no hacer.
Sin embargo, la mayoría de las veces en una comparación Mono en Windows vs .NET en Windows, es posible que encuentre .NET superando a Mono más seguido que no. Pero incluso entonces, Mono no siempre puede perder. De hecho, para el código específicamente optimizado para Mono (por ejemplo: utilizando Mono.SIMD), puede obtener un rendimiento de un orden de magnitud mejor en Mono vs .NET, independientemente de la plataforma.
Realmente no estás haciendo una gran comparación aquí. Básicamente estás comparando una función (Math.Pow) entre las dos. Presumiblemente, una aplicación real hará más cosas que esta función.
Mono''s Math.Pow parece optimizarse implementando esto en C. No sé cómo .Net lo implementa. Se puede implementar completamente en código administrado.
Probablemente encontrará que ambos tiempos de ejecución son lo suficientemente rápidos para las necesidades diarias.
Todo lo que realmente prueba es la implementación del temporizador, que normalmente son pruebas incorrectas porque no hay dos sistemas operativos que implementen lo mismo. Algunos usan un temporizador duro que es muy exacto (Linux) y otros tienen un temporizador que puede ser anticipado (Windows) según las necesidades del sistema. Si desea comparar una llamada, evite las llamadas intermedias o es probable que las esté cronometrando, no con lo que piensa que está probando. Math POW va a ser casi el mismo en ambas plataformas, ya que los cálculos para calcularlo no han cambiado en cien años. Aprendo sobre las diferencias de sistema operativo con el temporizador más que nada.