x86-64

There is a curious difference between assemblies of a small program, when compiled as a C-program or as a C++-program (for Linux x86-64). The code in question: int fun(); int main(){ return fun(); } Compiling it as a C-program (with gcc -O2 ) yields: main: xorl %eax, %eax jmp fun But compiling it as a C++-program (with g++ -02 ) yields: main: jmp _Z3funv I find it puzzling, that the C-version initializes the return value of the main-function with 0 ( xorl %eax, %eax ). Which feature of the C-language is responsible for this necessity? Edit: It is true that, for int fun(void); the is no

I have some highly perf sensitive code. A SIMD implementation using SSEn and AVX uses about 30 instructions, while a version that uses a 4096 byte lookup table uses about 8 instructions. In a microbenchmark, the lookup table is faster by 40%. If I microbenchmark, trying to invalidate the cache very 100 iterations, they appear about the same. In my real program, it appears that the non-loading version is faster, but it's really hard to get a provably good measurement, and I've had measurements go both ways. I'm just wondering if there are some good ways to think about which one would be better

In the Intel intrinsics webapp , several operations seem to have worsened from Sandy Bridge to Haswell. For example, many insert operations like _mm256_insertf128_si256 show a cost table like the following: Performance Architecture Latency Throughput Haswell 3 - Ivy Bridge 1 - Sandy Bridge 1 - I found this difference puzzling. Is this difference because there are new instructions that replace these ones or something that compensates for it (which ones)? Does anyone know if Skylake changes this model further? Peter Cordes TL:DR : all lane-crossing shuffles / inserts / extracts have 3c latency

When I write to a register, everything is fine, movq $0xffffffffffffffff, %rax But I get Error: operand size mismatch when I write to a memory location, movq $0xffffffffffffffff, -8(%rbp) Why is that? I see in compiled C code that in asm these numbers are split in two and two movl instructions show up. Maybe you can tell me where the mowq and other instructions are documented. Why is that? Because MOV r64, imm64 is a valid x86 instruction, but MOV r/m64, imm64 is not (there's no encoding for it). I see in compiled C code that in asm these numbers are split in two and two movl instructions show