Multiprocesadores: la nueva revolución en programación · 2005-01-11 23:32 by
En la década de 1990, la programación orientada a objetos irrumpió en el panorama de la Informática. Nacida 3 décadas antes, había encontrado su motivación, surgida de la necesidad de crear aplicaciones cada vez más grandes y complejas.
Pocos se atreven hoy en día a optimizar el código de sus programas. A fin de cuentas, los procesadores son rápidos y los plazos de entrega no permiten pausas. Pero… ¿y si la industria no pudiese producir procesadores más rápidos a un precio razonable? ¿Y si la solución pasara por usar multiprocesadores? ¿Cómo afectaría esto al desarrollo de programas? Herb Sutton lo analiza en The free lunch is over, artículo que saldrá publicado en Dr. Dobb’s Journal el próximo mes de marzo.
No es nuevo lo que el amigo Sutton dice. Es más, recuerdo las caras de estupefacción de mis interlocutores cuando afirmé que la programación orientada a objetos era una tendencia que encontraría su final algún día. O cuando pregunté por qué se descuidaban las optimizaciones, hallando como respuesta que “ya se encarga el compilador”.
Es cierto que los sistemas actuales han alcanzado una complejidad (tanto física como lógica) que impide que una persona pueda conocerlos al 100%. Ante eso, las optimizaciones finas como escribir partes en ensamblador parecen de otra época o, al menos, de otro ámbito (ej.: muchas, aunque no todas, de las aplicaciones para microcontroladores; que son el 98% del mercado de procesadores, de todas formas). Pero acostumbrarse a que para mejorar la velocidad, basta con cambiarse a un procesador más rápido es algo que tiene los días contados. Tal vez las horas…
Dado que es difícil, muy difícil, seguir aumentando la velocidad por ese camino, los fabricantes están optando (y seguirán, mientras puedan) por incluir varios procesadores en la misma oblea de silicio. Es un paso que la alianza IBM/Motorola ha dado en su PPC G5, y que Intel y AMD están a punto de dar este mismo año (la tecnología HT de Intel no cuenta, porque sólo duplica algunas partes del procesador, no todo).
Entonces, lo que cualquier usuario de un nuevo sistema (y más si es profesional) exigirá, pues su buen dinero le habrá costado, es que si su ordenador tiene 2 (o 4 o los que sea) procesadores, tanto el S.O. como las aplicaciones los usen. Y no valdrán trucos, pues será fácil comparar la velocidad con otro de 1 procesador y la misma frecuencia en MHz.
Entendedme, no os digo que olvidéis todo lo que sabéis de orientación a objetos, pero sí que lo que se avecina va a exigir algo más que eso. Y que lo mejor será ir desempolvando vuestros conocimientos sobre semáforos, monitores, colas, mensajes, bloqueos, etc, e ir poniéndolos en práctica. El paralelismo es complejo, pudiendo dar lugar a una secuenciación inadvertida o a interbloqueos. Pero con conocimiento, disciplina y práctica, puede ser conjurado en nuestro provecho. Y en el de los usuarios.
comentarios desactivados para este artículo
Celebremos el “Día del Administrador de Sistemas” Y si te comparan con el Messenger…
Lo que no termino de ver es el fin de las mejoras en rendimiento (incluso las basadas en la velocidad bruta). Cierto que Intel ha echado el freno y no pasará del micro a 4GHz, y que los avances más recientes vienen por otros caminos, pero la velocidad seguirá subiendo.
Y donde has dado en el clavo es en la optimización: un producto puede fracasar si su rendimiento no es el esperado (o esperable) pero el fracaso es inevitable si se entrega fuera de plazos. Ya lo dijo Knuth advirtiendo del bicho de la optimización prematura. Pero claro, ¿existe la optimización a posteriori?
— Epaminondas Pantulis 2005-01-12 20:01 #
Ahora que Commodore va a resucitar, superará todos estos problemas, condenando eternamente al binomio Wintel al olvido, e impondrá la Solución Definitiva por la Supremacía Mundial. Como las armas secretas de los Nazis al final de la Segund...
Ers... Olviden el ejemplo.
TQEALHVQOQPR
;^>
— LBF 2005-01-12 22:56 #
Pero, en definitiva, sólo anunciaba la tendencia a lo "multi"; supongo que como paso lógico desde la "multimedia" :)
Lo cual enlaza con el comentario de LBF, pues sin duda la nueva era Commodore abrirá una nueva dimensión en la producción de etiquetas adhesivas con la marca en cuestión impresa en ellas :)
Hoy estoy muy sonriente, por lo que veo. Será porque el Ojo se ha abierto al nuevo año. Ya sólo falta una glosa del nuevo iMac Mini. Voy a dar una vuelta, a ver si lo veo en la bitácora de algún amigo ;) y luego de paso miro unas páginas para aprender lo básico de la fotografía que me ha recomendado un amigo ;)
— DrPepix 2005-01-12 23:39 #
— Epaminondas Pantuls 2005-01-13 02:12 #
La programación orientada a objetos no durará siempre. Surgirán otros paradigmas (tal vez la orientada a aspectos o a esquemas o vete tú a saber qué), pero problemente se apoyarán en la orientada a objetos, igual que esta se apoya en el paradigma procedimental. La razón: los objetos no son suficiemente reusables.
Y aquí enlazo con lo de la optimización: el mayor coste en un proyecto es el de mantenimiento y por eso es más importante hacer algo que se entienda a que sea óptimo. Pero tampoco hay que dejar la optimización para el final. Como dice Connie Smith, autora de un interesante libro llamado "Software Performance Engineering", la alternativa fix-it-later (que podríamos traducir por "ya lo arreglaré") con respecto al rendimiento ha fracasado en muchas ocasiones. La solución: considerar el rendimiento en las especificaciones (que no tienen que ser sólo funcionales), en el diseño (aplicando modelos que nos permitan prever si ese diseño tan sencillo nos va a servir para cumplir las especificaciones, llegando a un compromiso entre la sencillez y la eficiencia necesaria), y en la implementación sólo en sitios muy concretos.
— Joaquín 2005-01-14 05:58 #
O sea, que los profesionales de la programación vayan teniendo en cuenta como algo que será cotidiano toda la pléyade de elementos nuevos que será necesario manejar para que las cosas funcionen.
Las optimizaciones tienen ese halo de mítico (tanto en lo positivo como en lo negativo) que hacen un poco difícil su discusión. Yo soy partidario de la optimización, pero siempre que no se vaya a emplear como una forma de perfeccionamiento personal (de gran importancia en momentos), opto por que se base en resultados medibles para el usuario, que son los más importantes.
Y, por supuesto, cuanto antes se hagan las optimizaciones, mejor. No dejemos al compilador lo que se puede hacer en el código fuente, ni a éste lo que se puede hacer en el diseño, ni aquí lo que pertenece a la especificación, ni entonces lo que podría haberse hecho en el planteamiento inicial del problema.
Aunque, claro: todo esto forma parte del siempre complejo equilibrio que hace que las cosas ya no sean tan simétricas ni sencillas. Pero merece la pena intentarlo.
— DrPepix 2005-01-14 23:38 #