avx

问题 I am trying to implement and code on some files, some of which contain SIMD-calls. I have compiled this code on a server, running basically the same OS as my machine, yet i cant compile it. This is the error: make g++ main.cpp -march=native -o main -fopenmp In file included from /usr/lib/gcc/x86_64-linux-gnu/7/include/immintrin.h:53:0, from tensor.hpp:9, from main.cpp:4: /usr/lib/gcc/x86_64-linux-gnu/7/include/avx512vlintrin.h: In function ‘_ZN6TensorIdE8add_avx2ERKS0_._omp_fn.5’: /usr/lib

问题 There are generally two types of SIMD instructions: A. Ones that work with aligned memory addresses, that will raise general-protection (#GP) exception if the address is not aligned on the operand size boundary: movaps xmm0, xmmword ptr [rax] vmovaps ymm0, ymmword ptr [rax] vmovaps zmm0, zmmword ptr [rax] B. And the ones that work with unaligned memory addresses, that will not raise such exception: movups xmm0, xmmword ptr [rax] vmovups ymm0, ymmword ptr [rax] vmovups zmm0, zmmword ptr [rax]

问题 Along with the introduction of AVX, Intel introduced the VEX encoding scheme into the Intel 64 and IA-32 architecture. This encoding scheme is used mostly with AVX instructions. I was wondering if it's okay to intermix VEX-encoded instructions and the now called "legacy SSE" instructions. The main reason for me asking this question is code size. Consider these two instructions : shufps xmm0, xmm0, 0 vshufps xmm0, xmm0, xmm0, 0 I commonly use the first one to "broadcast" a scalar value to all

问题 The problem can be described as follow. Input __m256d a, b, c, d Output __m256d s = {a[0]+a[1]+a[2]+a[3], b[0]+b[1]+b[2]+b[3], c[0]+c[1]+c[2]+c[3], d[0]+d[1]+d[2]+d[3]} Work I have done so far It seemed easy enough: two VHADD with some shuffling in-between but in fact combining all permutations featured by AVX can't generate the very permutation needed to achieve that goal. Let me explain: VHADD x, a, b => x = {a[0]+a[1], b[0]+b[1], a[2]+a[3], b[2]+b[3]} VHADD y, c, d => y = {c[0]+c[1], d[0]

问题 I have 8 AVX vectors containing 8 floats each (64 floats in total) and I want to sum elements in each vector together (basically perform eight horizontal sums). For now, I'm using the following code: __m256 HorizontalSums(__m256 v0, __m256 v1, __m256 v2, __m256 v3, __m256 v4, __m256 v5, __m256 v6, __m256 v7) { // transpose const __m256 t0 = _mm256_unpacklo_ps(v0, v1); const __m256 t1 = _mm256_unpackhi_ps(v0, v1); const __m256 t2 = _mm256_unpacklo_ps(v2, v3); const __m256 t3 = _mm256_unpackhi

问题 The AVX instruction set introduced VPERMILPS which seems to be a simplified version of SHUFPS (for the case where both input registers are the same). For example, the following instruction: c5 f0 c6 c1 00 vshufps xmm0,xmm1,xmm1,0x0 can be replaced with: c4 e3 79 04 c1 00 vpermilps xmm0,xmm1,0x0 As you can see, the VPERMILPS version takes one byte extra and does the same thing. According to the instruction tables, both of the instructions take 1 CPU cycle and have the same throughput. What's

问题 Let's say I have the following struct A { __m256 a; } struct B { __m256 a; float b; } Which of the following's generally better (if any and why) in a hard core loop? void f0(A a) { ... } void f1(A& a) { ... } //and the pointer variation void f2(B b) { ...} void f3(B& b) { ... } //and the pointer variation 回答1: The answer is that it doesn't matter. According to this: http://msdn.microsoft.com/en-us/library/ms235286.aspx The calling convention states that 16-byte (and probably 32-byte) operands

问题 I have an algorithm which benefits from hand optimisation with SSE(2) intrinsics. Moreover, the algorithm will also be able to benefit from the 256-bit AVX registers in the future. My question is what is the best way to Register the availability variants of my class at compile time; so if my classes are, say: Foo , FooSSE2 and FooAVX I require a means of determining at runtime what classes are compiled in. Determine the capabilities of the current CPU. At the lowest level this will result in

问题 I would like to know if the following is possible in any of the SIMD families of instructions. I have a qword input with 63 significant bits (never negative). Each sequential 7 bits starting from the LSB is shuffle-aligned to a byte, with a left-padding of 1 (except for the most significant non-zero byte). To illustrate, I'll use letters for clarity's sake. The result is only the significant bytes, thus 0 - 9 in size, which is converted to a byte array. In: 0|kjihgfe|dcbaZYX|WVUTSRQ|PONMLKJ

问题 I have a Java loop that looks like this: public void testMethod() { int[] nums = new int[10]; for (int i = 0; i < nums.length; i++) { nums[i] = 0x42; } } The assembly I get is this: 0x00000001296ac845: cmp %r10d,%ebp 0x00000001296ac848: jae 0x00000001296ac8b4 0x00000001296ac84a: movl $0x42,0x10(%rbx,%rbp,4) 0x00000001296ac852: inc %ebp 0x00000001296ac854: cmp %r11d,%ebp 0x00000001296ac857: jl 0x00000001296ac845 0x00000001296ac859: mov %r10d,%r8d 0x00000001296ac85c: add $0xfffffffd,%r8d