Hi all, So, I played around a bit to get OpenMP and GCD into something like a “parallel_for” wrapper which either uses OpenMP or GCD. Unfortunately, OpenMP seems to require that the “for” statement directly follows the “#pragma omg for …”. That currently killed all my attempts to define such a “parallel_for” (as function, #define, ?) so that the code will stay the same for both. One option would be to pull the “#pragma omp for …” into the wrapper, but I guess this is not really acceptable (since you can’t specify any specific schedule parameters any longer).
I will think about it some more just because of the challenge… but I am not very optimistic at the moment to get something nice. If anyone else has a nice idea, I’d be very interested to learn freaky new stuff… :) On the other side, I looked at using a non-Xcode OpenMP capable clang. The only caveat seems to be not to mix standard C++ libraries (in the past libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find out if that is resolved). Default on macOS now is libc++, but it seems that at least MacPorts builds clang with libstdc++ per default (no idea why). The MacPorts build can easily be switched to libc++. That clang-mp builds KiCad without problems even if dependencies have been built with Xcode clang. Everything seems to work as expected, multithreading is there where it should be. So, for now it seems to be the most easy solution to switch to a suitable non-Xcode clang for building packages - if we want to have OpenMP for macOS. AFAIK our build machines use Homebrew. Seems as if Homebrew decides which standard library to use depending on macOS version (https://docs.brew.sh/C++-Standard-Libraries <https://docs.brew.sh/C++-Standard-Libraries>). So, if everything is recent enough it might not be a problem at all… like it obviously also has been for Seth below. Regards, Bernhard > On 1. Mar 2018, at 17:47, Seth Hillbrand <seth.hillbr...@gmail.com> wrote: > > Hi All- > > I was playing with this last night (don't normally compile on the mac) and > found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp. > Running some OMP test code from > https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 > <https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5> > shows expected result of 4 threads. I didn't get OpenMP errors when > compiling KiCad although I didn't really notice a substantial difference in > speed for the quick tests I was running. Maybe with more involved operations. > > I'm not sure if this will require us to distribute a different libstdc++ with > KiCad. Probably. Does that seem feasible to the packing team? > > -S > > 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier <stegma...@sw-systems.de > <mailto:stegma...@sw-systems.de>>: > Hmm? > You keep everything as is (especially creating threads), but just put the > “#pragma …” before the for-loop. > So, there is one thread for the progress and one for the workers. > In the workers thread OpenMP (if there) takes care of adding additional > threads for parallelising the loop? > > Or, am I wrong with that? > > > On 1. Mar 2018, at 16:11, Jeff Young <j...@rokeby.ie > > <mailto:j...@rokeby.ie>> wrote: > > > > But then the progress reporter won’t work (and you’ve got no way to cancel). > > > > Non-pooling parallel threads are sufficient for zone filling, aren’t they? > > > > > >> On 1 Mar 2018, at 15:00, Bernhard Stegmaier <stegma...@sw-systems.de > >> <mailto:stegma...@sw-systems.de>> wrote: > >> > >> For now it would probably be fine to just restore the pragma for the for > >> loop optimisation. > >> Mac users are used to work single-threaded, all others would get back > >> multithreading here. > >> > >>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski <tomasz.wlostow...@cern.ch > >>> <mailto:tomasz.wlostow...@cern.ch>> wrote: > >>> > >>> On 01/03/18 15:43, Jeff Young wrote: > >>>> The purpose is it works on Mac. > >>>> > >>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part. > >>>> > >>> > >>> Thanks Jeff! > >>> > >>> Be aware that neither std::thread nor std::async have any concept of > >>> thread pooling - we need to look for a suitable library or write or own. > >>> > >>> Cheers, > >>> Tom > >>> > >>> _______________________________________________ > >>> Mailing list: https://launchpad.net/~kicad-developers > >>> <https://launchpad.net/~kicad-developers> > >>> Post to : kicad-developers@lists.launchpad.net > >>> <mailto:kicad-developers@lists.launchpad.net> > >>> Unsubscribe : https://launchpad.net/~kicad-developers > >>> <https://launchpad.net/~kicad-developers> > >>> More help : https://help.launchpad.net/ListHelp > >>> <https://help.launchpad.net/ListHelp> > >> > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
