kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <stegmaier@xxxxxxxxxxxxx
>> <mailto:stegmaier@xxxxxxxxxxxxx>> 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.hillbrand@xxxxxxxxx
>>> <mailto:seth.hillbrand@xxxxxxxxx>> 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 <stegmaier@xxxxxxxxxxxxx
>>> <mailto:stegmaier@xxxxxxxxxxxxx>>:
>>>
>>>     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 <jeff@xxxxxxxxx
>>>     <mailto:jeff@xxxxxxxxx>> 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
>>>     <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>> 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.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>     >>> 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@xxxxxxxxxxxxxxxxxxx
>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>     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@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>