Boost C++ Libraries: Ticket #8509: SSE/AVX optimization and C++11 support

attachment set

Andrey Semashev — Sun, 28 Apr 2013 00:33:04 GMT

attachment → uuid_operators.cpp

Benchmarking code

attachment set

Andrey Semashev — Sun, 28 Apr 2013 00:33:26 GMT

attachment → uuid_operators.txt

Benchmarking results

attachment set

Andrey Semashev — Wed, 16 Oct 2013 14:30:00 GMT

attachment → uuid_simd.patch

Updated patch that adds optimizations for SSE and C++11 to boost::uuid.

Andrey Semashev — Mon, 21 Oct 2013 23:01:26 GMT

(In [86385]) Added optimizations for C++11 and SSE. Refs #8509.

status changed; resolution set

Andrey Semashev — Tue, 12 Nov 2013 20:19:08 GMT

status new → closed
resolution → fixed

(In [86660]) Merged changes from trunk: warning silencing and support for SSE and C++11. Fixes #8495, #8697, #8509.

Thu, 25 Sep 2014 17:26:38 GMT

There seems to be a bug in the Visual Studio 2013 optimizer, which causes the != operator to crash. Please have a look at https://connect.microsoft.com/VisualStudio/feedbackdetail/view/981648#tabs. Putting a #pragma optimize("", off/on) around the operators works around this bug. I'll follow up with more details.

Andrey Semashev — Thu, 25 Sep 2014 18:25:58 GMT

Could you provide a small code snippet so I can reproduce the problem? I'll need it to implement a test.

Also, what compiler switches do you use when you have the problem?

Fri, 26 Sep 2014 07:12:35 GMT

I'll try to reproduce it. I am using /O2 and "no whole program optimization". The problem is that the optimizer will usually produce code like this:

000000013F2110DA  movdqu      xmm0,xmmword ptr [rsp+48h]
000000013F2110E0  movdqu      xmm1,xmmword ptr [rax+10h]
000000013F2110E5  pcmpeqd     xmm1,xmm0
000000013F2110E9  pmovmskb    eax,xmm1
000000013F2110ED  cmp         eax,0FFFFh

It's only when the register xmm0 is already assigned a different variable that the optimizer will then produce the problematic opcode. I need to find a way to reproduce that specific scenario. The bug manifests itself in a 29MB binary of an application I am currently porting from VS2008 to VS2013 (and boost 1.55 to boost 1.56).

Fri, 26 Sep 2014 07:27:20 GMT

My guess is that is further complicated by the fact that boost/uuid/detail/config.hpp defined BOOST_UUID_USE_SSE2 for Visual Studio and emits SSE2 opcodes which the compiler then optimizes. At least if I compile the debug version I see an entirely different output for _mm_loadu_si128 than with release.

Andrey Semashev — Fri, 26 Sep 2014 07:48:56 GMT

So this is case specific, I guess. I'm not sure it's a good idea to disable optimization for everyone. Does it happen with other operators or functions?

If patching Boost is difficult for you you can define BOOST_UUID_NO_SIMD to disable the optimized routines.

attachment set

Fri, 26 Sep 2014 08:02:30 GMT

attachment → testcase-1-981648-vsoptimizer-bug.cpp

testcase 1 showing part of the VS2013 optimizer problem

Fri, 26 Sep 2014 08:05:48 GMT

Yes, it's very specific. At least the other problem (movdqu) you mentioned over at connect.microsoft seems more common. I uploaded a testcase for you just now.

Since the problematic functions are inline I'll try to disable optimization in my calling functions. That should leave optimization for all other instances intact. BTW, I noticed that config.hpp does not define SSE41, even though that is available for VS2013. I'll try to enable that. Could be that my problem then disappears (for now).

Fri, 26 Sep 2014 08:22:33 GMT

Finally! Please see attached testcase that shows both problems. The problem is not that specific. I imagine it might affect others as well. All I had to do was move the function with the != operator to a different .cpp file than the calling function. Then I was able to reproduce the crash.

Note that this is Visual Studio 2013 Professional Update 3, Version 12.0.30723.0

attachment set

Fri, 26 Sep 2014 08:23:12 GMT

attachment → testcase-981648-vsoptimizer-bug.zip

Testcase showing all optimizer problems including the access violation

Fri, 26 Sep 2014 15:26:01 GMT

The good news is that code generated with #define BOOST_UUID_USE_SSE3 seems to be working okay. So the easiest fix for this problem would be to add

#if _MSC_VER>=1800 && defined(_M_X64)
#define BOOST_UUID_USE_SSE3
#endif

to boost/uuid/detail/config.hpp, line 44. BOOST_UUID_USE_SSE41 would also work, but the code for the operator== gets bigger. There is an added comparision which looks weird to me.

After that I don't have any more problems (yet).

Andrey Semashev — Fri, 26 Sep 2014 15:35:25 GMT

Defining these macros makes the resulting binaries only runnable on CPUs with the respective instructions supported. This is ok if you target your application to these more recent CPUs, but in general SSE3 and later are not required to be present in Intel64/AMD64 CPUs.

Fri, 26 Sep 2014 15:38:44 GMT

Yes, of course. Then the only solution I see is disabling the uuid_x86 for VS2013 for the present. I am curious what you can find out about the problem.

Andrey Semashev — Sat, 27 Sep 2014 19:09:30 GMT

Please, have a look at this pull request:

https://github.com/boostorg/uuid/pull/4

It works around the optimizer bug for me.

mailinglists@… — Tue, 30 Sep 2014 06:20:31 GMT

Thanks, this seems to work. It still generates a movups though, but it does not crash anymore.

BTW, perhaps you could click on "Users can reproduce this bug" over at connect.microsoft, so we can get their attention and possibly get this fixed (see connect.microsoft link above).

Wed, 01 Oct 2014 14:46:14 GMT

This bug seems to affect Visual Studio 2008 as well. When was this patch released? I just ported from boost 1.55 to 1.56 and never saw this problem before, but now I have the same problem with the pcmpeqd opcode in the VS 2008 compiled object files. OTOH it could be that our class layout changed and the UUIDs were 16-byte aligned until now.

Anyway, I see this crash with Visual Studio 2008 as well, so your fix should probably be enabled for _MSC_VER VS2008 also.

Andrey Semashev — Wed, 01 Oct 2014 18:03:36 GMT

The optimized routines were first released in 1.56.

Did you test the change in the pull request (modifying it to also apply to VS2008), does it fix the problem for you?

Andrey Semashev — Wed, 01 Oct 2014 20:24:24 GMT

BTW, the test case doesn't reproduce the crash with VS2008 SP1. Can you provide a test that breaks with that compiler?

Thu, 02 Oct 2014 07:46:37 GMT

The pull request works for both, VS2013 and VS2008. I just verified again that VS2008 indeed has a similar problem, although the circumstances when this bug manifests itself are different. I'll try to come up with another test project for VS2008.

Thu, 02 Oct 2014 15:05:11 GMT

I correct myself: The pull request works for VS2013 but not for VS2008. The testcase project crashes with 2008 as well, could you please try it again? Perhaps you forgot to switch to the x64 configuration? I'll upload another testcase with a VS2008 solution in a short while.

Thu, 02 Oct 2014 15:13:45 GMT

I've added a new testcase for VS2008. _ReadWriteBarrier() does not help with Visual Studio 2008. It still crashes.

attachment set

Thu, 02 Oct 2014 15:14:11 GMT

attachment → testcase-981648-vs2008-bug.zip

Testcase for VS2008

Andrey Semashev — Sat, 04 Oct 2014 13:02:32 GMT

Thanks for the test case. It crashes in a different place, that's why I didn't see the crash in my test.

I've updated the pull request with a new fix for VS2008.

Mon, 06 Oct 2014 14:49:45 GMT

The new fix doesn't work. Our application does not crash at the operator== location anymore, but it doesn't work either. Instead it crashes in entirely different places and/or behaves strangely. My guess is that some of the other operators no longer work correctly with the optimizations and VS2008. Unfortunately I don't have any more time to investigate this problem. I've deactivated all optimizations in detail/uuid_config.hpp for VS2008 and our application is working again as it should. Since VS 2008 is already 6 years old I'd probably just disable the optimizations in the official boost lib as well and move on.

Andrey Semashev — Sun, 12 Oct 2014 10:30:31 GMT

Sorry, there was a bug in the workaround. Fixed now.