Ir al contenido principal

Análisis de efectividad en lenguajes de programación.

Últimamente me ha dado por realizar pequeñas prácticas que hace mucho realicé como parte de mi descubrimiento en algunos lenguajes de programación. He leído mucho respecto a los sabores y performance de cada lenguaje, cuyos argumentos no trataré por ser sumamente objetivos. Algunos valoran la facilidad, otros la poca verborrea que facilitan la construcción de complejos componentes de software.

A continuación expongo los códigos comparados y las salidas en terminal.

Características de la computadora.

  • CPU: 2 CPUs con 2 Cores AMD Turion(tm) 64 X2 Mobile Technology TL-60 a 1800.000 Mhz.
  • Memoria RAM: 3.7G
  • Sistema Operativo: Fedora release 20 (Heisenbug)


Versiones de compiladores/interpretes

  • Python: 2.7
  • C: gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)
  • Java: 1.7 hotspot a 64 bits
  • Ruby: 2.0
  • Go: 1.4.2 64 bits


Python




for my_range in range(1,90000000):
print (my_range)



Tiempo de ejecución


real    10m24.691s
user    2m23.193s
sys     0m7.727s


C


int i = 0;
for(i=0;i<=90000000;i++) {
printf("%d\n",i);
}

Tiempo de ejecución

real    0m28.385s
user    0m19.777s
sys     0m2.499s


Java


int i = 0;
for (i=0;i<=90000000;i++) {
System.out.println(i);

Tiempo de ejecución

real    17m22.300s
user    5m37.142s
sys     11m21.516s


Ruby


for i in 0..90000000
   puts "#{i}"
end

Tiempo de ejecución

real    2m56.731s
user    2m47.771s
sys     0m4.091s

Go


for i:=0;i<=90000000;i++ {
fmt.Println(i);
}

Tiempo de ejecución

real    8m22.270s
user    2m33.143s
sys     5m46.353s


Conclusión


Para simplificar las comparativas utilicé una escala en segundos y grafiqué los resultados.


Real


Este refleja el total de tiempo (cronómetro) que tardó la ejecución del programa. 


System

Tiempo de CPU en modo kernel (syscalls) que utilizó el programa. 

User

 Análogo al anterior, solo que en modo usuario.


Nota: Los tiempos de usuario y kernel, sumados, no son precisamente el tiempo real de ejecución, esto es debido a los diferentes estados que transita un proceso (como las esperas). 


Resultado


  1. Como podíamos esperar, Java en los 3 tiempos fue el más lento, por el otro lado, C siempre fue el más eficiente.
  2. Python es más lento que Ruby y Go hablando del tiempo real.
  3. Ruby ocupa más tiempo de procesador en modo usuario que Python y Go (virtualmente empatados).
  4. Go ocupa más tiempo en modo kernel que Python y Ruby.
Nota: Como pueden ver, los números no corresponden de la mejor manera, ya que hay un sesgo que tenemos que quitar de la mesa. La ejecución de cualquier syscall (modo kernel) siempre será más lenta que la ejecución de código en modo usuario, debido a los registros que se cargan y descargan en el CPU y las validaciones de seguridad.


Para quitar ese sesgo (sabemos que el planificador de procesos de GNU/Linux no es tan preciso como para permitirnos medir de la manera menos arbitraría) hice una sumatoria de los tiempos de usuario y kernel, eliminando las 'esperas'.


Con esta nueva comparativa vemos que en primer lugar, el lenguaje que más tiempo de CPU consume es Java, seguido por Go. Ruby y Python son muy cercanos, pero aún así, lejanos al rey de la eficiencia, es decir, C.






Etiquetas:

Comentarios

Publicar un comentario

Entradas populares de este blog

Ángulo de Corte

El armar un gallo de pulgada es una de las cosas más sujeta a mitos y medias verdades. Este es uno de los muchos temas que los galleros enuncian con una seguridad a prueba de balas.  Hasta el momento no he leído un solo escrito o esquema con detalle científico que tenga conclusiones claras y precisas de lo que sucede en un combate ni la ergonomía que mejor se adapta, todo proviene de un sistema de creencias que, muy en lo personal, me cuesta creer. El ángulo de corte se refiere a la posición de la punta de la navaja con respecto al codo de la pata. Dependiendo del amarrado es que la sitúa en un rango de los 5° a los 9°. De lo que no dudo es que no hay una manera precisa de emitir teorema alguno sobre este rubro. La formula del corte está dada por la sujeción de la navaja, la forma de la navaja, la altura de la botana, la posición de disparo del gallo, así como la calidad y aprendizaje del mismo durante el desarrollo de la pelea. Son muchas las variables, sin emba...
Publicar un comentario
Leer más

Análisis de conexiones TIME_WAIT

El tema de las conexiones mal utilizadas es un dolor de cabeza para muchos administradores de servidores de aplicaciones. Es común que las aplicaciones que mantenemos en nuestro resguardo sufran degradación, e incluso fallos, por el "simple" hecho de no cerrar las conexiones o tardar demasiado en hacerlo (vía sistema operativo). Como sabemos, una conexión pasa por varios estados, mismos que salen de la intención de este escrito. Las conexiones establecidas (ESTABLISHED) son demasiado costosas cuando abren y cierran, debido a eso, se han creado manejadores de conexiones (pooles) que mantienen abiertas las conexiones para reutilizarlas dependiendo la demanda. Es por eso, que en medida de lo posible, hay que utilizar un manejador de conexiones, ya sea a base de datos o algún broker. Entrando de lleno al tema, las conexiones en estado TIME_WAIT son un problema por el consumo de memoria, ocupando cada una 64k de memoria no paginable, es decir,  todo el tiempo se mantiene...
Publicar un comentario
Leer más

Significado de los dígitos de versión del kernel Linux

Algunas de las cosas que siempre quise saber, pero nunca me hice del tiempo para investigarlo es la función de los cuatro dígitos del kernel Linux. Su significado poco tiene que ver con hechos cabalísticos o confusos enunciados matemáticos. Mejor que en mis palabras están las de Tanenbaum: Los números de versión de Linux consiste en cuatro números, A.B.C.D, como 2.6.9.11. El primer número indica la versión del kernel. El segundo indica la revisión mayor. Antes del kernel 2.6 los números pares correspondían a versiones estables del kernel, mientras que los impares correspondían a versiones inestables que estaban en desarrollo. Después del kernel 2.6 los significados se manejaron de forma distinta. El tercer número corresponde a la revisión de versiones menores, como la aceptación de drivers. El cuarto número corresponde a las correcciones de errores menores o parches de seguridad.  Como ven, el señor Tanenbaum es sumamente lacónico con la explicación de los dígitos que compo...
Publicar un comentario
Leer más