Debian testing package reports libgomp1 version 8-20180218-1 and CMake finds it as version 4.5. I'm not sure why the disconnect. I'm using gcc 7.3.0. I'll check windows when I get a chance.
On 03/04/2018 01:36 PM, Bernhard Stegmaier wrote: > Hi all, > > could please anybody test the following on a Windows/Linux OpenMP version? > > I have a PCB with only components placed (via “Update from Schematic”), > no routing done yet. > Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer. > Now, edit a footprint (“e”) and do a “Update Footprint from Library” for > only this footprint (no changes in footprint needed). > Open 3d-viewer again. > > Or: > Open PCB as above with only components and no routing yet. > Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer. > Delete some of the components and reimport them vie “Update PCB from > Schematic”. > Open 3d-viewer again. > > In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or > hang (all cores at 100%, grey window, nothing happens) 3d-viewer . > It doesn’t hang/crash in my non-OpenMP builds. > > If I save the PCB after the changes, close and reopen KiCad, then > 3d-viewer of OpenMP build is also fine again. > > > Regards, > Bernhard > >> On 3. Mar 2018, at 20:33, Bernhard Stegmaier <stegma...@sw-systems.de >> <mailto:stegma...@sw-systems.de>> wrote: >> >> 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). >> 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 >>> <mailto: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 >>> 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 >>> <mailto: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 >> <mailto: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 > _______________________________________________ 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
