Published 16 years ago
(updated 13 years ago)
La Ley de Moore ha muerto. Ahora rige la Ley de Amdah
Desde hace unos años, la Ley de Moore dejó de tener importancia. Hoy en día, es mucho más aplicable la Ley de Amdahl, acuñada por Gene Amdahl. Esta ley sostiene que al añadir más procesadores para trabajar sobre un problema, no se logra la productividad global esperada calculada mediante la suma de la productividad individual de cada procesador. Lo que tendrá efecto en su productividad global será la capacidad de poder disgregar el problema original en subproblemas, que puedan distribuirse entre los diversos procesadores.
Esta ley es importante porque la estrategia actual para desarrollar computadoras más veloces consiste en aumentar los nodos de procesamiento paralelos, ya sea colocando más núcleos en chip, más chips en un servidor, y más servidores en un único cluster. Sin embargo, su software requiere ser escrito específicamente para aprovechar este paralelismo.
En el caso del software aplicativo del que tenemos el código fuente, es posible hacerle pequeños ajustes y utilizar librerías para ejecución paralela, que lo hagan más eficiente en este contexto. Sin embargo, ¿qué sucede con las bibliotecas y subsistemas que están fuera de nuestro control? Más específicamente, ¿qué sucede con las bases de datos que entran en contacto con discos que inherentemente involucran un procesamiento secuencial? Las bases de datos son sólo un ejemplo común de la serialización de procesos. La serialización sólo permitiría el funcionamiento de un único núcleo en un momento determinado en un sistema de múltiples núcleos, y limitaría la potencia de cálculo utilizable. La serialización es el gran enemigo en esta instancia porque contrarresta todos los avances en productividad que ofrece el paralelismo.
Aquí es donde el almacenamiento en caché cobra importancia. A diferencia de una base de datos que es inherentemente serial por naturaleza, una caché vive en la memoria y es altamente paralela debido a la naturaleza de los buses de memoria. Una memoria bien escrita minimizará los bloqueos o el uso de señalización entre unidades de ejecución, y utilizará técnicas modernas para garantizar la integridad de los datos de manera escalable.
Caché en cluster
Las caché en cluster permiten que múltiples núcleos y servidores en un grid trabajen sobre los datos dispuestos en paralelo, aprovechando al máximo la potencia de cómputo disponible. El problema es cómo mantener la integridad de los datos entre los diferentes nodos. Las caché en cluster utilizan diversos mecanismos para mantener la sincronización entre las caché y garantizar la validez de los datos:
• Bloqueo pesimista del cluster completo. Cuando un cache requiere modificar datos, obtiene un bloqueo para todo el cluster, hace los cambios que se replican a cada instancia de caché y luego liberará el bloqueo del cluster. Este enfoque es seguro y sencillo pero presenta problemas de escalabilidad.
• Bloqueoo optimista. Es aquél donde los conjuntos de datos se copian, se trabaja con ellos y, una vez terminada la tarea, se obtienen los bloqueos y se escribe el estado en las caché de todo el cluster. Brinda mayor escalabilidad pero presenta la necesidad de reintentar una operación en caso de colisión.
Distribución de datos
Hasta ahora hemos hablado de las caché en cluster en el sentido de que cada caché es local pero consciente de sus pares y es capaz de sincronizar cambios con ellos. Si bien este enfoque funciona bien para la mayoría de las aplicaciones, aun restringe la memoria accesible que pueden utilizar. Otro enfoque sería no reproducir los datos entre las caché, pero sumar la memoria utilizable de todas las caché en un cluster y distribuir los datos entre ellas. Ubicar dónde se encuentran los datos podría implicar metadatos duplicados –una especie de mapa– o una función de búsqueda de registros compatible que apuntará a la instancia que contiene el registro que busca. Aunque distribuir datos de esta forma puede conllevar búsquedas innecesarias en la red, expone un espacio de memoria utilizable mayor para que sea ocupado por el sistema de caché. También hace que el sistema global sea más escalable.
Conclusión
Las caché constituyen una herramienta importante para aprovechar el paralelismo y eliminar los obstáculos en la recuperación y cálculo de datos. Analizando la arquitectura de su aplicación y el volumen y los patrones de acceso de sus datos, podrá decidir si le conviene una caché local, en cluster o distribuida. Muchas estructuras o productos de almacenamiento en caché desarrollados le ofrecerán un abanico de modos operacionales que se adapten a su uso en particular. Pero como sucede con frecuencia, las caché no son soluciones milagrosas y no deberían utilizarse de manera indiscriminada. Como citó el experto en optimización de Java, Kirk Pepperdine: “Calcule, no adivine”. Utilice un buen analista de perfiles e incorpore las caché sólo cuando sea necesario, cuando los problemas de recuperación o cálculo de datos estén frenando la escalabilidad.
Acerca del Autor
Manik Surtani es ingeniero investigador en JBoss, una división de Red Hat corp. Actualmente dirige el proyecto JBossCache en el Centro de Investigación y Desarrollo de JBoss. Su área de especialidad es la inteligencia artificial y redes neuronales.
Desde hace unos años, la Ley de Moore dejó de tener importancia. Hoy en día, es mucho más aplicable la Ley de Amdahl, acuñada por Gene Amdahl. Esta ley sostiene que al añadir más procesadores para trabajar sobre un problema, no se logra la productividad global esperada calculada mediante la suma de la productividad individual de cada procesador. Lo que tendrá efecto en su productividad global será la capacidad de poder disgregar el problema original en subproblemas, que puedan distribuirse entre los diversos procesadores.
Esta ley es importante porque la estrategia actual para desarrollar computadoras más veloces consiste en aumentar los nodos de procesamiento paralelos, ya sea colocando más núcleos en chip, más chips en un servidor, y más servidores en un único cluster. Sin embargo, su software requiere ser escrito específicamente para aprovechar este paralelismo.
En el caso del software aplicativo del que tenemos el código fuente, es posible hacerle pequeños ajustes y utilizar librerías para ejecución paralela, que lo hagan más eficiente en este contexto. Sin embargo, ¿qué sucede con las bibliotecas y subsistemas que están fuera de nuestro control? Más específicamente, ¿qué sucede con las bases de datos que entran en contacto con discos que inherentemente involucran un procesamiento secuencial? Las bases de datos son sólo un ejemplo común de la serialización de procesos. La serialización sólo permitiría el funcionamiento de un único núcleo en un momento determinado en un sistema de múltiples núcleos, y limitaría la potencia de cálculo utilizable. La serialización es el gran enemigo en esta instancia porque contrarresta todos los avances en productividad que ofrece el paralelismo.
Aquí es donde el almacenamiento en caché cobra importancia. A diferencia de una base de datos que es inherentemente serial por naturaleza, una caché vive en la memoria y es altamente paralela debido a la naturaleza de los buses de memoria. Una memoria bien escrita minimizará los bloqueos o el uso de señalización entre unidades de ejecución, y utilizará técnicas modernas para garantizar la integridad de los datos de manera escalable.
Caché en cluster
Las caché en cluster permiten que múltiples núcleos y servidores en un grid trabajen sobre los datos dispuestos en paralelo, aprovechando al máximo la potencia de cómputo disponible. El problema es cómo mantener la integridad de los datos entre los diferentes nodos. Las caché en cluster utilizan diversos mecanismos para mantener la sincronización entre las caché y garantizar la validez de los datos:
• Bloqueo pesimista del cluster completo. Cuando un cache requiere modificar datos, obtiene un bloqueo para todo el cluster, hace los cambios que se replican a cada instancia de caché y luego liberará el bloqueo del cluster. Este enfoque es seguro y sencillo pero presenta problemas de escalabilidad.
• Bloqueoo optimista. Es aquél donde los conjuntos de datos se copian, se trabaja con ellos y, una vez terminada la tarea, se obtienen los bloqueos y se escribe el estado en las caché de todo el cluster. Brinda mayor escalabilidad pero presenta la necesidad de reintentar una operación en caso de colisión.
Distribución de datos
Hasta ahora hemos hablado de las caché en cluster en el sentido de que cada caché es local pero consciente de sus pares y es capaz de sincronizar cambios con ellos. Si bien este enfoque funciona bien para la mayoría de las aplicaciones, aun restringe la memoria accesible que pueden utilizar. Otro enfoque sería no reproducir los datos entre las caché, pero sumar la memoria utilizable de todas las caché en un cluster y distribuir los datos entre ellas. Ubicar dónde se encuentran los datos podría implicar metadatos duplicados –una especie de mapa– o una función de búsqueda de registros compatible que apuntará a la instancia que contiene el registro que busca. Aunque distribuir datos de esta forma puede conllevar búsquedas innecesarias en la red, expone un espacio de memoria utilizable mayor para que sea ocupado por el sistema de caché. También hace que el sistema global sea más escalable.
Conclusión
Las caché constituyen una herramienta importante para aprovechar el paralelismo y eliminar los obstáculos en la recuperación y cálculo de datos. Analizando la arquitectura de su aplicación y el volumen y los patrones de acceso de sus datos, podrá decidir si le conviene una caché local, en cluster o distribuida. Muchas estructuras o productos de almacenamiento en caché desarrollados le ofrecerán un abanico de modos operacionales que se adapten a su uso en particular. Pero como sucede con frecuencia, las caché no son soluciones milagrosas y no deberían utilizarse de manera indiscriminada. Como citó el experto en optimización de Java, Kirk Pepperdine: “Calcule, no adivine”. Utilice un buen analista de perfiles e incorpore las caché sólo cuando sea necesario, cuando los problemas de recuperación o cálculo de datos estén frenando la escalabilidad.
Acerca del Autor
Manik Surtani es ingeniero investigador en JBoss, una división de Red Hat corp. Actualmente dirige el proyecto JBossCache en el Centro de Investigación y Desarrollo de JBoss. Su área de especialidad es la inteligencia artificial y redes neuronales.
- Log in to post comments