Theres been some issues with OpenMP, but am wary of kicking out entire technology just because we can't set an environment variable? (ok, of course theres more to it - but seems a weak reasoning still).
Regarding OSX - Clang is preparing to use OpenMP from Intel, so situation on OSX likely improves soon: http://clang-omp.github.io clang's development moves at quite good pace so think its reasonable to expect this is usable soon. We had problems with Windows & setting env vars before, where we weren't able to set CPython's stdout encoding. https://developer.blender.org/T31555 It may be good to use some stub (BAT/COM/EXE) to launch blender on Windows, then we don't run into a wall whenever some library needs an env var set. On Wed, Aug 6, 2014 at 10:32 PM, Martijn Berger <martijn.ber...@gmail.com> wrote: > Excellent plan Bastien. > From a semantic standpoint combining different threading strategies and or > support libraries within one project is really far from ideal. > For this to work we would need to write some kind of document or declare > some already implemented part of code "the official way" to do this. > > Yes the code would be more verbose compared to openmp but also more > explicit and likely better to control versus the current zoo of tricks in > order to exploit parallelism. > > > > > On Wed, Aug 6, 2014 at 2:15 PM, Bastien Montagne <montagn...@wanadoo.fr> > wrote: > >> 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.ber...@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 <ideasma...@gmail.com> >> >> wrote: >> >> >> >>> On Wed, Aug 6, 2014 at 6:23 PM, Sergey Sharybin <sergey....@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@blender.org >> >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>> >> >> _______________________________________________ >> >> Bf-committers mailing list >> >> Bf-committers@blender.org >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > >> > >> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
