通过查看装配将值传递与引用传递性能进行比较

Question

I want to test a function in order to verify which one is faster, pass-by-value or pass-by-reference

Here is my test case : https://godbolt.org/g/cjaEx3

code :

struct Vec4f
{
  float val[4];
};


Vec4f suma(const Vec4f& a, const Vec4f& b)
{
  return {a.val[0] + b.val[0], 
          a.val[1] + b.val[1],
          a.val[2] + b.val[2],
          a.val[3] + b.val[3]};
}

Vec4f sumb(Vec4f a, Vec4f b)
{
  return {a.val[0] + b.val[0], 
          a.val[1] + b.val[1],
          a.val[2] + b.val[2],
          a.val[3] + b.val[3]};
}

assembly's output on x86-64 clang using -O3 -std=c++14 :

suma(Vec4f const&, Vec4f const&):                     # @suma(Vec4f const&, Vec4f const&)
        movq    xmm1, qword ptr [rdi]   # xmm1 = mem[0],zero
        movq    xmm0, qword ptr [rsi]   # xmm0 = mem[0],zero
        addps   xmm0, xmm1
        movq    xmm2, qword ptr [rdi + 8] # xmm2 = mem[0],zero
        movq    xmm1, qword ptr [rsi + 8] # xmm1 = mem[0],zero
        addps   xmm1, xmm2
        ret

sumb(Vec4f, Vec4f):                        # @sumb(Vec4f, Vec4f)
        addps   xmm0, xmm2
        addps   xmm1, xmm3
        ret

It turns out on gcc, clang, and msvc that passing by value produces fewer assembly in this particular case.

My questions are :

1. Is comparing assembly line count generally is a good heuristic for comparing performance of simple functions like these?

and also as I don't really understand the assembly output

2. Can you explain the assembly output of both suma and sumb function?

Interestingly, if I change Vec4f to have float val[40] instead, both functions produce the same assembly output. So,

3. What's the reason of the initial assembly difference?

Answer 1

1) No. Not all instructions execute in the same amount of time, and once memory needs to be accessed there can be a large latency.

2) and 3). suma needs to load the contents of a and b into appropriate registers. In sumb , those values are passed to the function already in the registers. In some cases, the register loading in suma will be done by sumb 's caller. In other cases, the values may already be in registers, and the suma caller will first need to store those values in memory so that it can create references to them.

When you use float val[40] that exceeds the capacity for passing values by register, so both functions will need to load the data from memory first (in suma , by dereferencing the reference; in sumb by loading the values off the stack).

Answer 2

1) Maybe this can be used as a heuristic, but it cannot be trusted at all. For example, a simple div instruction can be slower than 20 simple instructions. So I wouldn't bother looking at instruction counts at all.

2), 3)

Here's a little explanation the assembly you listed:

clang only uses half of the vector registers (xmmX can contain 4 float values, but clang only uses 2). Maybe it is because of calling conventions.

// this function has two reference parameters
// register rdi points to the first parameter (points to, so it is not the value of it, but a pointer)
// register rsi points to the second parameter
// register xmm0, xmm1 contains the result
suma(Vec4f const&, Vec4f const&):
        movq    xmm1, qword ptr [rdi]   # xmm1 will contain the first 2 floats of the first parameter
        movq    xmm0, qword ptr [rsi]   # xmm0 will contain the first 2 floats of the second parameter
        addps   xmm0, xmm1              # let's add them together, xmm0 contains the result
        movq    xmm2, qword ptr [rdi + 8] # xmm2 will contain the second 2 floats of the first parameter
        movq    xmm1, qword ptr [rsi + 8] # xmm1 will contain the second 2 floats of the second parameter
        addps   xmm1, xmm2              # let's add them together, xmm1 contains the result
        ret

// this function has to parameters
// first is passed in xmm0 and xmm1
// seconds is passed in xmm2 and xmm3
// register xmm0, xmm1 contains the result
sumb(Vec4f, Vec4f):
        addps   xmm0, xmm2
        addps   xmm1, xmm3
        ret

if I change Vec4f to have float val[40] instead, both functions produce the same assembly output.

This is false . They don't. They seem to be the same at first sight, but they are not.

There's code in both functions that is the same: because you return a float[40] , which has a lot of zero members, there should be code in both functions that zeros these elements. You see that code, and it is the same. The other parts differ.