Hi Maciej,
Your last changes allow a complete independence of the loop iterations
in RN_DATA::Recalculate( int aNet ).
I have almost a 2x speedup on a Core i7-4770 with the very simple
parallelization in the attached patch. I was expecting more, though. There
seems to be a bottleneck somewhere.
Hi Carl,
Great job! I have just tested your patch and I confirm 2x boost on my
machine as well. To tell the truth, I consider this a big speedup -
particularly that you made it with just a few lines of code.
RN_DATA::Recalculate() is run every time when there are changes on the
board (e.g.
I'm glad you like it. You did most of the work by eliminating the statics
in the triangulator.
I have not tested it under any other platform than Linux, but it's supposed
to work under MSVC++ as well.
On Fri, Jan 31, 2014 at 12:01 PM, Maciej Sumiński
maciej.sumin...@cern.chwrote:
Hi Carl,
mailto:kicad-developers@__lists.launchpad.net
mailto:kicad-developers@lists.launchpad.net
Sent: Wednesday, January 22, 2014 3:51 AM
Subject: Re: [Kicad-developers] Net names and net codes
: [Kicad-developers] Net names and net codes
There are some things in the code that don't like being
multithreaded. If I parallelize the for loop in
RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
happen if I put a lock to the call updateNet( i
:
From: Carl Poirier carl.poirie...@gmail.com
To: Marco Serantoni marco.serant...@gmail.com
Cc: Kicad Developers kicad-developers@lists.launchpad.net
Sent: Wednesday, January 22, 2014 3:51 AM
Subject: Re: [Kicad-developers] Net names and net codes
21/01/14 18:51, Carl Poirier kirjoitti:
There are some things in the code that don't like being multithreaded. If I
parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a
segfault.
It probably makes more sense to vectorize the loop than making it
multi-threaded. Then you don't
Maybe. Having no experience whatsoever in vectorization, I'm looking into
multithreading. Anyway, I believe one doesn't exclude the other.
On Wed, Jan 22, 2014 at 12:23 PM, Vesa Solonen vesa.solo...@aalto.fiwrote:
21/01/14 18:51, Carl Poirier kirjoitti:
There are some things in the code that
To: Marco Serantoni marco.serant...@gmail.com
mailto:marco.serant...@gmail.com
Cc: Kicad Developers kicad-developers@lists.launchpad.net
mailto:kicad-developers@lists.launchpad.net
Sent: Wednesday, January 22, 2014 3:51 AM
Subject: Re: [Kicad-developers] Net names and net codes
From: Carl Poirier carl.poirie...@gmail.com
To: Vesa Solonen vesa.solo...@aalto.fi
Cc: KiCad Developers kicad-developers@lists.launchpad.net
Sent: Thursday, January 23, 2014 4:41 AM
Subject: Re: [Kicad-developers] Net names and net codes
Maybe. Having
There are some things in the code that don't like being multithreaded. If I
parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a
segfault. It does not happen if I put a lock to the call updateNet( i ),
but obviously there is no increase in performance. I'm trying to find out
From: Carl Poirier carl.poirie...@gmail.com
To: Marco Serantoni marco.serant...@gmail.com
Cc: Kicad Developers kicad-developers@lists.launchpad.net
Sent: Wednesday, January 22, 2014 3:51 AM
Subject: Re: [Kicad-developers] Net names and net codes
Only the warning: keep attention that boost::context doesn't support the
context switch for the vector registers
(mmx*/v*).
If needed i can help you to implement.
--
Marco
On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen vesa.solo...@aalto.fi wrote:
13/01/14 10:04, Maciej Sumiński kirjoitti:
Great, now it seems that we have a group of people who are experienced
with the subject. I believe this has to end up with some speed up in KiCad.
Regards,
Orson
On 01/14/2014 10:59 AM, Marco Serantoni wrote:
Only the warning: keep attention that boost::context doesn't support the
context
Nice,
But please, think before add dependencies and look deeply if those are
supported for all platforms, I wish being able to don't trash years of work.
--
Marco
On Tue, Jan 14, 2014 at 11:00 AM, Maciej Sumiński
maciej.sumin...@cern.chwrote:
Great, now it seems that we have a group of
Well, if OpenMP is alright with you, I'll give it a shot this weekend.
On Tue, Jan 14, 2014 at 5:12 AM, Marco Serantoni
marco.serant...@gmail.comwrote:
Nice,
But please, think before add dependencies and look deeply if those are
supported for all platforms, I wish being able to don't trash
On 01/10/2014 08:45 PM, Vesa Solonen wrote:
10/01/14 19:35, Maciej Sumiński kirjoitti:
the board that I recommended for testing the GAL
(http://www.ohwr.org/attachments/download/2187/wrs.kicad_pcb), when you
drag the biggest IC in the middle, as it contains the greatest number of
nets
13/01/14 10:04, Maciej Sumiński kirjoitti:
I fully support the idea, in fact I have dreamed about this too
(http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades).
I had a short try with OpenMP, but I did not get any better results, so
it seems that I could have done it
Le 10/01/2014 18:35, Maciej Sumiński a écrit :
On 01/09/2014 04:51 PM, jp charras wrote:
Le 09/01/2014 11:22, Tomasz Wlostowski a écrit :
On 01/08/2014 04:39 PM, jp charras wrote:
Tracks do not store the net name but just the net code, because they
are
expected to be connected to pads
On 01/09/2014 04:51 PM, jp charras wrote:
Le 09/01/2014 11:22, Tomasz Wlostowski a écrit :
On 01/08/2014 04:39 PM, jp charras wrote:
Tracks do not store the net name but just the net code, because
they are
expected to be connected to pads which store this info.
(this is the reason tracks
10/01/14 19:35, Maciej Sumiński kirjoitti:
the board that I recommended for testing the GAL
(http://www.ohwr.org/attachments/download/2187/wrs.kicad_pcb), when you
drag the biggest IC in the middle, as it contains the greatest number of
nets connected. After being dropped you may observe a
On 01/08/2014 04:39 PM, jp charras wrote:
Le 08/01/2014 15:35, Maciej Sumiński a écrit :
I am wondering if there are any special reasons to keep net names and
net codes separated. This gives programmer a chance to set a net code
that is actually not related to the appropriate net name. One is
On 01/08/2014 04:39 PM, jp charras wrote:
Tracks do not store the net name but just the net code, because they are
expected to be connected to pads which store this info.
(this is the reason tracks and vias not connected to a pad lose their
net after loading a board, or reading a netlist)
Le 09/01/2014 09:56, Maciej Sumiński a écrit :
On 01/08/2014 04:39 PM, jp charras wrote:
Le 08/01/2014 15:35, Maciej Sumiński a écrit :
I am wondering if there are any special reasons to keep net names and
net codes separated. This gives programmer a chance to set a net code
that is actually
Le 09/01/2014 11:22, Tomasz Wlostowski a écrit :
On 01/08/2014 04:39 PM, jp charras wrote:
Tracks do not store the net name but just the net code, because they are
expected to be connected to pads which store this info.
(this is the reason tracks and vias not connected to a pad lose their
I am wondering if there are any special reasons to keep net names and
net codes separated. This gives programmer a chance to set a net code
that is actually not related to the appropriate net name. One is even
able to set a net name that does not exist using D_PAD::SetNetname() for
a single
26 matches
Mail list logo
