Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Short Answer:</strong> It's a compiler hiccup. x64 optimizer fail.</p> <hr> <p><strong>Long Answer:</strong></p> <p>This x86 version is very slow if SSE2 is disabled. But I'm able to reproduce the results with SSE2 enabled in x86.</p> <p>If you dive into the assembly of that inner-most loop. The x64 version has two extra memory copies at the end.</p> <p><strong>x86:</strong></p> <pre><code>$LL71@main: movsd xmm2, QWORD PTR [eax-8] movsd xmm0, QWORD PTR [eax-16] movsd xmm3, QWORD PTR [eax] movapd xmm1, xmm0 mulsd xmm0, QWORD PTR __real@3fa60418a0000000 movapd xmm7, xmm2 mulsd xmm2, QWORD PTR __real@3f95810620000000 mulsd xmm7, xmm5 mulsd xmm1, xmm4 addsd xmm1, xmm7 movapd xmm7, xmm3 mulsd xmm3, QWORD PTR __real@3fdcccccc0000000 mulsd xmm7, xmm6 add eax, 24 ; 00000018H addsd xmm1, xmm7 addsd xmm0, xmm2 movq QWORD PTR [ecx], xmm1 addsd xmm0, xmm3 movq QWORD PTR [ecx+8], xmm0 lea edx, DWORD PTR [eax-16] add ecx, 16 ; 00000010H cmp edx, esi jne SHORT $LL71@main </code></pre> <p><strong>x64:</strong></p> <pre><code>$LL175@main: movsdx xmm3, QWORD PTR [rdx-8] movsdx xmm5, QWORD PTR [rdx-16] movsdx xmm4, QWORD PTR [rdx] movapd xmm2, xmm3 mulsd xmm2, xmm6 movapd xmm0, xmm5 mulsd xmm0, xmm7 addsd xmm2, xmm0 movapd xmm1, xmm4 mulsd xmm1, xmm8 addsd xmm2, xmm1 movsdx QWORD PTR r$109492[rsp], xmm2 mulsd xmm5, xmm9 mulsd xmm3, xmm10 addsd xmm5, xmm3 mulsd xmm4, xmm11 addsd xmm5, xmm4 movsdx QWORD PTR r$109492[rsp+8], xmm5 mov rcx, QWORD PTR r$109492[rsp] mov QWORD PTR [rax], rcx mov rcx, QWORD PTR r$109492[rsp+8] mov QWORD PTR [rax+8], rcx add rax, 16 add rdx, 24 lea rcx, QWORD PTR [rdx-16] cmp rcx, rbx jne SHORT $LL175@main </code></pre> <p>The x64 version has a lot more (unexplained) moves at the end of the loop. It looks like some sort of memory-to-memory data-copy.</p> <h1>EDIT:</h1> <p>It turns out that the x64 optimizer isn't able to optimize out the following copy:</p> <pre><code>(*i2) = r; </code></pre> <p>This is why the inner loop has two extra memory copies. If you change the loop to this:</p> <pre><code>std::for_each(m.begin(), m.end(), [&amp;](const Vector&amp; v) { i2-&gt;x = Dot(axisX, v); i2-&gt;y = Dot(axisY, v); ++i2; }); </code></pre> <p>This eliminates the copies. Now the x64 version is just as fast as the x86 version:</p> <pre><code>x86: 0.0249423 x64: 0.0249348 </code></pre> <p><strong>Lesson Learned:</strong> Compilers aren't perfect.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhy c++ program compiled for x64 platform is slower than compiled for x86?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMysticial
    1. USMysticial
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy c++ program compiled for x64 platform is slower than compiled for x86?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI don't think it does... but is 'double' 64-bit if compiled for 64-bit versus 32-bit if compiled for 32-bit arch. I believe long changes size, but not sure if double does. I would check it, but visual studio is only letting me compile 32-bit today. double should be 64-bits on both (8 bytes).
      singulars
      1. PO
      1. USDavid
    2. CONah, `double` is standard IEEE double-precision on x86. The assembly here is pretty clear, it's all scalar double-precision SSE.
      singulars
      1. PO
      1. USMysticial
    3. COThis looks like the same issue: http://www.dreamincode.net/forums/topic/127989-compiler-made-optimizations/ To fix it they used the /O2 compiler optimization which resulted in the 64-bit version being faster than the 32-bit version. Can you try that and see if it helps?
      singulars
      1. PO
      1. USDavid
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload