We're migrating to LLVM 3.1 and trying to use the upstream FMA patterns.
Why is VFMADDSD4 defined with vector types? Is this simply because the
gcc intrinsic uses vector types? It's quite unnatural if you have a
compiler that generates FMAs as opposed to requiring user intrinsics.
-Dave
Because the intrinsics uses vector types (same as gcc).
- Jan
Hey Jan and Dave,
It’s not obvious, but there is a significant scalar performance issue following the GCC intrinsics.
Let’s look at the VFMADDSD pattern. We’re operating on scalars with undefineds as the remaining vector elements of the operands. This sounds okay, but when one looks closer…
vmovsd fp4_+1088(%rip), %xmm3 # fpppp.f:647
vmovaps %xmm3, 18560(%rsp) # fpppp.f:647 <= 16-byte spill
vfmaddsd %xmm5, fp4_+3288(%rip), %xmm3, %xmm3 # fpppp.f:647
The spill here is 16-bytes. But, we’re only using the low 8-bytes of xmm3. Changing the intrinsics and patterns to accept scalar operands, we end up with…
vmovsd fp4_+1056(%rip), %xmm0 # fpppp.f:666
vmovsd %xmm0, 10088(%rsp) # fpppp.f:666 <= 8-byte spill
vfmaddsd %xmm3, fp4_+3288(%rip), %xmm0, %xmm3 # fpppp.f:666
I do not know the actual number of cycles offhand, but I believe on Interlagos and Sandybridge, a vmovaps takes roughly 3x as many micro-ops as a vmovsd if it involves memory.
-Cameron
Jan Sjodin <jan_sjodin@yahoo.com> writes:
Because the intrinsics uses vector types (same as gcc).
Ok, so there's no fundamental reason. We are working on fixing this so
that compilers that auto-generate FMAs can produce efficient code.
We'll be sending this work up once our 3.1 integration is finished.
It's just a matter of adding some new patterns.
-Dave
Ah, bad example. This is a general problem for all (maybe most) SSE and AVX SS/SD patterns though, which is why I mentioned Sandybridge. You can swap out VFMADDSD in my example for VADDSD or whatever you like.
I have a lion’s share of such a change implemented already and performance is greatly affected. If the community is interested in this change, I would be happy to prepare a patch.
-Cameron
Jan Sjodin <jan_sjodin@yahoo.com> writes:
You can't execute FMA4 instructions on Intel processors, so it doesn't
really matter what the impact of the move instructions would be, since
it would end up with an illegal instruction regardless.
Interlagos? All the world is not Intel.
It does perhaps bring up an issue of tuning for different
architectures, but that is something nobody is really looking into at
the moment afaik.
*ahem*
-Dave
Just looked up the numbers from Agner Fog for Sandy Bridge for vmovaps/etc for loading/storing from memory.
vmovaps - load takes 1 load mu op, 3 latency, with a reciprocal throughput of 0.5.
vmovaps - store takes 1 store mu op, 1 load mu op for address calculation, 3 latency, with a reciprocal throughput of 1.
He does not list vmovsd, but movsd has the same stats as vmovaps, so I feel it is a safe assumption to make that vmovsd has the same stats as well.
Michael
Hey Michael,
Thanks for the legwork!
It appears that the stats you listed are for movaps [SSE], not vmovaps [AVX]. I would assume that vmovaps(m128) is closer to vmovaps(m256), since they are both AVX instructions. Although, yes, I agree that this is not clear from Agner’s report. Please correct me if I am misunderstanding.
As I am sure you are aware, we cannot use SSE (movaps) instructions in an AVX context, or else we’ll pay the context switch penalty. It might be too big an assumption to assume that movaps and vmovaps have the same timings. Same for movsd.
Also, I’m sure you are aware that the Sandybridge optimization guide suggests that unaligned stores be split into a 128b store and 128b extract. This does argue against my above assumption.
For full disclosure, I have not timed the individual instructions; just kernels. So, my performance gains may be coming from another source related to this change. Most likely, my gains are from better use of cache, since we would not be moving unneeded bytes around. In the context of shared cache, this savings may be enough to keep the other cores more busy. Not to mention the stack space saved. But, I cannot say for sure right now.
It appears that the stats you listed are for movaps [SSE], not vmovaps [AVX]. I would assume that vmovaps(m128) is closer to vmovaps(m256), since they are both AVX instructions. Although, yes, I agree that this is not clear from Agner’s report. Please correct me if I am misunderstanding.
You are misunderstanding [no worries, happens to everyone = )]. The timings I listed were for vmovaps of the form,
vmovaps %xmm0, (mem)
i.e., its form as a 128 bit AVX instruction. Let me explain. There are 3 categories of instructions we are discussing:
First note that 1,2 are exactly the same performance wise. The difference in between 1,2 is as follows: When you use a 256 bit AVX instruction, you cause a ``dirty state’’ to be entered**. After that occurs, every SSE instruction used will cause the processor to save/restore the upper 128 bits of the ymm register aliased onto the output xmm register of the SSE instruction, resulting in bad performance. On the other hand, if you use the 128 bit AVX form of the SSE instructions, you are signaling to the processor that you do not care about the upper 128 bits of the aliased ymm register and thus it can just zero the top bits. Thus the bad performance is avoided. That is the whole point of the 128 bit AVX form of the SSE instructions, to enable you to mix SSE/AVX instructions without paying said penalty. Calling vzeroupper restores the ymm registers to a clean state allowing you to use the normal SSE instructions again without slowdown.
Additionally note that the 128 bit AVX instructions do not cause the ``dirty state’’ to be entered allowing you to mix/match with normal SSE and take advantage of the lack of implicit arguments/nice non-destructive encoding if you choose to (in case you can’t tell I like the non-destructive encoding a lot).
As I am sure you are aware, we cannot use SSE (movaps) instructions in an AVX context, or else we’ll pay the context switch penalty. It might be too big an assumption to assume that movaps and vmovaps have the same timings. Same for moved.
See above.
Also, I’m sure you are aware that the Sandybridge optimization guide suggests that unaligned stores be split into a 128b store and 128b extract. This does argue against my above assumption.
This is true. The reason that they suggest that is so that you avoid storing over a page boundary which causes obscene slow downs. As an aside if you are doing any vector coding, you should always align the stores and use unaligned loads.
For full disclosure, I have not timed the individual instructions; just kernels. So, my performance gains may be coming from another source related to this change. Most likely, my gains are from better use of cache, since we would not be moving unneeded bytes around. In the context of shared cache, this savings may be enough to keep the other cores more busy. Not to mention the stack space saved. But, I cannot say for sure right now.
I have actually timed said instructions in the past and reproduced Agner Fog’s results. I just prefer to speak by referring to facts that can not be misconstrued as hearsay = ).
But if you don’t believe me, time the instructions yourself (its an important thing to have in your toolbox anyways since sometimes Intel’s documentation can be non-specific). I have a small instruction timing project lying around somewhere, if you want it I can send it to you privately.
Michael
...
I have actually timed said instructions in the past and reproduced Agner
Fog's results. I just prefer to speak by referring to facts that can not be
misconstrued as hearsay = ).
That would be great. Also, can you point me to the Agner Fog table
that you are referring to? Thanks.
I am sending the Agner Fog table offline. Do you want the instruction timer thing as well?
Our specialists (Intel) say that “vmovaps” and “vmovsd” have the same throughput and latency, but “vmovsd” reduces chance of 4k aliasing, so it is preferable.
- Elena
Michael Gottesman <mgottesman@apple.com> writes:
But if you don't believe me, time the instructions yourself (its an
important thing to have in your toolbox anyways since sometimes Intel's
documentation can be non-specific). I have a small instruction timing
project lying around somewhere, if you want it I can send it to you
privately.
Note that timings aren't everything. Second-order effects can be
meaningful. I've seen it many times. I would not be surprised at all
if a scalar spill/restore is much faster than a vector one due to the
lower impact on cache bandwidth. We know that scalar spill/reload is
much better. We have seen it in many real codes.
Single instruction timings and small kernels can be very, very
misleading.
-Dave