|
|
|
Secciones
Login Barrapunto
mig21 (7781)
mig21
reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw
Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames ;)
reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw
Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames
No creo que te interese, pero en Lecturas aleatorias [blogspot.com] dejo registro de los libros que voy leyendo...
Esta es toda mi información de usuario
Publicidad
Publicidad
Jueves, 04 de Noviembre 2004
Sencillo es bonito
09:56h.
Siguiendo con los artículos propuestos para los mejores de 2004 me encuentro con "Simple Is Beautiful" de Noel Llopis. Es del tipo de artículos que me gustan, casi más filosoficos que prácticos, aunque en este caso contiene consejos útiles. La premisa de la que parte es que el mejor código es el que no existe. Es decir, que primero hay que preguntarse el porqué de ponerse a desarrollar. Pero ¿que hacer si hay que desarrollar? Tratar de dejarlo lo más simple posible (la vieja regla de KISS (Keep it Simple, Stupid!)). Y para llegar a esa simplicidad da una serie de consejos que me parecen simples y buenos:
- Evitar trucos de lenguaje innecesarios
- Evitar o postponer optimizaciones que oscurezcan o compliquen el código (a alguno le sonará a "Premature optimization is the root of all evil" de Donald Knuth)
- Hacer funciones y/o clases que hagan una sola cosa
- Tener cuidado que las mediciones de rendimiento, el registro de sucesos y el manejo de errores no compliquen lo que es simple
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
no siempre es tan sencillo
(Puntos:2)( http://www.angelfire.com/co2/muzaraque/index.html | Última bitácora: Domingo, 02 Noviembre de 2008, 19:37h )
A veces no resulta simple
Hace algunos años me toco programar un algoritmo para probar una maquina vectorial, para calcular matrices, rapidamente hice uso de las operaciones vectoriales que reducián el número de ciclos de ejecución a aproximadamente un 20% del original, unos 30000 ciclos en el original y unos 5500 en la version vectorial).
El código quedo claro y bonito.
Pero aquello no fue suficiente, a priori y había que optimizarlo aún mas, por lo que tuve que preparar un complejisimo sistema que aunque seguía basado en operaciones vectoriales, hacia uso de las caracteristicas propias que tiene la multiplicacion de matrices para adelantar ciertos resultados a costa de multiplicar por 10 el tamaño del programa para lograr reducirlo a 4500 ciclos de reloj y haber complicado la complejidad de compresión del programa MUCHO, aun se podía haber optimizado mas y dejarlo en unos 3900-4000 ciclos según mis calculo, pero el tamaño hubiese sido 100 veces mayor que la verison con código claro y bonito y me negé teniendo en cuenta que 5500 fue un resultado un 15% mejor de lo inicialmente esperado.
Moraleja: ahorar unos ciclos de reloj en ejecución multiplica por 100% la probabilidad de que la ejecución del programa falle por corrupción de algún código de operacion.