2 votos

Compresión de RAM. ¿Por qué no se ha puesto de moda?

Estaba leyendo un artículo sobre la compresión por hardware de la memoria RAM y me preguntaba por qué no se ha generalizado el uso de algo así. Algo como esto sería realmente útil para los servidores o el niño en casa que está renderizando vídeo para su canal de Minecraft.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.3232&rep=rep1&type=pdf

5voto

Kiran Puntos 320

AFAIK, en general La compresión sin pérdidas nunca puede alcanzar una tasa mejor que 2x (creo que había alguna prueba al respecto que implicaba que para datos "algo aleatorios" hay rendimientos decrecientes. Intentaré encontrarla). Tenemos que considerar el caso general porque el hardware de compresión está incorporado.

Compresión con pérdidas, como MPEG JPEG puede hacer mucho mejor, pero eso es inútil para los programas informáticos y los datos. La compresión es menos eficaz cuanto más "aleatorios" son los datos, por lo que podría llegar un momento en que la compresión incorporada no ofreciera ninguna compresión real.

Cuanto más corto sea el objeto comprimido, mayor será la sobrecarga de memoria del esquema de compresión, lo que reducirá su eficacia. Por ejemplo, para garantizar que el acceso aleatorio siga funcionando, las direcciones de memoria tendrían que ser asignables a la memoria comprimida, lo que probablemente desperdiciaría espacio en alguna parte.

A cambio de la compresión, es probable que aumente la latencia de la memoria principal para permitir que funcione el hardware de compresión. La memoria principal ya es mucho más lenta que la CPU, con una latencia considerable. Así que añadir más latencia parece fundamentalmente una "mala idea". El desajuste entre la velocidad de la CPU y la de la memoria ha ido empeorando (en parte debido a los múltiples núcleos que comparten un bus de memoria) durante muchos años. Así que es posible que un artículo escrito en el año 2000 no lo tuviera en cuenta.

Las CPU de la serie Power de IBM pueden utilizar la compresión en las instrucciones. Pueden descodificar a los patrones de instrucciones normales antes de que la CPU utilice las instrucciones.

Edición3: Tiene mucho más sentido comprimir datos de sólo lectura que datos de lectura-escritura. Un gran bloque de datos de sólo lectura se puede comprimir una vez, lo que resulta barato. El código de instrucciones es un buen candidato para la compresión porque en la mayoría de los sistemas operativos y en muchos lenguajes el código es de sólo lectura o incluso de sólo ejecución (no puede ser leído como datos por los programas de usuario). El inconveniente es que algunas arquitecturas de conjuntos de instrucciones (ISA) de CPU ya están densamente codificadas, por lo que podría no resultar tan beneficioso como parece.

La mayoría de los lenguajes de programación modernos incluyen funciones de compresión en sus bibliotecas. Así, un programador puede optar por comprimir trozos de datos que puedan beneficiarle. El programador tiene conocimientos suficientes para elegir entre compresión con pérdida o sin pérdida, que podría reportar mayores beneficios que una técnica sin pérdida total. Un programador que utilice la compresión en realidad sería malo para un esquema de compresión incorporado porque los datos comprimidos son muy difíciles de comprimir (cuando se utiliza un buen esquema). Así que una situación en la que la compresión con pérdida de datos específicos es "buena", y produciría una compresión mucho mejor que un esquema sin pérdida, ¡empeoraría la compresión!

Edit3:
Memoria comprimida de OS X "Mavericks" (página 8) explica que el OS X "Mavericks" sí comprime los datos para inactivo aplicaciones.

Linux también tiene mecanismos de compresión de memoria en el núcleo. Ese artículo explica que utiliza páginas como unidad de compresión, por lo que ya existen tablas en el núcleo para rastrearlas y, por tanto, se pueden ampliar las estructuras existentes. Además, el hardware subyacente de la CPU "interrumpirá" el acceso a una página, que es exactamente el momento adecuado para descomprimirla.

Como se ha señalado en los comentarios, AIX de IBM tiene Memoria activa Ampliación también.

{ Comentario: Si alguien puede encontrar las versiones de Windows, BSD, etc que identifican in-RAM compresión, los añadiré también. }

Para que quede claro, no estoy diciendo que el documento de referencia, utilizando hardware de compresión específica es necesariamente una mala idea.

Yo diría que la compresión de memoria con la CPU es relativamente "cara". Es probable que esté leyendo la memoria secuencialmente, lo que es típicamente la definición de un "destructor de caché". Es imaginable que los SOs desactiven el desalojo de caché para la memoria que está siendo comprimida, mientras se realiza la compresión. Por lo tanto, hacer el trabajo antes de la caché parece que podría ser útil.

Un modelo podría ser un controlador DMA "inteligente" que pudiera realizar la compresión o descompresión a medida que copia la memoria. Esto podría ser más obvio, fácil de integrar en un sistema operativo existente y lo bastante visible para la CPU y el hardware controlador de memoria como para tener un impacto mínimo.

Edita:
Es irrelevante que un caso específico tenga una compresión sin pérdidas que supere a 2x. Los casos específicos no importan. Escriba 20.000 0 bytes en un archivo y ejecute un sistema de compresión sin pérdidas, y el archivo quedará diminuto. Eso no es prueba de que en el caso general la compresión sin pérdidas siempre consigue una compresión mejor que 2x, simplemente que podría hacerlo en algunos casos concretos.

En su lugar, tenemos que demostrar que la compresión sin pérdidas puede lograr mejores resultados que 2x en todos casos, especialmente el peor casos, y datos aleatorios casos. Esa es la cuestión. Una vez incorporado el hardware de compresión, no hay elección, a menos que el esquema se vuelva aún más complejo. Con aún más complejidad, yo esperaría que el espacio desperdiciado, un cognado de la fragmentación de la memoria, empeorara.

Edita 2:
He hojeado el documento. En mi opinión, uno de sus puntos débiles es que no tiene en cuenta el coste de la electrónica frente a otros usos alternativos de ese gasto. Me sorprendería que un coste significativo aplicado a varias áreas de una CPU no produjera beneficios. En mi humilde opinión no lo suficiente como para decir "añade esto de más y esta propiedad del sistema mejorará". Hay que compararlo con una o varias alternativas. Por ejemplo, podría ser más barato comprar más memoria.

Mi $0.02

1voto

panopticoncentral Puntos 1333

Hoy en día, la DRAM consume muy poca energía en reposo. Dado que tanto los servidores como los smartphones no están tan limitados por el coste del hardware como por la potencia, hasta que no se demuestre una ventaja en el consumo de energía por el uso de la compresión, ésta no se utilizará, en general, en estos ámbitos. En su lugar, se preferirá un sistema de caché multinivel, con varios tipos sucesivos de memoria que requieran menos energía y tengan mayor capacidad.

La compresión de RAM por software se ha utilizado, de hecho, para adaptar sistemas más antiguos o débiles a la ejecución de software para el que no son trivialmente adecuados debido a los requisitos de RAM y a la falta de almacenamiento en disco de memoria virtual. Sin embargo, ha sido evidente un aumento del consumo de energía (*esto se discute, véase la discusión más abajo). También se ha utilizado para aumentar el rendimiento de unidades en las que el disco scratch es prohibitivamente lento.

Es probable que, con soporte de hardware, se pueda implementar un sistema de compresión de RAM con menos requisitos energéticos que puramente por software. Sin embargo, esto va en contra del objetivo de adaptar equipos que, de otro modo, no serían adecuados, y no parece que pueda demostrarse su utilidad en equipos de nuevo diseño.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X