Dosyanın başlangıcından sonuna kadar açmadan daha verimli bir şey yapmanın mümkün olup olmadığını merak ettim. Cevabın hayır olduğu anlaşılıyor. Ancak, bazı CPU'larda (Skylake) zcat | tailCPU'yu tam saat hızına yükseltmez. Aşağıya bakınız. Özel bir dekoder bu sorunu önleyebilir ve boru yazma sistemi çağrılarını kaydedebilir ve belki ~% 10 daha hızlı olabilir. (Veya güç yönetimi ayarlarını değiştirmezseniz Skylake'te ~% 60 daha hızlı).
skipbytesFonksiyonu olan özelleştirilmiş bir zlib ile yapabileceğiniz en iyi şey, sıkıştırılmış bloğu gerçekten yeniden yapılandırma işi yapmadan sonuna ulaşmak için bir sıkıştırma bloğundaki sembolleri ayrıştırmak olacaktır. Bu, aynı arabelleğin üzerine yazmak ve dosyada ilerlemek için zlib'in normal kod çözme işlevini çağırmaktan önemli ölçüde daha hızlı olabilir (muhtemelen en az 2x). Ama kimsenin böyle bir işlev yazıp yazmadığını bilmiyorum. (Ve dosya çözücünün belirli bir blokta yeniden başlamasına izin vermek için özel olarak yazılmadığı sürece bunun aslında işe yaramadığını düşünüyorum).
Blokları çözmeden Deflate bloklarını atlamanın bir yolu olduğunu umuyordum, çünkü bu çok daha hızlı olurdu . Huffman ağacı her bloğun başında gönderilir, böylece herhangi bir bloğun başından kodunu çözebilirsiniz (sanırım). Oh, bence dekoder durumu Huffman ağacından daha fazla, aynı zamanda kod çözülmüş verilerin önceki 32kiB'si ve bu varsayılan olarak blok sınırları boyunca sıfırlanmıyor / unutulmuyor. Aynı baytlara tekrar tekrar başvurulmaya devam edilebilir, bu nedenle dev sıkıştırılmış bir dosyada yalnızca bir kez görünebilir. (örneğin, bir günlük dosyasında, ana makine adı muhtemelen sıkıştırma sözlüğünde sürekli olarak "sıcak" kalır ve her örneği birincisine değil, öncekine başvurur).
zlibManuel kullanımdan gerektiği yazıyor Z_FULL_FLUSHçağrılırken deflatesen sıkıştırılmış akışı bu noktaya seekable olmasını istiyorsanız. "Sıkıştırma durumunu sıfırlar", bu yüzden bence, geriye dönük referanslar önceki blok (lar) içine gidebilirsiniz. Zip dosyanız zaman zaman tam floş blokları ile yazılmadığı sürece (her 1G veya bir şey sıkıştırma üzerinde ihmal edilebilir bir etki yaratacaktır), bence kod çözme işini başlangıçta benden daha fazla yapmak zorunda kalabilirsiniz. düşünce. Sanırım muhtemelen herhangi bir bloğun başında başlayamazsınız.
Bunun geri kalanı, istediğiniz ilk baytı içeren bloğun başlangıcını bulmak ve oradan kod çözmenin mümkün olacağını düşünürken yazılmıştır.
Ancak ne yazık ki, Deflate bloğunun başlangıcı sıkıştırılmış bloklar için ne kadar sürdüğünü göstermez . Sıkıştırılamaz veriler, öndeki bayt cinsinden 16 bit büyüklüğüne sahip sıkıştırılmamış bir blok türüyle kodlanabilir, ancak sıkıştırılmış bloklar şunları yapmaz: RFC 1951 formatı oldukça okunaklı bir şekilde açıklar . Dinamik Huffman kodlu bloklar bloğun önünde ağaca sahiptir (bu nedenle dekompresör akışta aramak zorunda değildir), bu nedenle kompresörün yazmadan önce tüm (sıkıştırılmış) bloğu hafızada tutması gerekir.
Maksimum geriye doğru referans mesafesi sadece 32kiB'dir, bu nedenle kompresörün sıkıştırılmamış çok fazla veriyi bellekte tutması gerekmez, ancak bu blok boyutunu sınırlamaz. Bloklar birden fazla megabayt uzunluğunda olabilir. (Disk, manyetik diskte bile buna değecek kadar büyüktür, ancak mevcut bloğun sonunu bulmadan bulmak mümkün olsaydı, sırayla belleğe okumak ve sadece RAM'de veri atlamak gibi).
zlib olabildiğince uzun bloklar yapar:
Marc Adler'e göre , zlib sadece sembol arabelleği dolduğunda yeni bir blok başlatır ve varsayılan ayar 16.383 semboldür (değişmez değerler veya eşleşmeler)
Ben seq(son derece gereksiz ve muhtemelen büyük bir test değil) pv < /tmp/seq1G.gz | gzip -d | tail -c $((1024*1024*1000)) | wc -cçıktı gzipped, ancak bu sadece DDR4-2666 RAM ile 3.9GHz bir Skylake i7-6700k ~ 62 MiB / s sıkıştırılmış veri çalışır. Bu memcpy, önbelleğe sığmayacak kadar büyük blok boyutları için ~ 12 GiB / s hızına kıyasla yığın değişikliği olan 246MiB / s'lik sıkıştırılmış verilerdir .
( Skylake'in dahili CPU valisi yerine energy_performance_preferencevarsayılan olarak ayarlandığında , sadece 2,7GHz, ~ 43 MiB / s sıkıştırılmış veri ile çalışmaya karar verir. Ayarlamak için kullanırım . Muhtemelen bu tür sistem çağrıları gerçek CPU'ya bağlı görünmüyor güç yönetimi birimine çalışın.)balance_powerbalance_performancesudo sh -c 'for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference;do echo balance_performance > "$i";done'
TL: DR: Çok yavaş diskleriniz zcat | tail -colmadığı sürece hızlı bir CPU'ya bile CPU bağlıdır . gzip, üzerinde çalıştığı CPU'nun% 100'ünü kullandı (ve buna göre saat başına 1.81 talimatı çalıştırdı perf) ve tailçalıştırdığı CPU'nun 0.162'sini (0.58 IPC) kullandı. Sistem aksi halde çoğunlukla boştu.
Meltdown etrafında çalışmak için varsayılan olarak KPTI etkinleştirilmiş Linux 4.14.11-1-ARCH kullanıyorum , bu nedenle tüm bu writesistem çağrıları gzipeskisinden daha pahalı: /
Aramanın yerleşik olması unzipveya zcat(ancak normal zlibkod çözme işlevinin kullanılması) tüm bu boru yazmalarını kaydeder ve Skylake CPU'ların tam saat hızında çalışmasını sağlar. (Bazı yük türleri için bu hız aşırtma, CPU frekansı karar verme işlemini işletim sisteminden indiren Intel Skylake ve sonraki sürümlere özgüdür, çünkü CPU'nun ne yaptığı hakkında daha fazla veriye sahiptirler ve daha hızlı yukarı / aşağı rampa yapabilirler. normalde iyi, ancak burada Skylake daha muhafazakar bir vali ayarı ile tam hıza ulaşmıyor).
Hiçbir sistem çağrısı yok, sadece istediğiniz başlangıç bayt konumuna ulaşana kadar L2 önbelleğine uyan bir arabelleği yeniden yazmak, muhtemelen en azından% birkaç fark yaratacaktır. Belki% 10 bile, ama burada sadece sayılar yapıyorum. zlibÖnbellek kapladığı alanın ne kadar büyük olduğunu ve her sistem çağrısındaki TLB floşunun (ve dolayısıyla uop-önbellek floşunun) KPTI etkinken ne kadar acı verdiğini görmek için herhangi bir ayrıntıda profilli değilim.
Gzip dosya biçimine arama dizini ekleyen birkaç yazılım projesi vardır . Kimsenin sizin için aranabilir sıkıştırılmış dosyalar oluşturmasını sağlayamazsanız bu size yardımcı olmaz, ancak gelecekteki diğer okuyucular fayda sağlayabilir.
Tahminen ne bu projelerin bir indeks zaman onlar sadece işin için tasarlanmış çünkü, bir dizin olmadan Deflate akımına atlamasına bilen bir kod çözme fonksiyonu var olan mevcut.