尽管广泛阅读了JDK源代码并检查了内在例程,但我还是不能一概而论。

我正在测试清除ByteBuffer,并使用allocateDirect分配了ByteBuffer.putLong(int index, long value)。基于JDK代码,如果缓冲区为“本机字节顺序”,则将导致单个8字节的写操作;否则,将导致字节写操作;否则,将导致相同的写操作。

因此,我希望本机字节顺序(对我来说是小尾数)至少与非本机字节一样快。但是事实证明,非本地的速度要快2倍左右。

这是我在Caliper 0.5x中的基准:

...

public class ByteBufferBench extends SimpleBenchmark {

    private static final int SIZE = 2048;

    enum Endian {
        DEFAULT,
        SMALL,
        BIG
    }

    @Param Endian endian;

    private ByteBuffer bufferMember;

    @Override
    protected void setUp() throws Exception {
        super.setUp();
        bufferMember = ByteBuffer.allocateDirect(SIZE);
        bufferMember.order(endian == Endian.DEFAULT ? bufferMember.order() :
            (endian == Endian.SMALL ? ByteOrder.LITTLE_ENDIAN : ByteOrder.BIG_ENDIAN));
    }

    public int timeClearLong(int reps) {
        ByteBuffer buffer = bufferMember;
        while (reps-- > 0) {
            for (int i=0; i < SIZE / LONG_BYTES; i+= LONG_BYTES) {
                buffer.putLong(i, reps);
            }
        }
        return 0;
    }

    public static void main(String[] args) {
        Runner.main(ByteBufferBench.class,args);
    }

}

结果是:
benchmark       type  endian     ns linear runtime
ClearLong     DIRECT DEFAULT   64.8 =
ClearLong     DIRECT   SMALL  118.6 ==
ClearLong     DIRECT     BIG   64.8 =

这是一致的。如果我将putLong交换为putFloat,则本机订单的速度快约4倍。如果您查看putLong的工作方式,那么在非本地情况下,它的工作量绝对更多:
private ByteBuffer putLong(long a, long x) {
    if (unaligned) {
        long y = (x);
        unsafe.putLong(a, (nativeByteOrder ? y : Bits.swap(y)));
    } else {
        Bits.putLong(a, x, bigEndian);
    }
    return this;
}

请注意,每种情况下unaligned为true。本机字节顺序和非本机字节顺序之间的唯一区别是Bits.swap,它支持本机大小写(little-endian)。

最佳答案

总结机械同情邮件列表中的讨论:

1,OP所描述的异常无法在我的设置(JDK7u40 / Ubuntu13.04 / i7)上重现,从而导致所有情况下堆和直接缓冲区的性能保持一致,而直接缓冲区具有巨大的性能优势:

BYTE_ARRAY DEFAULT 211.1 ==============================
BYTE_ARRAY   SMALL 199.8 ============================
BYTE_ARRAY     BIG 210.5 =============================
DIRECT DEFAULT  33.8 ====
DIRECT   SMALL  33.5 ====
DIRECT     BIG  33.7 ====

Bits.swap(y)方法被固有地限制在一条指令中,因此不能/不应该真正考虑很大的差异/开销。

2,以上结果(即与OP经验相矛盾)由幼稚的手动基准和另一位参与者编写的JMH基准独立确认。

这使我相信您正在遇到一些本地问题或某种基准框架问题。如果其他人可以进行实验并查看他们是否可以重现您的结果,那将很有价值。

10-05 22:54