情况:
我正在优化 LZF 压缩算法的纯 Java 实现，它涉及大量 byte[] 访问和用于散列和比较的基本 int 数学。性能真的很重要，因为压缩的目标是减少 I/O 要求。我没有发布代码，因为它尚未清理干净，并且可能会进行大量重组。
问题:

public int compressNewer(final byte[] in, final int inLen, final byte[] out, int outPos){
        int inPos = 0;
        // initialize the hash table
        if (cachedHashTable == null) {
            cachedHashTable = new int[HASH_SIZE];
        } else {
            System.arraycopy(EMPTY, 0, cachedHashTable, 0, HASH_SIZE);
        }
        int[] hashTab = cachedHashTable;
        // number of literals in current run
        int literals = 0;
        int future = first(in, inPos);
        final int endPos = inLen-4;

        // Loop through data until all of it has been compressed
        while (inPos < endPos) {
                future = (future << 8) | in[inPos+2] & 255;
//                hash = next(hash,in,inPos);
                int off = hash(future);
                // ref = possible index of matching group in data
                int ref = hashTab[off];
                hashTab[off] = inPos;
                off = inPos - ref - 1; //dropped for speed

                // has match if bytes at ref match bytes in future, etc
                // note: using ref++ rather than ref+1, ref+2, etc is about 15% faster
                boolean hasMatch = (ref > 0 && off <= MAX_OFF && (in[ref++] == (byte) (future >> 16) && in[ref++] == (byte)(future >> 8) && in[ref] == (byte)future));

                ref -=2; // ...EVEN when I have to recover it
                // write out literals, if max literals reached, OR has a match
                if ((hasMatch && literals != 0) || (literals == MAX_LITERAL)) {
                    out[outPos++] = (byte) (literals - 1);
                    System.arraycopy(in, inPos - literals, out, outPos, literals);
                    outPos += literals;
                    literals = 0;
                }

                //literal copying split because this improved performance by 5%

                if (hasMatch) { // grow match as much as possible
                    int maxLen = inLen - inPos - 2;
                    maxLen = maxLen > MAX_REF ? MAX_REF : maxLen;
                    int len = 3;
                    // grow match length as possible...
                    while (len < maxLen && in[ref + len] == in[inPos + len]) {
                        len++;
                    }
                    len -= 2;

                    // short matches write length to first byte, longer write to 2nd too
                    if (len < 7) {
                        out[outPos++] = (byte) ((off >> 8) + (len << 5));
                    } else {
                        out[outPos++] = (byte) ((off >> 8) + (7 << 5));
                        out[outPos++] = (byte) (len - 7);
                    }
                    out[outPos++] = (byte) off;
                    inPos += len;

                    //OPTIMIZATION: don't store hashtable entry for last byte of match and next byte
                    // rebuild neighborhood for hashing, but don't store location for this 3-byte group
                    // improves compress performance by ~10% or more, sacrificing ~2% compression...
                    future = ((in[inPos+1] & 255) << 16) | ((in[inPos + 2] & 255) << 8) | (in[inPos + 3] & 255);
                    inPos += 2;
                } else { //grow literals
                    literals++;
                    inPos++;
                } 
        }
        
        // write out remaining literals
        literals += inLen-inPos;
        inPos = inLen-literals;
        if(literals >= MAX_LITERAL){
            out[outPos++] = (byte)(MAX_LITERAL-1);
            System.arraycopy(in, inPos, out, outPos, MAX_LITERAL);
            outPos += MAX_LITERAL;
            inPos += MAX_LITERAL;
            literals -= MAX_LITERAL;
        }
        if (literals != 0) {
            out[outPos++] = (byte) (literals - 1);
            System.arraycopy(in, inPos, out, outPos, literals);
            outPos += literals;
        }
        return outPos; 
    }

最佳答案

不是完整的答案，我只是没有时间做您的问题需要的详细基准测试，但希望有用。

了解你的敌人

您的目标是 JVM(本质上是 JIT)和底层 CPU/内存子系统的组合。因此，当您进入更积极的优化时，“这在 JVM X 上更快”不太可能在所有情况下都有效。

如果您的目标市场/应用程序将主要在特定架构上运行，您应该考虑投资于特定于它的工具。
* 如果您在 x86 上的性能是关键因素，那么英特尔的 VTune非常适合深入了解 jit output analysis你描述。
* 64 位和 32 位 JIT 之间的差异可能相当大，尤其是在 x86 平台上，调用约定可以更改和 enregistering机会非常不同。

获得正确的工具

您可能想要一个采样分析器。针对您的特定需求的检测开销(以及相关联的内联、缓存污染和代码大小膨胀等问题)的开销太大了。英特尔 VTune 分析器实际上可以用于 Java，尽管集成不像其他分析器那么紧密。
如果您使用的是 sun JVM 并且很高兴只知道最新/最好的版本在做什么，那么 investigate the output of the JIT 可用的选项如果你知道一点组装，那是相当可观的。
此 article details some interesting analysis using this functionality

从其他实现中学习

The Change history更改历史表明以前的内联汇编实际上适得其反，并且允许编译器完全控制输出(通过代码中的调整而不是汇编中的指令)产生更好的结果。

一些细节

由于 LZF 在现代桌面 CPU 上的高效非托管实现中，很大程度上受内存带宽限制(因此它与未优化的 memcpy 的速度相比)，因此您需要将代码完全保留在 1 级缓存中。
因此，任何不能作为常量的静态字段都应放置在同一个类中，因为这些值通常放置在专用于与类相关联的 vtable 和元数据的同一内存区域中。

需要避免逃逸分析无法捕获的对象分配(仅在 1.6 及更高版本中)。

c code积极使用循环展开。然而，这在较旧的(1.4 时代)VM 上的性能是 heavily dependant on the mode the JVM is in .显然，后来的 sun jvm 版本在内联和展开方面更加激进，尤其是在服务器模式下。

JIT 生成的预取指令可以对像这样接近内存限制的代码产生很大的影响。

“它直接来找我们”

您的目标正在移动，并将继续移动。再次 Marc Lehmann 之前的经历:

default HLOG size is now 15 (cpu caches have increased)

6544668 Don't vecorized array operations that can't be aligned at runtime. 6536652 Implement some superword (SIMD) optimizations 6531696 don't use immediate 16-bits value store to memory on Intel cpus 6468290 Divide and allocate out of eden on a per cpu basis

关于java - 如何编写 Java 代码以允许使用 SSE 和边界检查消除(或其他高级优化)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1352422/