[Bf-committers] OpenMP issues with msvc2013 builds

[Bastien Montagne]

We could also choose to drop OMP in our code (not all at once, but 
gradually replacing it with real threading), since it’s also a pile of 
crap on OSX currently afaik?

Assuming our BLI_task 'lib' is ready for massive use (iirc Martijn 
already had that in mind)…

Or is there some serious issues with this approach (aside the slightly 
more verbose [complicated?] code)?

Le 06/08/2014 13:26, Sergey Sharybin a écrit :
> Switching to icc wouldn't happen any time soon anyway, so afraid we'll need
> to have some shorter-term solution anyway... The question only is what
> exactly we'll choose.
>
> P.S. And yeah, there's nothing more permanent as a temporary solution..
>
>
> On Wed, Aug 6, 2014 at 4:48 PM, Martijn Berger <martijn.berger at gmail.com>
> wrote:
>
>> Hi Campbell,
>>
>> I last compiled with intel c++ a few month's ago and without OSL / Collada.
>> In general it works but as with any change it will again probably expose
>> lots of little issues once people actually use builds intensively.
>>
>> Main issue is the compiler is not free to use for windows not even for open
>> source projects. ( the linux toolchain is free for open source ).
>>
>>
>>
>> On Wed, Aug 6, 2014 at 12:43 PM, Campbell Barton <ideasman42 at gmail.com>
>> wrote:
>>
>>> On Wed, Aug 6, 2014 at 6:23 PM, Sergey Sharybin <sergey.vfx at gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> We've spent quite a while trying to solve the upcoming stream of
>> reports
>>>> about high CPU usage with builds made with msvs2013 in certain
>>> situations.
>>>> Root of the issue goes to the change made to OMP inplementation back to
>>>> msvc2010 days -- they've forced threads to spin for a while after they
>>> did
>>>> a work. This is a know issue in the library and nobody actually gonna
>> to
>>>> fix it [1].
>>>>
>>>> There's one woekaround to solve the issue which is to set
>> OMP_WAIT_POLICY
>>>> environment variable to PASSIVE. Unfortunately, since openmp is a
>> dynamic
>>>> library and can't be linked statically at all we can't modify
>> environment
>>>> variables from within blender using putenv(), this is to be done
>>>> externally, before blender.exe starts.
>>>>
>>>> Here's the list of possible solutions:
>>>>
>>>> - Declare msvc full of crap, switch to intel compilers
>>> Did anyone try Intel-c/c++ on Windows?
>>>
>>> A while back I got Blender building on Linux with Intel's compiler, it
>>> needed a few tweaks in CMake but wasn't really a big deal to get
>>> running.
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>