4 ms·
vector<double> c(MM); => Initializes all c[i] to 0.0. Thus it writes to each entry (causing a cache fill or cache allocate depending on copy-back versus write-
by hermanhermitage 15y ago
vector<double> c(MM);
=> Initializes all c[i] to 0.0. Thus it writes to each entry (causing a cache fill or cache allocate depending on copy-back versus write-thru configuration of cache). Thus in the timed C++ loop access to c[] is mainly at minimal latency.
To reproduce the behaviour change the C init to:
for(i = 0; i < MM; ++i){
a[i] = 1.0/(double)(i+1);
b[i] = a[i];
c[i] = 0;
}
Then your times will coincide.
On my machine here the inner loops are identical:
gcc -O9 test.c -S:
callq _clock
movq %rax, %r13
.align 4, 0x90
LBB2_3:
movsd (%rbx,%r12,8), %xmm0
addsd (%r14,%r12,8), %xmm0
movsd %xmm0, (%r15,%r12,8)
incq %r12
cmpq $90000000, %r12
jne LBB2_3
callq _clock
g++ -O9 test.cc -S
callq _clock
movq %rax, %r13
.align 4, 0x90
LBB5_19:
movsd (%rbx,%r12,8), %xmm0
addsd (%r14,%r12,8), %xmm0
movsd %xmm0, (%r15,%r12,8)
incq %r12
cmpq $90000000, %r12
jne LBB5_19
callq _clock
(gcc/g++ 4.2 on Mac OS X)
Furthermore, compiling on Intel Fortran with the same change to pre load c into cache:
do i = 1,MM
a(i) = 1.0/dble(i)
b(i) = a(i)
c(i) = 0.0
enddo
and compiling with ifort -fast test.f90, I get a performance 1.33x greater in fortran than C/C++.
C: 0.168993
C++: 0.169194
F90: 0.122215
Intel Fortran is compiling with more aggressive detection of AVX etc out of the box. A modern version of GCC or adding compiler switches might get it to meet the f90 figures.
So this all highlights how difficult micro benchmarks are to get right. It's much easier to measure sustained thruput than create accurate micro benchmarks.