Monday, May 23, 2011
De la eficiencia en cómputo
Han pasado ya algunos años, por no decir muchos, desde que empecé a usar computadoras. Mi primera máquina fue una Apple ][ y ahí hice mis pininos, primero en el Applesoft Basic y más adelante en el UCSD Pascal. Cabe recordar que una computadora de los años ochenta tenía unos 128K de memoria RAM y unidades de discos flexibles. Ni pensar en discos duros. De hecho, me tocó ver uno, para un sistema de precios unitarios, que era cvomo de 5 megabytes y que, para usarse con la Apple ][, el disco estaba dividido en un sistema de discos flexibles virtuales, que el sistema operativo DOS 3.3, podía entender entonces.
Cuando se tenían estos sistemas, estábamos limitados a unos 70K por lado del disco. Si voltéabamos el disco flexible (floppy) y le hacíamos una muesca en un borde, podíamos duplicar la cantidad de información a guardar, aunque el fabricante de los diskettes no recomendaba esta práctica. Igualmente, al tener solamente 128K de RAM, teníamos espacio reducido para nuestros programas. Si usábamos el intérprete de Applesoft Basic entonces estaríamos hablando de unos 48K para programas, porque los 128K no podían usarse más que en dos mapas alternativos de memoria por la forma en que el procesador accedía a la memoria. Por ello, en Applesoft Basic se seguía un esquema que se usó mucho en los primeros sistemas con lenguaje BASIC, el cual lo que hacía era "tokenizar" cada palabra reservada del lenguaje, para así ahorrar bytes, que estaban tan escasos en ese tiempo. Así, la instrucción PRINT, por ejemplo, se traducía a un sólo número hexadecimal. Si queríamos ver el listado del programa en memoria, éste se desplegaba destokenizando, valga la expresión, cada token y el programador veía su código fuente.
En términos de hardware y software, por ejemplo, la Apple ][ tenía su sistema operativo en un diskette de 70K. Increíble pensar que se podía tener un sistema operativo en tan poca memoria. Pues bien, como desde luego esta pieza de software era la más importante de la Apple ][, me hice de un libro que explicaba lo que pasaba dentro del sistema: Beneath Apple DOS. Hallé, cosa notable, que los ingenieros de software de Apple habían decidido poner el sistema a la mitad del disco. Si éste tenía 36 tracks, se cargaba éste en el track 18. Sonaba extraño. ¿Para qué? la respuesta es notable: si el cargador se pone a la mitad del disco, la cabeza lectora tiene que caminar máximo la mitad de la distancia para hallar el track deseado. Obsérvese pues cómo se buscaba optimizar hasta en estos detalles.
Con el tiempo y los megas, gigas y teras, que ya están con nosotros, las cosas cambiaron radicalmente. Cualquier computadora casera tiene al menos dos gigabytes de memoria, y ello hace que la optimización y la eficiencia pierda sentido.
Ahora nadie piensa realmente en este tema. Los compiladores ya no son tan cuidadosos para ahorrar memoria. Los procesadores de texto han hecho crecer los documentos porque ahora se les añadetodo género de tags y marcas para identificar tipos de letra, tamaños, formato, etc. Simplemente un archivo que contenga la frase "Hello world!", ocupa 24064 bytes, cosa que vendría ser la tercera parte de un diskette de Apple ][.
Ahora la eficiencia, creo yo, se considera desde otro enfoque. Ahora se trata de ser muy rápido en todo, aunque para ello necesitemos usar mucha memoria. Los programadores sabemos que no se puede tener un programa muy rápido que use poca memoria, a mayor rapidez de una cosa, más recursos para que esto ocurra. En ese sentido la computación es muy ética. No hay una relación de ganar ganar entre velocidad de proceso y uso de poca memoria.
Desde luego que a pesar de que los sistemas modernos no hacen énfasis en lo que se refiere a optimización, las herramientas de programación insisten en usar esquemas dinámicos de memoria. Apartar usando un arreglo demasiada memoria ya no es una práctica adecuada. Ahora lo que se hace es que el sistema operatiuvo otorga memoria a los procesos que la están pidiendo. Da bloques de memoria, no toda, a alguna aplicación. Si ésta requiere más, buscará darle más. De esta manera se optimizan ahora las cosas, como previniendo de antemano, por software, de hacer las cosas bien, de usar de la mejor manera losa recursos.
Como sea, creo que no estaría de más que se pensara de pronto en optimización. Aunque sobre memoria, ¿por qué no hacer las cosas un poco mejor dentro de la computadora?
Subscribe to:
Post Comments (Atom)
5 comments:
Hay que recordar la célebre frase de Donald Knuth, casi siempre usada fuera de contexto: "La optimización prematura de la raíz de todo mal". Aquí la frase completa para quien le interese.
Yo primero programo una aplicación o biblioteca de componentes enfocándome a cumplir la funcionalidad requerida, y después empiezo a optimizar. En el raro caso de que se pueda identificar un segmento que hay que optimizar (como cuando tienes una función que sabes de antemano que se va a invocar miles de veces por segundo, por la naturaleza de la aplicación donde reside), pues ahí sí desde el principio es mejor pensar en la mejor manera de implementarlo sin usar muchos recursos y con la mayor velocidad posible.
Todo esto obviamente dentro de las limitaciones de la tecnología elegida; si estás haciendo un sistema en Ruby pues por más que optimices tu código, a la hora de correr va a ser interpretado. El desempeño de código Java depende en parte de la implementación de la JVM que se use, etc.
Esto me recuerda que hace década y media el mejor software se estaba produciendo en Cuba, llegué a ver cosas sorprendentes de Información Geográfica y de Medicina en computadoras 386 con sólo DOS. La excelente calidad y velocidad de este software se debía a la escasez en la Isla de hardware actualizado y en cantidad suficiente. Como siempre, la escasez es la madre de toda creatividad...y de toda optimización, agregaría yo.
¿Qué tal los one-liner y two-liners que promovían los Beagle Brothers?, eso si está cañón.
Beno,
tengo pendiente un artículo sobre los Beagle Brothers...
saludos
Manuel
hola!
pues tienes mucha razón, actualmente se preocupan muy poco en esto de la memoria, sobre todo para aplicaciones que se requiere sean AMIGABLES con el usuario. Aunque recordemos que en la investigación sigue siendo fundamental la optimización de recursos, los ejemplos que se me vienen a la mente son máquinas de aprendizaje, algoritmos genéticos, etc.
Esto sólo refiriéndonos a computadoras de escritorio, porque si hablamos de dispositivos móviles sigue habiendo una gran necesidad de optimizar memoria. Claro que esto quizá no dure mucho puesto que los dispositivos móviles aumentan su capacidad muy rápido.
saludos
sazuke
Post a Comment