對Zlib Java和C進行基准測試

Question

我正在嘗試通過切換到C來加速我最初使用Java編寫的TIFF編碼器，並編譯了Zlib 1.2.8並定義了Z_SOLO和最小的C文件集： adler32.c ， crc32.c ， deflate.c ， trees.c和zutil.c 。 Java正在使用java.util.zip.Deflater 。

我編寫了一個簡單的測試程序，用於評估壓縮級別和速度方面的性能，並且考慮到更高級別所需的時間越來越多，因此無論我需要什么級別，壓縮都沒有那么多，因此我感到困惑。 令我驚訝的是Java在壓縮和速度方面的表現實際上比Visual Studio Release-compile（VC2010）更好：

Java的：

Level 1 : 8424865 => 6215200 (73,8%) in 247 cycles.
Level 2 : 8424865 => 6178098 (73,3%) in 254 cycles.
Level 3 : 8424865 => 6181716 (73,4%) in 269 cycles.
Level 4 : 8424865 => 6337236 (75,2%) in 334 cycles.
Level 5 : 8424865 => 6331902 (75,2%) in 376 cycles.
Level 6 : 8424865 => 6333914 (75,2%) in 395 cycles.
Level 7 : 8424865 => 6333350 (75,2%) in 400 cycles.
Level 8 : 8424865 => 6331986 (75,2%) in 437 cycles.
Level 9 : 8424865 => 6331598 (75,2%) in 533 cycles.

C：

Level 1 : 8424865 => 6215586 (73.8%) in 298 cycles.
Level 2 : 8424865 => 6195280 (73.5%) in 309 cycles.
Level 3 : 8424865 => 6182748 (73.4%) in 331 cycles.
Level 4 : 8424865 => 6337942 (75.2%) in 406 cycles.
Level 5 : 8424865 => 6339203 (75.2%) in 457 cycles.
Level 6 : 8424865 => 6337100 (75.2%) in 481 cycles.
Level 7 : 8424865 => 6336396 (75.2%) in 492 cycles.
Level 8 : 8424865 => 6334293 (75.2%) in 547 cycles.
Level 9 : 8424865 => 6333084 (75.2%) in 688 cycles.

我是唯一一個目睹這種結果的人嗎？ 我的猜測是JVM中的Zlib正在使用我不包含在我的C項目中的匯編類型優化，或者在編譯Zlib（或Visual Studio編譯器很糟糕）時我錯過了一個明顯的配置步驟。

以下是兩個片段：

Java的：

public static void main(String[] args) throws IOException {
    byte[] pix = Files.readAllBytes(Paths.get("MY_MOSTLY_UNCOMPRESSED.TIFF"));
    int szin = pix.length;
    byte[] buf = new byte[szin*101/100];
    int szout;
    long t0, t1;

    for (int i = 1; i <= 9; i++) {
        t0 = System.currentTimeMillis();
        Deflater deflater = new Deflater(i);
        deflater.setInput(pix);
        szout = deflater.deflate(buf);
        deflater.finish();
        t1 = System.currentTimeMillis();
        System.out.println(String.format("Level %d : %d => %d (%.1f%%) in %d cycles.", i, szin, szout, 100.0f*szout/szin, t1 - t0));
    }
}

C：

#include <time.h>
#define SZIN 9000000
#define SZOUT 10000000
void main(void)
{
    static unsigned char buf[SZIN];
    static unsigned char out[SZOUT];
    clock_t t0, t1;
    int i, ret;
    uLongf sz, szin;
    FILE* f = fopen("MY_MOSTLY_UNCOMPRESSED.TIFF", "rb");
    szin = fread(buf, 1, SZIN, f);
    fclose(f);

    for (i = 1; i <= 9; i++) {
        sz = SZOUT;
        t0 = clock();
        compress2(out, &sz, buf, szin, i); // I rewrote compress2, as it's not available when Z_SOLO is defined
        t1 = clock();
        printf("Level %d : %d => %d (%.1f%%) in %ld cycles.\n", i, szin, sz, 100.0f*sz/szin, t1 - t0);
    }
}

編輯：

在@ MarkAdler的評論之后，我通過deflateInit2() （即Z_FILTERED和Z_HUFFMAN_ONLY ）嘗試了不同的壓縮策略：

Z_FILTERED ：

Level 1 : 8424865 => 6215586 (73.8%) in 299 cycles.
Level 2 : 8424865 => 6195280 (73.5%) in 310 cycles.
Level 3 : 8424865 => 6182748 (73.4%) in 330 cycles.
Level 4 : 8424865 => 6623409 (78.6%) in 471 cycles.
Level 5 : 8424865 => 6604616 (78.4%) in 501 cycles.
Level 6 : 8424865 => 6595698 (78.3%) in 528 cycles.
Level 7 : 8424865 => 6594845 (78.3%) in 536 cycles.
Level 8 : 8424865 => 6592863 (78.3%) in 595 cycles.
Level 9 : 8424865 => 6591118 (78.2%) in 741 cycles.

Z_HUFFMAN_ONLY ：

Level 1 : 8424865 => 6803043 (80.7%) in 111 cycles.
Level 2 : 8424865 => 6803043 (80.7%) in 108 cycles.
Level 3 : 8424865 => 6803043 (80.7%) in 106 cycles.
Level 4 : 8424865 => 6803043 (80.7%) in 106 cycles.
Level 5 : 8424865 => 6803043 (80.7%) in 107 cycles.
Level 6 : 8424865 => 6803043 (80.7%) in 106 cycles.
Level 7 : 8424865 => 6803043 (80.7%) in 107 cycles.
Level 8 : 8424865 => 6803043 (80.7%) in 108 cycles.
Level 9 : 8424865 => 6803043 (80.7%) in 107 cycles.

按照他的評論預計， Z_HUFFMAN_ONLY不會改變的壓縮，但執行速度快了很多 。 使用我的數據， Z_FILTERED並不比Z_DEFAULT_STRATEGY更快，壓縮也更差。

Answer 1

壓縮量和增量對於未壓縮的圖像數據而言並不令人驚訝，基本上沒有匹配的字符串。 被壓縮的數據部分沒有被進一步壓縮 - 它正在略微擴展一些恆定量，因此變化全部在未壓縮部分。

3級和4級之間的算法發生了變化，其中3級用於它找到的第一個匹配。 當幾乎沒有匹配的字符串時，這將傾向於最小化發送字符串匹配的開銷，因此壓縮效果更好。 如果使用FILTERED或HUFFMAN_ONLY完全關閉字符串匹配，您可能會做得更好。 HUFFMAN_ONLY還具有甚至不尋找匹配字符串的優點，顯着加快了壓縮速度。

至於速度差異，我只能猜測使用了不同的編譯器或不同的編譯器優化。