Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Hi again,

just wanted to share some of my OpenMP on macOS experience, FWIW:

I used both clang-5.0.1 and clang-6.0 from MacPorts.
KiCad builds fine with it.

It works fine on my build machine (b).
On my MacBook (a) such a build always crashes when ratsnest changes after I 
opened the PCB (e.g. move/update a footprint).
Initial ratsnest on opening the PCB is for whatever reason OK.
On a third machine (c) it crashes just like on (a).

There is some OpenMP stuff in the ratsnest code.
On my build machine I can stress the ratsnest code by moving a component around.
It is really using multiple threads according to CPU load.

That’s with clang-6.0.

A previous build with clang-5.0 doesn’t show this crash with ratsnest, but the 
3d-viewer hang/crash problems I asked about in the other mail.
Again, 3d-viewer in OpenGL mode doesn’t work on my MacBook, but perfectly works 
on my build machine (same PCB, of course).

In backtraces of crashes always libomp task stuff is involved.

(b) and (c) are still on macOS 10.12, (a) is on 10.13.
It doesn’t seem to be about macOS version, because on one 10.12 machine the 
build is working, on the other not.

Of course, all machines are different HW. 
(b) is a 2012 i7. The other machines are a 2012 i5 and i3.
I even did a local build of libomp on my MacBook to rule out that it might use 
some i7 specific stuff that doesn’t run on i5/i3.
Didn’t help, I get the same crashes.

At the moment, I don’t really know what’s going on.
I looked at the code both for the 3d-viewer problem and the ratsnest stuff, but 
I don’t see anything being obviously wrong.
Of course, I don’t claim that I have understood every detail of it and I am no 
OpenMP expert.
It obviously works on a lot of linux boxes, so I guess it can’t be that wrong.

If someone wants to try the build:
  https://drive.google.com/open?id=1rpuKYxpHZTk5YiWe8s3LhIssHxJ9Y1oh 

I’d be happy to hear if it works or not, especially with OpenGL 3d-viewer 
and/or the rats nest use-case.


Regards,
Bernhard

> On 3. Mar 2018, at 20:33, Bernhard Stegmaier  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 > > 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 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

On windows builds using msys, openmp 4.5, gcc 7.3.0

On 3/4/2018 1: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 > > 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 >> > 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 >> >:
>>>
>>> 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 >> > 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
>>> > wrote:
>>> >>
>>> >> For now it 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Bernhard,

On 03/04/2018 02:32 PM, Bernhard Stegmaier wrote:
> Wayne, I am seeing the same funny stuff on my old Debian box.
> I didn’t follow up, because I thought it might have to do something with my 
> OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not 
> that good maintained.

My system is a core i7 with an nvidia graphics card using the
proprietary nvidia drivers.  I rarely have any rendering issue with the
nvidia drivers.  I have far less luck with the open source nvidia drivers.

> 
> But, the first picture is the OpenGL renderer, so this one is OK?

Yes, the OpenGL rendering is fine.

> 
> 
> Bernhard
> 
>> On 4. Mar 2018, at 20:20, Wayne Stambaugh  wrote:
>>
>> I'm not seeing any crash on Debian testing but there is some rather
>> amusing artifacts on the rendering.  It looks like all of my 3D models
>> have been deconstructed to tiny bits all over the model space.  Last
>> time I checked it was fine on windows.
>>
>> On 03/04/2018 02:06 PM, Maciej Suminski wrote:
>>> Bernhard,
>>>
>>> I suppose this is about raytrace rendering? Anyway, I see it crashing
>>> even without any design loaded. 3D viewer passes the first phase so I
>>> see the design rendered, but during 'Post processing shader' stage it
>>> crashes.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 03/04/2018 07: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  
> 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 > > wrote:
>>
>> Hi All-
>>
>> I was playing with this last night (don't normally compile on the mac) 
>> and found that using homebrew's llvm 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Wayne, I am seeing the same funny stuff on my old Debian box.
I didn’t follow up, because I thought it might have to do something with my 
OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not that 
good maintained.

But, the first picture is the OpenGL renderer, so this one is OK?


Bernhard

> On 4. Mar 2018, at 20:20, Wayne Stambaugh  wrote:
> 
> I'm not seeing any crash on Debian testing but there is some rather
> amusing artifacts on the rendering.  It looks like all of my 3D models
> have been deconstructed to tiny bits all over the model space.  Last
> time I checked it was fine on windows.
> 
> On 03/04/2018 02:06 PM, Maciej Suminski wrote:
>> Bernhard,
>> 
>> I suppose this is about raytrace rendering? Anyway, I see it crashing
>> even without any design loaded. 3D viewer passes the first phase so I
>> see the design rendered, but during 'Post processing shader' stage it
>> crashes.
>> 
>> Cheers,
>> Orson
>> 
>> On 03/04/2018 07: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  
 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  > 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 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Orson,

no, the raytracing renderer is completely fine in that use-cases.

It is only the OpenGL renderer.
I first noticed the hang when I switched back from Raytracing to OpenGL 
(obviously after I did one of the 2 use-cases).

If it crashes, I get a backtrace of the crashing thread as follows
<<<
Thread 3 Crashed:
0   libomp.dylib0x000109c728e2 
__kmp_release_queuing_lock + 165
1   _pcbnew.kiface  0x000111a1aaa3 
CLAYER_TRIANGLES::AddToMiddleContourns(std::__1::vector, std::__1::allocator > 
> const&, float, float, bool) + 1011
2   _pcbnew.kiface  0x000111a1ad52 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_LINE_CHAIN const&, float, float, 
double, bool) + 546
3   _pcbnew.kiface  0x000111a1b228 .omp_outlined. + 248
4   libomp.dylib0x000109c81b93 
__kmp_invoke_microtask + 147
5   libomp.dylib0x000109c587b7 
__kmp_invoke_task_func + 156
6   libomp.dylib0x000109c57e88 __kmp_launch_thread 
+ 267
7   libomp.dylib0x000109c79e6f 
__kmp_launch_worker(void*) + 588
8   libsystem_pthread.dylib 0x7fff6735b6c1 _pthread_body + 340
9   libsystem_pthread.dylib 0x7fff6735b56d _pthread_start + 377
10  libsystem_pthread.dylib 0x7fff6735ac5d thread_start + 13
>>>

The main thread looks similar.
<<<
Thread 0:: Dispatch queue: com.apple.main-thread
0   libomp.dylib0x000109c728e2 
__kmp_release_queuing_lock + 165
1   _pcbnew.kiface  0x000111a1aaa3 
CLAYER_TRIANGLES::AddToMiddleContourns(std::__1::vector, std::__1::allocator > 
> const&, float, float, bool) + 1011
2   _pcbnew.kiface  0x000111a1ad52 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_LINE_CHAIN const&, float, float, 
double, bool) + 546
3   _pcbnew.kiface  0x000111a1b228 .omp_outlined. + 248
4   libomp.dylib0x000109c81b93 
__kmp_invoke_microtask + 147
5   libomp.dylib0x000109c587b7 
__kmp_invoke_task_func + 156
6   libomp.dylib0x000109c557dc __kmp_fork_call + 
4682
7   libomp.dylib0x000109c4d1fb __kmpc_fork_call + 
183
8   _pcbnew.kiface  0x000111a1b114 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_POLY_SET const&, float, float, 
double, bool) + 628
9   _pcbnew.kiface  0x000111a126ae 
C3D_RENDER_OGL_LEGACY::generate_holes_display_list(std::__1::list > const&, SHAPE_POLY_SET const&, float, float, 
bool) + 462
10  _pcbnew.kiface  0x000111a12d39 
C3D_RENDER_OGL_LEGACY::reload(REPORTER*) + 1545
11  _pcbnew.kiface  0x000111a16e02 
C3D_RENDER_OGL_LEGACY::Redraw(bool, REPORTER*) + 306
12  _pcbnew.kiface  0x000111a09124 
EDA_3D_CANVAS::OnPaint(wxPaintEvent&) + 628
>>>

I am not really familiar with OpenMP, but the AddToMiddleContourns methods look 
good in terms of synchronization (well, at first glance).


Regards,
Bernhard

> On 4. Mar 2018, at 20:06, Maciej Suminski  wrote:
> 
> Bernhard,
> 
> I suppose this is about raytrace rendering? Anyway, I see it crashing
> even without any design loaded. 3D viewer passes the first phase so I
> see the design rendered, but during 'Post processing shader' stage it
> crashes.
> 
> Cheers,
> Orson
> 
> On 03/04/2018 07: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  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> So, I played around a bit to get OpenMP and GCD into something 

Re: [Kicad-developers] MacOS + OpenMP

[Maciej Suminski]

Bernhard,

I suppose this is about raytrace rendering? Anyway, I see it crashing
even without any design loaded. 3D viewer passes the first phase so I
see the design rendered, but during 'Post processing shader' stage it
crashes.

Cheers,
Orson

On 03/04/2018 07: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  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 >> > 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 >> >:
>>> 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 > wrote:

 But then the progress reporter won’t work (and you’ve got no way to 
 cancel).

 Non-pooling 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

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 > > 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 >> > 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 >> >:
>>>
>>> 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 >> > 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 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

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  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 > > 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 > >:
>> 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 > > > 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 > >> > 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.
>> >>

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

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  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  >:
> 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  > > 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  >> > 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  >>> > 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 
> >>> 
> >>> 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 : 

Re: [Kicad-developers] MacOS + OpenMP

[Andrey Kuznetsov]

Hi,

So for now I've had a chance to test the motherboard project on my Retina
macbook display.
eeschema: horrible zoom, feels like elastic band zoom and I have all scroll
wheel accelerations and similar disabled, zoom response is super laggy,
cannot work like this, will need to make schematics on windows.
pcbnew by order of slowness:
legacy - pretty slow, zoom lag is major, boo boo
modern (fallback) - decent, but the lag can be felt, zoom lag is minor
modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
responsiveness

I'll report tomorrow on 5K LG display.

On Thu, Mar 1, 2018 at 9:06 AM, Bernhard Stegmaier 
wrote:

> When I started with KiCad I had massive problems mixing gcc and clang
> depending on what dependency was built with which compiler (different
> libstdc, ABI, etc.) - even if everything should have been compatible in
> theory.
> So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t
> target that for v5.
>
> For my taste, I would rather stick to a toolchain being as stock as
> possible.
>
> > On 1. Mar 2018, at 18:00, Adam Wolf 
> wrote:
> >
> > I do not think it is feasible to distribute a different libstdc++ with
> > V5 stable for macOS unless there's someone who wants to take that on.
> >
> > Adam
> >
> > On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh 
> wrote:
> >> Just for clarification I think Tom was commenting that the changes hurt
> >> the zone filling speed.  @Tom, is that what your were commenting on
> earlier?
> >>
> >> On 3/1/2018 10:11 AM, Jeff Young 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 
> 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> 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
> > 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
> >>>
> >>
> >> ___
> >> 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
>
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

When I started with KiCad I had massive problems mixing gcc and clang depending 
on what dependency was built with which compiler (different libstdc, ABI, etc.) 
- even if everything should have been compatible in theory.
So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t 
target that for v5.

For my taste, I would rather stick to a toolchain being as stock as possible.

> On 1. Mar 2018, at 18:00, Adam Wolf  wrote:
> 
> I do not think it is feasible to distribute a different libstdc++ with
> V5 stable for macOS unless there's someone who wants to take that on.
> 
> Adam
> 
> On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh  wrote:
>> Just for clarification I think Tom was commenting that the changes hurt
>> the zone filling speed.  @Tom, is that what your were commenting on earlier?
>> 
>> On 3/1/2018 10:11 AM, Jeff Young 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  
 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  
> 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
> 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
>>> 
>> 
>> ___
>> 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


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Seth Hillbrand]

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 :

> 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  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 
> 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 
> 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
> >>> 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
>
___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

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  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  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  
>>> 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
>>> 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

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

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  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  
>> 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
>> 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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

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  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
> 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

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

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
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

The purpose is it works on Mac.

But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.

Patch coming.

Cheers,
Jeff.


> On 1 Mar 2018, at 14:09, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 15:01, Jon Evans wrote:
>> I missed that change to STL, oops!
>> In that case we should standardize on STL for all new code in the future
>> so that it will work on Mac.
> 
> Me too.
> 
> I don't understand the purpose of it - now all zone calculation (except
> for insulated copper island removal) works in a *single* worker thread
> (the main thread is just refreshing the progress dialog).
> 
> It means ~3.5x slower zone refilling on a 4-core CPU.
> 
> Can anybody comment on that?
> 
> Tom
> 
> 
>> There are already many edge cases I have found (or users have reported)
>> where KiCad is extremely slow, and we need to have a good story for
>> multiprocessing so that we can take advantage of it where it makes sense
>> to increase performance and/or responsiveness.
>> 
>> -Jon
>> 
>> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young > > wrote:
>> 
>>There’s performance and there’s responsiveness.
>> 
>>The footprint loading and zone filling were moved to STL so that
>>progress reporting would work on Mac.
>> 
>>As long as we don’t introduce more OpenMP into core stuff, I’m not
>>that fixated on what we use for raytracing.
>> 
>>Cheers,
>>Jeff.
>> 
>> 
>>>On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>>>> wrote:
>>> 
>>>On 01/03/18 14:29, Jon Evans wrote:
It is also used for zone filling and in my new eeschema connectivity
code that I'm hoping to get merged soon after V5 release.
 
I'm happy to help with research / testing of alternatives if we can't
use OpenMP on Mac. 
 
>>>I'd like to hear from a *single* Apple user who designs boards of
>>>sufficient complexity for the multithreading to really have an
>>>impact on
>>>performance. What's next, rewriting Kicad in Objective-C?
>>> 
>>>- my 5 cents
>>> 
>>>Tom
>>> 
>>> 
Jon
 
On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh 
> wrote:
 
   Ughh!  Thank you Apple.  I'm not opposed to this idea if
OpenMP isn't a
   viable option on macos.  I would like to see our macos port be
on par
   with linux and windows ports.
 
   Wayne
 
   On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>I did look around a bit.
>Looks like OpenMP isn’t a friend of Xcode clang, because Apple
>has its
>own Grand Central Dispatch (libdispatch) implementation/library
>doing
>similar things (at first glance, didn’t look into details).
>So, I guess OpenMP maybe won’t happen soon with stock toolchain
>or we
>would have to use non-stock toolchain (probably with all
>problems that
>come with that - I have seen bad things mixing compilers, etc.).
> 
>Seems to be quite easy to convert OpenMP for loop parallelisation
   to GCD:
><<<
>//#pragma omp parallel for
>//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>dispatch_queue_t queue =
>dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>{
>...
>}
>);
 
> 
>I just naively replaced all of the OpenMP for loops like above
>and now
>3d-Viewer uses all cores.
>On my i7-3770T rendering time decreased from about 100s to 30s.
> 
>I also did it for the ratsnest loop but didn’t notice any difference
>(maybe my test PCB was just to small).
> 
>I could play around a bit to put that stuff into some nice syntax
   maybe
>similar to what Microsoft has with concurrency::parallel_for_each
>  https://msdn.microsoft.com/en-us/library/dd492857.aspx
>
>So, at least ugly #ifdef around each parallel for loop could be
   hidden.
> 
>Don’t get me wrong, I don’t want to add just another parallelisation
>library/mechanism.
>And… I guess it won’t be possible to transparently cover all the
   OpenMP
>pragma stuff maybe needed inside for loop body or maybe other stuff
>needed for GCD (e.g. when writing to variables outside for body).
> 
>Thoughts? Would this be an option?
> 
>Oh, yes:
>I did look into using STL std::async.
>Doesn’t seem to be a good idea, because it usually doesn’t seem
>to use
>anything like thread pools, etc. on 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I didn’t follow in detail, but from what I saw I guess the bad thing about it 
was to use OpenMP for
(1) parallelising for loop
  and
(2) creating individual threads for progress reporter and workers.

As soon as you don’t have OpenMP it didn’t work anymore… so maybe using OpenMP 
for (1) and usual STL threading stuff for (2) would be a compromise (even) if 
maybe clumsy.
At least, it would work also with non-OpenMP systems.


Regards,
Bernhard

> On 1. Mar 2018, at 15:09, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 15:01, Jon Evans wrote:
>> I missed that change to STL, oops!
>> In that case we should standardize on STL for all new code in the future
>> so that it will work on Mac.
> 
> Me too.
> 
> I don't understand the purpose of it - now all zone calculation (except
> for insulated copper island removal) works in a *single* worker thread
> (the main thread is just refreshing the progress dialog).
> 
> It means ~3.5x slower zone refilling on a 4-core CPU.
> 
> Can anybody comment on that?
> 
> Tom
> 
> 
>> There are already many edge cases I have found (or users have reported)
>> where KiCad is extremely slow, and we need to have a good story for
>> multiprocessing so that we can take advantage of it where it makes sense
>> to increase performance and/or responsiveness.
>> 
>> -Jon
>> 
>> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young > > wrote:
>> 
>>There’s performance and there’s responsiveness.
>> 
>>The footprint loading and zone filling were moved to STL so that
>>progress reporting would work on Mac.
>> 
>>As long as we don’t introduce more OpenMP into core stuff, I’m not
>>that fixated on what we use for raytracing.
>> 
>>Cheers,
>>Jeff.
>> 
>> 
>>>On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>>>> wrote:
>>> 
>>>On 01/03/18 14:29, Jon Evans wrote:
It is also used for zone filling and in my new eeschema connectivity
code that I'm hoping to get merged soon after V5 release.
 
I'm happy to help with research / testing of alternatives if we can't
use OpenMP on Mac. 
 
>>>I'd like to hear from a *single* Apple user who designs boards of
>>>sufficient complexity for the multithreading to really have an
>>>impact on
>>>performance. What's next, rewriting Kicad in Objective-C?
>>> 
>>>- my 5 cents
>>> 
>>>Tom
>>> 
>>> 
Jon
 
On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh 
> wrote:
 
   Ughh!  Thank you Apple.  I'm not opposed to this idea if
OpenMP isn't a
   viable option on macos.  I would like to see our macos port be
on par
   with linux and windows ports.
 
   Wayne
 
   On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>I did look around a bit.
>Looks like OpenMP isn’t a friend of Xcode clang, because Apple
>has its
>own Grand Central Dispatch (libdispatch) implementation/library
>doing
>similar things (at first glance, didn’t look into details).
>So, I guess OpenMP maybe won’t happen soon with stock toolchain
>or we
>would have to use non-stock toolchain (probably with all
>problems that
>come with that - I have seen bad things mixing compilers, etc.).
> 
>Seems to be quite easy to convert OpenMP for loop parallelisation
   to GCD:
><<<
>//#pragma omp parallel for
>//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>dispatch_queue_t queue =
>dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>{
>...
>}
>);
 
> 
>I just naively replaced all of the OpenMP for loops like above
>and now
>3d-Viewer uses all cores.
>On my i7-3770T rendering time decreased from about 100s to 30s.
> 
>I also did it for the ratsnest loop but didn’t notice any difference
>(maybe my test PCB was just to small).
> 
>I could play around a bit to put that stuff into some nice syntax
   maybe
>similar to what Microsoft has with concurrency::parallel_for_each
>  https://msdn.microsoft.com/en-us/library/dd492857.aspx
>
>So, at least ugly #ifdef around each parallel for loop could be
   hidden.
> 
>Don’t get me wrong, I don’t want to add just another parallelisation
>library/mechanism.
>And… I guess it won’t be possible to transparently cover all the
   OpenMP
>pragma stuff maybe needed inside for loop body or maybe other stuff
>needed for GCD 

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 15:26, Bernhard Stegmaier wrote:
> I didn’t follow in detail, but from what I saw I guess the bad thing about it 
> was to use OpenMP for
> (1) parallelising for loop
>   and
> (2) creating individual threads for progress reporter and workers.
> 
> As soon as you don’t have OpenMP it didn’t work anymore… so maybe using 
> OpenMP for (1) and usual STL threading stuff for (2) would be a compromise 
> (even) if maybe clumsy.
> At least, it would work also with non-OpenMP systems.
> 
Sure, I'm all in for STL - my only concern is that zone filling, as it
is done now, does not benefit at all from multiple CPU cores. We need a
proper STL-based worker dispatcher for that to work.


Tom


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

> On 1. Mar 2018, at 15:28, Tomasz Wlostowski  wrote:
>> 
> Sure, I'm all in for STL - my only concern is that zone filling, as it
> is done now, does not benefit at all from multiple CPU cores. We need a

Welcome to the KiCad Mac world, citing you some mails ago:
<<<
I'd like to hear from a *single* Apple user who designs boards of
sufficient complexity for the multithreading to really have an impact on
performance.
>>>

Sorry, couldn’t resist… :)

> proper STL-based worker dispatcher for that to work.

Yes, that’s the problem.
std::async goes into that direction, but seems to pretty unusable in practice 
since it doesn’t impose any pooling, etc.


Regards,
Bernhard
___
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

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 15:01, Jon Evans wrote:
> I missed that change to STL, oops!
> In that case we should standardize on STL for all new code in the future
> so that it will work on Mac.

Me too.

I don't understand the purpose of it - now all zone calculation (except
for insulated copper island removal) works in a *single* worker thread
(the main thread is just refreshing the progress dialog).

It means ~3.5x slower zone refilling on a 4-core CPU.

Can anybody comment on that?

Tom


> There are already many edge cases I have found (or users have reported)
> where KiCad is extremely slow, and we need to have a good story for
> multiprocessing so that we can take advantage of it where it makes sense
> to increase performance and/or responsiveness.
> 
> -Jon
> 
> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young  > wrote:
> 
> There’s performance and there’s responsiveness.
> 
> The footprint loading and zone filling were moved to STL so that
> progress reporting would work on Mac.
> 
> As long as we don’t introduce more OpenMP into core stuff, I’m not
> that fixated on what we use for raytracing.
> 
> Cheers,
> Jeff.
> 
> 
>> On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>> > wrote:
>>
>> On 01/03/18 14:29, Jon Evans wrote:
>>> It is also used for zone filling and in my new eeschema connectivity
>>> code that I'm hoping to get merged soon after V5 release.
>>>
>>> I'm happy to help with research / testing of alternatives if we can't
>>> use OpenMP on Mac. 
>>>
>> I'd like to hear from a *single* Apple user who designs boards of
>> sufficient complexity for the multithreading to really have an
>> impact on
>> performance. What's next, rewriting Kicad in Objective-C?
>>
>> - my 5 cents
>>
>> Tom
>>
>>
>>> Jon
>>>
>>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh >> 
>>> > wrote:
>>>
>>>    Ughh!  Thank you Apple.  I'm not opposed to this idea if
>>> OpenMP isn't a
>>>    viable option on macos.  I would like to see our macos port be
>>> on par
>>>    with linux and windows ports.
>>>
>>>    Wayne
>>>
>>>    On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
 I did look around a bit.
 Looks like OpenMP isn’t a friend of Xcode clang, because Apple
 has its
 own Grand Central Dispatch (libdispatch) implementation/library
 doing
 similar things (at first glance, didn’t look into details).
 So, I guess OpenMP maybe won’t happen soon with stock toolchain
 or we
 would have to use non-stock toolchain (probably with all
 problems that
 come with that - I have seen bad things mixing compilers, etc.).

 Seems to be quite easy to convert OpenMP for loop parallelisation
>>>    to GCD:
 <<<
 //#pragma omp parallel for
 //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
 dispatch_queue_t queue =
 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
 {
 ...
 }
 );
>>>

 I just naively replaced all of the OpenMP for loops like above
 and now
 3d-Viewer uses all cores.
 On my i7-3770T rendering time decreased from about 100s to 30s.

 I also did it for the ratsnest loop but didn’t notice any difference
 (maybe my test PCB was just to small).

 I could play around a bit to put that stuff into some nice syntax
>>>    maybe
 similar to what Microsoft has with concurrency::parallel_for_each
   https://msdn.microsoft.com/en-us/library/dd492857.aspx
 
 So, at least ugly #ifdef around each parallel for loop could be
>>>    hidden.

 Don’t get me wrong, I don’t want to add just another parallelisation
 library/mechanism.
 And… I guess it won’t be possible to transparently cover all the
>>>    OpenMP
 pragma stuff maybe needed inside for loop body or maybe other stuff
 needed for GCD (e.g. when writing to variables outside for body).

 Thoughts? Would this be an option?

 Oh, yes:
 I did look into using STL std::async.
 Doesn’t seem to be a good idea, because it usually doesn’t seem
 to use
 anything like thread pools, etc. on various platforms.
 You probably don’t want to create that much threads… :) 


 Regards,
 Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>>>    >>  >> 

Re: [Kicad-developers] MacOS + OpenMP

[Jon Evans]

I missed that change to STL, oops!
In that case we should standardize on STL for all new code in the future so
that it will work on Mac.
There are already many edge cases I have found (or users have reported)
where KiCad is extremely slow, and we need to have a good story for
multiprocessing so that we can take advantage of it where it makes sense to
increase performance and/or responsiveness.

-Jon

On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young  wrote:

> There’s performance and there’s responsiveness.
>
> The footprint loading and zone filling were moved to STL so that progress
> reporting would work on Mac.
>
> As long as we don’t introduce more OpenMP into core stuff, I’m not that
> fixated on what we use for raytracing.
>
> Cheers,
> Jeff.
>
>
> On 1 Mar 2018, at 13:34, Tomasz Wlostowski 
> wrote:
>
> On 01/03/18 14:29, Jon Evans wrote:
>
> It is also used for zone filling and in my new eeschema connectivity
> code that I'm hoping to get merged soon after V5 release.
>
> I'm happy to help with research / testing of alternatives if we can't
> use OpenMP on Mac.
>
> I'd like to hear from a *single* Apple user who designs boards of
> sufficient complexity for the multithreading to really have an impact on
> performance. What's next, rewriting Kicad in Objective-C?
>
> - my 5 cents
>
> Tom
>
>
> Jon
>
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  >> wrote:
>
>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>viable option on macos.  I would like to see our macos port be on par
>with linux and windows ports.
>
>Wayne
>
>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>
> I did look around a bit.
> Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> own Grand Central Dispatch (libdispatch) implementation/library doing
> similar things (at first glance, didn’t look into details).
> So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> would have to use non-stock toolchain (probably with all problems that
> come with that - I have seen bad things mixing compilers, etc.).
>
> Seems to be quite easy to convert OpenMP for loop parallelisation
>
>to GCD:
>
> <<<
> //#pragma omp parallel for
> //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> dispatch_queue_t queue =
> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> {
> ...
> }
> );
>
>
>
> I just naively replaced all of the OpenMP for loops like above and now
> 3d-Viewer uses all cores.
> On my i7-3770T rendering time decreased from about 100s to 30s.
>
> I also did it for the ratsnest loop but didn’t notice any difference
> (maybe my test PCB was just to small).
>
> I could play around a bit to put that stuff into some nice syntax
>
>maybe
>
> similar to what Microsoft has with concurrency::parallel_for_each
>   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> So, at least ugly #ifdef around each parallel for loop could be
>
>hidden.
>
>
> Don’t get me wrong, I don’t want to add just another parallelisation
> library/mechanism.
> And… I guess it won’t be possible to transparently cover all the
>
>OpenMP
>
> pragma stuff maybe needed inside for loop body or maybe other stuff
> needed for GCD (e.g. when writing to variables outside for body).
>
> Thoughts? Would this be an option?
>
> Oh, yes:
> I did look into using STL std::async.
> Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> anything like thread pools, etc. on various platforms.
> You probably don’t want to create that much threads… :)
>
>
> Regards,
> Bernhard
>
> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>
> >
>
> 
>
>
>
> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I
> had never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> if user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used
> for normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t
> think it will be worth it.
>
>
> Regards,
> Bernhard
>
> On 1. Mar 2018, at 00:50, Jeff Young 
>>
>
>   
> Or rip it out and use STL?
>
> On 28 Feb 2018, at 23:38, Jon Evans 
>>
>
> 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Once we figure out what is involved and any risks, we can make a
decision at that point.  I'm working under the assumption that this only
applies to the raytracing.

Wayne

On 3/1/2018 8:41 AM, Bernhard Stegmaier wrote:
> Currently, I fully agree with you.
> 
> The only spot right now where it has real impact is the raytracing 3d viewer.
> And for me it is also only 3x faster with threading, so not that critical for 
> some “offline” functionality.
> 
> But more and more OpenMP stuff might get added which maybe will make an 
> impact in future.
> This has caused much problems with the zone filling already…
> 
> So, from my point of view at least a clear strategy should be defined.
> 
> 
> Bernhard
> 
>> On 1. Mar 2018, at 14:34, Tomasz Wlostowski  
>> wrote:
>>
>> On 01/03/18 14:29, Jon Evans wrote:
>>> It is also used for zone filling and in my new eeschema connectivity
>>> code that I'm hoping to get merged soon after V5 release.
>>>
>>> I'm happy to help with research / testing of alternatives if we can't
>>> use OpenMP on Mac. 
>>>
>> I'd like to hear from a *single* Apple user who designs boards of
>> sufficient complexity for the multithreading to really have an impact on
>> performance. What's next, rewriting Kicad in Objective-C?
>>
>> - my 5 cents
>>
>> Tom
>>
>>
>>> Jon
>>>
>>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh >> > wrote:
>>>
>>>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>>>viable option on macos.  I would like to see our macos port be on par
>>>with linux and windows ports.
>>>
>>>Wayne
>>>
>>>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
 I did look around a bit.
 Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
 own Grand Central Dispatch (libdispatch) implementation/library doing
 similar things (at first glance, didn’t look into details).
 So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
 would have to use non-stock toolchain (probably with all problems that
 come with that - I have seen bad things mixing compilers, etc.).

 Seems to be quite easy to convert OpenMP for loop parallelisation
>>>to GCD:
 <<<
 //#pragma omp parallel for
 //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
 dispatch_queue_t queue =
 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
 {
 ...
 }
 );
>>>

 I just naively replaced all of the OpenMP for loops like above and now
 3d-Viewer uses all cores.
 On my i7-3770T rendering time decreased from about 100s to 30s.

 I also did it for the ratsnest loop but didn’t notice any difference
 (maybe my test PCB was just to small).

 I could play around a bit to put that stuff into some nice syntax
>>>maybe
 similar to what Microsoft has with concurrency::parallel_for_each
   https://msdn.microsoft.com/en-us/library/dd492857.aspx
 So, at least ugly #ifdef around each parallel for loop could be
>>>hidden.

 Don’t get me wrong, I don’t want to add just another parallelisation
 library/mechanism.
 And… I guess it won’t be possible to transparently cover all the
>>>OpenMP
 pragma stuff maybe needed inside for loop body or maybe other stuff
 needed for GCD (e.g. when writing to variables outside for body).

 Thoughts? Would this be an option?

 Oh, yes:
 I did look into using STL std::async.
 Doesn’t seem to be a good idea, because it usually doesn’t seem to use
 anything like thread pools, etc. on various platforms.
 You probably don’t want to create that much threads… :) 


 Regards,
 Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>>>
> >>>> wrote:
>
> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I
> had never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> if user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used
> for normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t
> think it will be worth it.
>
>
> Regards,
> Bernhard
>
>> On 1. Mar 2018, at 00:50, Jeff Young >>
>> >> wrote:
>>
>> Or rip it out and use STL?
>>
>>> On 28 Feb 2018, at 23:38, Jon Evans 

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

There’s performance and there’s responsiveness.

The footprint loading and zone filling were moved to STL so that progress 
reporting would work on Mac.

As long as we don’t introduce more OpenMP into core stuff, I’m not that fixated 
on what we use for raytracing.

Cheers,
Jeff.


> On 1 Mar 2018, at 13:34, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 14:29, Jon Evans wrote:
>> It is also used for zone filling and in my new eeschema connectivity
>> code that I'm hoping to get merged soon after V5 release.
>> 
>> I'm happy to help with research / testing of alternatives if we can't
>> use OpenMP on Mac. 
>> 
> I'd like to hear from a *single* Apple user who designs boards of
> sufficient complexity for the multithreading to really have an impact on
> performance. What's next, rewriting Kicad in Objective-C?
> 
> - my 5 cents
> 
> Tom
> 
> 
>> Jon
>> 
>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh > 
>> >> wrote:
>> 
>>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>>viable option on macos.  I would like to see our macos port be on par
>>with linux and windows ports.
>> 
>>Wayne
>> 
>>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>>> I did look around a bit.
>>> Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
>>> own Grand Central Dispatch (libdispatch) implementation/library doing
>>> similar things (at first glance, didn’t look into details).
>>> So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
>>> would have to use non-stock toolchain (probably with all problems that
>>> come with that - I have seen bad things mixing compilers, etc.).
>>> 
>>> Seems to be quite easy to convert OpenMP for loop parallelisation
>>to GCD:
>>> <<<
>>> //#pragma omp parallel for
>>> //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>>> dispatch_queue_t queue =
>>> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>>> dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>>> {
>>> ...
>>> }
>>> );
>> 
>>> 
>>> I just naively replaced all of the OpenMP for loops like above and now
>>> 3d-Viewer uses all cores.
>>> On my i7-3770T rendering time decreased from about 100s to 30s.
>>> 
>>> I also did it for the ratsnest loop but didn’t notice any difference
>>> (maybe my test PCB was just to small).
>>> 
>>> I could play around a bit to put that stuff into some nice syntax
>>maybe
>>> similar to what Microsoft has with concurrency::parallel_for_each
>>>   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
>>> 
>>> So, at least ugly #ifdef around each parallel for loop could be
>>hidden.
>>> 
>>> Don’t get me wrong, I don’t want to add just another parallelisation
>>> library/mechanism.
>>> And… I guess it won’t be possible to transparently cover all the
>>OpenMP
>>> pragma stuff maybe needed inside for loop body or maybe other stuff
>>> needed for GCD (e.g. when writing to variables outside for body).
>>> 
>>> Thoughts? Would this be an option?
>>> 
>>> Oh, yes:
>>> I did look into using STL std::async.
>>> Doesn’t seem to be a good idea, because it usually doesn’t seem to use
>>> anything like thread pools, etc. on various platforms.
>>> You probably don’t want to create that much threads… :) 
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>> 
>> >
 
>> On 1. Mar 2018, at 00:50, Jeff Young  
>>>
>    
> Or rip it out and use STL?
> 
>> On 28 Feb 2018, at 23:38, Jon Evans > 
>>>
>> 

Re: [Kicad-developers] MacOS + OpenMP

[Adam Wolf]

This seems like it is not critical for the upcoming V5 release, but
that a strategy should be determined before we get too far into V6,
right?

Adam

On Thu, Mar 1, 2018 at 7:41 AM, Bernhard Stegmaier
 wrote:
> Currently, I fully agree with you.
>
> The only spot right now where it has real impact is the raytracing 3d viewer.
> And for me it is also only 3x faster with threading, so not that critical for 
> some “offline” functionality.
>
> But more and more OpenMP stuff might get added which maybe will make an 
> impact in future.
> This has caused much problems with the zone filling already…
>
> So, from my point of view at least a clear strategy should be defined.
>
>
> Bernhard
>
>> On 1. Mar 2018, at 14:34, Tomasz Wlostowski  
>> wrote:
>>
>> On 01/03/18 14:29, Jon Evans wrote:
>>> It is also used for zone filling and in my new eeschema connectivity
>>> code that I'm hoping to get merged soon after V5 release.
>>>
>>> I'm happy to help with research / testing of alternatives if we can't
>>> use OpenMP on Mac.
>>>
>> I'd like to hear from a *single* Apple user who designs boards of
>> sufficient complexity for the multithreading to really have an impact on
>> performance. What's next, rewriting Kicad in Objective-C?
>>
>> - my 5 cents
>>
>> Tom
>>
>>
>>> Jon
>>>
>>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh >> > wrote:
>>>
>>>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>>>viable option on macos.  I would like to see our macos port be on par
>>>with linux and windows ports.
>>>
>>>Wayne
>>>
>>>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
 I did look around a bit.
 Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
 own Grand Central Dispatch (libdispatch) implementation/library doing
 similar things (at first glance, didn’t look into details).
 So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
 would have to use non-stock toolchain (probably with all problems that
 come with that - I have seen bad things mixing compilers, etc.).

 Seems to be quite easy to convert OpenMP for loop parallelisation
>>>to GCD:
 <<<
 //#pragma omp parallel for
 //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
 dispatch_queue_t queue =
 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
 {
 ...
 }
 );
>>>

 I just naively replaced all of the OpenMP for loops like above and now
 3d-Viewer uses all cores.
 On my i7-3770T rendering time decreased from about 100s to 30s.

 I also did it for the ratsnest loop but didn’t notice any difference
 (maybe my test PCB was just to small).

 I could play around a bit to put that stuff into some nice syntax
>>>maybe
 similar to what Microsoft has with concurrency::parallel_for_each
   https://msdn.microsoft.com/en-us/library/dd492857.aspx
 So, at least ugly #ifdef around each parallel for loop could be
>>>hidden.

 Don’t get me wrong, I don’t want to add just another parallelisation
 library/mechanism.
 And… I guess it won’t be possible to transparently cover all the
>>>OpenMP
 pragma stuff maybe needed inside for loop body or maybe other stuff
 needed for GCD (e.g. when writing to variables outside for body).

 Thoughts? Would this be an option?

 Oh, yes:
 I did look into using STL std::async.
 Doesn’t seem to be a good idea, because it usually doesn’t seem to use
 anything like thread pools, etc. on various platforms.
 You probably don’t want to create that much threads… :)


 Regards,
 Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>>>
> >>>> wrote:
>
> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I
> had never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> if user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used
> for normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t
> think it will be worth it.
>
>
> Regards,
> Bernhard
>
>> On 1. Mar 2018, at 00:50, Jeff Young >>
>> >> wrote:
>>
>> Or rip it out and use STL?
>>
>>> On 28 Feb 2018, at 23:38, Jon Evans 

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

The zone filler was moved to STL.

> On 1 Mar 2018, at 13:29, Jon Evans  wrote:
> 
> It is also used for zone filling and in my new eeschema connectivity code 
> that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't use 
> OpenMP on Mac. 
> 
> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  > wrote:
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
> > 
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  >> 
> >> >> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  >>> 
> >>> >> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans   
>  >> wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers 
>  
>  Post to : kicad-developers@lists.launchpad.net 
>  
>    >
>  Unsubscribe : https://launchpad.net/~kicad-developers 
>  
>  More help   

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

The zone filling code was the only spot which didn’t work by just simply 
replacing the for loop with dispatch_apply.
I’ll have to dig a little deeper on what has to be done there… I guess it is 
something about using variables outside the loop body in the clang block given 
to dispatch_apply.


Bernhard

> On 1. Mar 2018, at 14:29, Jon Evans  wrote:
> 
> It is also used for zone filling and in my new eeschema connectivity code 
> that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't use 
> OpenMP on Mac. 
> 
> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  > wrote:
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
> > 
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  >> 
> >> >> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  >>> 
> >>> >> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans   
>  >> wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers 
>  
>  Post to : kicad-developers@lists.launchpad.net 
>  

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 14:29, Jon Evans wrote:
> It is also used for zone filling and in my new eeschema connectivity
> code that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't
> use OpenMP on Mac. 
> 
I'd like to hear from a *single* Apple user who designs boards of
sufficient complexity for the multithreading to really have an impact on
performance. What's next, rewriting Kicad in Objective-C?

- my 5 cents

Tom


> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  > wrote:
> 
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation
> to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax
> maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> > So, at least ugly #ifdef around each parallel for loop could be
> hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the
> OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
> 
> >>  >> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  
> >>> >> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans  
>  >> wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
> 

Re: [Kicad-developers] MacOS + OpenMP

[Jon Evans]

It is also used for zone filling and in my new eeschema connectivity code
that I'm hoping to get merged soon after V5 release.

I'm happy to help with research / testing of alternatives if we can't use
OpenMP on Mac.

Jon

On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  wrote:

> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
>
> Wayne
>
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :)
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  >> > wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  >>> > wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans   > wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
>  ___
>  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
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> 
> 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
viable option on macos.  I would like to see our macos port be on par
with linux and windows ports.

Wayne

On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> I did look around a bit.
> Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> own Grand Central Dispatch (libdispatch) implementation/library doing
> similar things (at first glance, didn’t look into details).
> So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> would have to use non-stock toolchain (probably with all problems that
> come with that - I have seen bad things mixing compilers, etc.).
> 
> Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> <<<
> //#pragma omp parallel for
> //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> dispatch_queue_t queue =
> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> {
> ...
> }
> );

> 
> I just naively replaced all of the OpenMP for loops like above and now
> 3d-Viewer uses all cores.
> On my i7-3770T rendering time decreased from about 100s to 30s.
> 
> I also did it for the ratsnest loop but didn’t notice any difference
> (maybe my test PCB was just to small).
> 
> I could play around a bit to put that stuff into some nice syntax maybe
> similar to what Microsoft has with concurrency::parallel_for_each
>   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> So, at least ugly #ifdef around each parallel for loop could be hidden.
> 
> Don’t get me wrong, I don’t want to add just another parallelisation
> library/mechanism.
> And… I guess it won’t be possible to transparently cover all the OpenMP
> pragma stuff maybe needed inside for loop body or maybe other stuff
> needed for GCD (e.g. when writing to variables outside for body).
> 
> Thoughts? Would this be an option?
> 
> Oh, yes:
> I did look into using STL std::async.
> Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> anything like thread pools, etc. on various platforms.
> You probably don’t want to create that much threads… :) 
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 08:40, Bernhard Stegmaier > > wrote:
>>
>> I had a quick look where OpenMP is used.
>>
>> I found it somewhere in the connectivity/ratsnest code.
>> I don’t know of any complaints in that area and even on my old HW I
>> had never a bad experience.
>>
>> And then, 3D-Viewer.
>>
>> So, in my opinion it is basically only about 3D-Viewer… I don’t know
>> if user experience will be that bad without OpenMP.
>> IMHO it’s only the Raytracing view, which isn’t intended to be used
>> for normal viewing stuff anyway.
>>
>> If I find some time over the weekend I will also try… but I don’t
>> think it will be worth it.
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 1. Mar 2018, at 00:50, Jeff Young >> > wrote:
>>>
>>> Or rip it out and use STL?
>>>
 On 28 Feb 2018, at 23:38, Jon Evans > wrote:

 Hi all,

 Does anyone have a working build setup for getting OpenMP-enabled
 KiCad out of MacOS?
 If so, please share how -- I tried for a bit but couldn't get it
 going (I'm not super familiar with the MacOS toolchain yet).

 We should make sure that the 5.0 release is built with OpenMP,
 otherwise our Mac users are going to have a slower user experience.

 -Jon
 ___
 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
>>
>>
>> ___
>> 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
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I did look around a bit.
Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its own 
Grand Central Dispatch (libdispatch) implementation/library doing similar 
things (at first glance, didn’t look into details).
So, I guess OpenMP maybe won’t happen soon with stock toolchain or we would 
have to use non-stock toolchain (probably with all problems that come with that 
- I have seen bad things mixing compilers, etc.).

Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
<<<
//#pragma omp parallel for
//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
dispatch_queue_t queue = 
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
{
...
}
);
>>>

I just naively replaced all of the OpenMP for loops like above and now 
3d-Viewer uses all cores.
On my i7-3770T rendering time decreased from about 100s to 30s.

I also did it for the ratsnest loop but didn’t notice any difference (maybe my 
test PCB was just to small).

I could play around a bit to put that stuff into some nice syntax maybe similar 
to what Microsoft has with concurrency::parallel_for_each
  https://msdn.microsoft.com/en-us/library/dd492857.aspx 

So, at least ugly #ifdef around each parallel for loop could be hidden.

Don’t get me wrong, I don’t want to add just another parallelisation 
library/mechanism.
And… I guess it won’t be possible to transparently cover all the OpenMP pragma 
stuff maybe needed inside for loop body or maybe other stuff needed for GCD 
(e.g. when writing to variables outside for body).

Thoughts? Would this be an option?

Oh, yes:
I did look into using STL std::async.
Doesn’t seem to be a good idea, because it usually doesn’t seem to use anything 
like thread pools, etc. on various platforms.
You probably don’t want to create that much threads… :) 


Regards,
Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  wrote:
> 
> I had a quick look where OpenMP is used.
> 
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I had never 
> a bad experience.
> 
> And then, 3D-Viewer.
> 
> So, in my opinion it is basically only about 3D-Viewer… I don’t know if user 
> experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used for 
> normal viewing stuff anyway.
> 
> If I find some time over the weekend I will also try… but I don’t think it 
> will be worth it.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 00:50, Jeff Young  wrote:
>> 
>> Or rip it out and use STL?
>> 
>>> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
>>> 
>>> Hi all,
>>> 
>>> Does anyone have a working build setup for getting OpenMP-enabled KiCad out 
>>> of MacOS?
>>> If so, please share how -- I tried for a bit but couldn't get it going (I'm 
>>> not super familiar with the MacOS toolchain yet).
>>> 
>>> We should make sure that the 5.0 release is built with OpenMP, otherwise 
>>> our Mac users are going to have a slower user experience.
>>> 
>>> -Jon
>>> ___
>>> 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
> 
> 
> ___
> 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

Re: [Kicad-developers] MacOS + OpenMP

[Andrey Kuznetsov]

Is there a complicated board design online I could download and test for
comparison between macOS and windows?
Someone people have used before for kicad verification for example.

On Wed, Feb 28, 2018 at 11:40 PM, Bernhard Stegmaier <
stegma...@sw-systems.de> wrote:

> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I had
> never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know if
> user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used for
> normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t think it
> will be worth it.
>
>
> Regards,
> Bernhard
>
> > On 1. Mar 2018, at 00:50, Jeff Young  wrote:
> >
> > Or rip it out and use STL?
> >
> >> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
> >>
> >> Hi all,
> >>
> >> Does anyone have a working build setup for getting OpenMP-enabled KiCad
> out of MacOS?
> >> If so, please share how -- I tried for a bit but couldn't get it going
> (I'm not super familiar with the MacOS toolchain yet).
> >>
> >> We should make sure that the 5.0 release is built with OpenMP,
> otherwise our Mac users are going to have a slower user experience.
> >>
> >> -Jon
> >> ___
> >> 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
>
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I had a quick look where OpenMP is used.

I found it somewhere in the connectivity/ratsnest code.
I don’t know of any complaints in that area and even on my old HW I had never a 
bad experience.

And then, 3D-Viewer.

So, in my opinion it is basically only about 3D-Viewer… I don’t know if user 
experience will be that bad without OpenMP.
IMHO it’s only the Raytracing view, which isn’t intended to be used for normal 
viewing stuff anyway.

If I find some time over the weekend I will also try… but I don’t think it will 
be worth it.


Regards,
Bernhard

> On 1. Mar 2018, at 00:50, Jeff Young  wrote:
> 
> Or rip it out and use STL?
> 
>> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
>> 
>> Hi all,
>> 
>> Does anyone have a working build setup for getting OpenMP-enabled KiCad out 
>> of MacOS?
>> If so, please share how -- I tried for a bit but couldn't get it going (I'm 
>> not super familiar with the MacOS toolchain yet).
>> 
>> We should make sure that the 5.0 release is built with OpenMP, otherwise our 
>> Mac users are going to have a slower user experience.
>> 
>> -Jon
>> ___
>> 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


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

Or rip it out and use STL?

> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
> 
> Hi all,
> 
> Does anyone have a working build setup for getting OpenMP-enabled KiCad out 
> of MacOS?
> If so, please share how -- I tried for a bit but couldn't get it going (I'm 
> not super familiar with the MacOS toolchain yet).
> 
> We should make sure that the 5.0 release is built with OpenMP, otherwise our 
> Mac users are going to have a slower user experience.
> 
> -Jon
> ___
> 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

[Kicad-developers] MacOS + OpenMP

[Jon Evans]

Hi all,

Does anyone have a working build setup for getting OpenMP-enabled KiCad out
of MacOS?
If so, please share how -- I tried for a bit but couldn't get it going (I'm
not super familiar with the MacOS toolchain yet).

We should make sure that the 5.0 release is built with OpenMP, otherwise
our Mac users are going to have a slower user experience.

-Jon
___
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