R3b3l10Nn

Ú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 ...

El tema del monitoreo es por sí solo vasto y exige cierto nivel de especialización y comprensión. Como todas las soluciones de software , el establecimiento de una arquitectura y elección de productos conlleva un conocimiento profundo del las necesidades y las mejores opciones disponibles, no solo en términos de costos, sino de prestaciones y flexibilidad de los productos que están en el mercado. No es cosa fácil establecer un flujo y tratamiento adecuado de las métricas recolectadas. En lo que mi experiencia acontece, éste rubro de las TI apenas se le da importancia, se mira como un gasto que no tiene retorno. Los profesionales lo entienden como la manera en detectar problemas en los ambientes productivos, pero que si se detectan vía registros, el problema está cuasi resuelto, por tanto, la necesidad de un sistema complejo de monitoreo no es necesario.  No estoy a favor de acumular datos y sólo mantenerlos por si llegasen a requerirse en algún punto, si l...

Advierto, no soy desarrollador de software, no obstante, suelo entretener el tiempo con algunos problemas que requieren habilidades de desarrollo. He traído a cuento un viejo problema (no es coincidencia). La impresión de números primos. En este caso trabajaré para la siguiente cifra 1000000. La idea es ir mejorando el algoritmo y medirlo cuantitativamente en el tiempo de ejecución. Para ello, he decidido mostrar los avances y cómo es que ataqué el problema. Primer esfuerzo Este código es el menos adecuado. Funciona, pero es demasiado lento, puesto que prueba todos y cada uno de los números. Esta versión tarda casi 1 hora. Segundo esfuerzo Agregando una simple sentencia que salga del ciclo y comience con el siguiente número hace mucho más eficiente el código. La idea detrás de esta mejora es que si sabemos que sólo debe haber dos divisiones exactas, cuando haya más; no tiene caso seguir probando los siguientes números. El tiempo que tarda ...