Git DEFLATE / zlib optimizado

Tenemos algunos repositorys realmente grandes en git, en estos hemos observado cómo la compression remota / server es un cuello de botella al clonar / tirar. Dado que git se ha generalizado y utiliza zlib, ¿se ha optimizado esta compression zlib?

Un documento de Intel detalla cómo pueden acelerar la compression DEFLATE con un factor de aproximadamente ~ 4 veces, aunque con una relación de compression menor:

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-deflate-compression-paper.pdf

Otro documento indica una velocidad de ~ 1.8 veces donde las proporciones de compression se conservan para la mayoría de los "niveles" de compression (1-9):

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/zlib-compression-whitepaper-copy.pdf

Esta última optimization es que parece disponible en github: https://github.com/jtkukunas/zlib

zlib parece ser bastante antiguo (en esta industria de ritmo acelerado), la última versión es de abril de 2013. ¿Ha habido algún bash de optimizar SIMD zlib para nuevas generaciones de procesadores? ¿O hay alternativas para usar zlib en git?

Entiendo que puede especificar un nivel de compression en git que afectará la velocidad y la relación de compression. Sin embargo, lo anterior indica que puede haber mejoras de performance bastante grandes en zlib sin dañar las relaciones de compression.

Entonces, para recapitular, ¿existe alguna implementación de git existente que use una alternativa zlib o zlib altamente optimizada?

PD: parece que muchos desarrolladores / serveres se beneficiarían de esto (incluso emisiones de gases de efecto invernadero;)).

De hecho, hay contribuciones al desinflado de zlib de Intel que aún no se han integrado. Puede ver esta bifurcación de zlib que tiene algunas integraciones experimentales de las mejoras de compression de Intel y Cloudfare. Puedes intentar comstackr eso con git para ver cómo funciona.

zlib es más antiguo de lo que crees La mayoría del código de compression está relativamente sin cambios desde hace 20 años. La descompression fue reescrita hace unos 12 años.

No conozco ninguna implementación de git que use zlib o alternativas optimizadas. Sin embargo, he investigado un poco la compression y las compensaciones entre los niveles de compression y la velocidad, y si pretende mejorar significativamente el performance, generalmente obtendrá mejores resultados con un nuevo algorithm diseñado con la velocidad en mente que tratando de optimizar una algorithm existente. LZ4 es un buen ejemplo de un algorithm de compression diseñado con la velocidad como una prioridad sobre la relación de compression.

La naturaleza de los algorithms de compression significa que no tienden a paralelizar o SIMDify (que es realmente un tipo de paralelismo) de manera muy efectiva, particularmente si no se diseñaron con ese objective. La compression, por su propia naturaleza, implica dependencies de datos en serie en una transmisión.

Otra cosa a considerar con los algorithms de compression es si priorizar la velocidad de compression o descompression. Si su cuello de botella es el time que le toma al server comprimir datos, entonces quiere enfocarse en la compression rápida, pero en otras situaciones donde comprime una vez y descomprime a menudo (cargando activos del juego o buscando una página web estática, por ejemplo) entonces probablemente quiera priorizar la velocidad de descompression.

    Intereting Posts