Le 28/01/2014 10:51, Maciej Sumiński a écrit :
> Hi Jean-Pierre,
>
> I am done with the changes that would let me rely on the net codes in
> other parts of code. I did my best to perform tests and put comments to
> each commit, so they could be easier to understand and verify.
> Could you please h
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
wrote:
> Hi Carl,
>
> Great job! I have just
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. ite
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. I
Hi Jean-Pierre,
I am done with the changes that would let me rely on the net codes in
other parts of code. I did my best to perform tests and put comments to
each commit, so they could be easier to understand and verify.
Could you please have a look at the lp:~cern-kicad/kicad/netnames
branch?
:carl.poirie...@gmail.com>
>> <mailto:carl.poirier.2@gmail.__com
>>
>> <mailto:carl.poirie...@gmail.com>>>
>> >To: Marco Serantoni > <mailto:marco.serant...@gmail.com>
>> <mailto:marco.seranto
sts.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
>
>
>
t 4:05 PM, Cirilo Bernardo
>> mailto:cirilo_berna...@yahoo.com>> wrote:
>>
>> >
>> > From: Carl Poirier > <mailto:carl.poirie...@gmail.com>>
>> >To: Marco Serantoni > <mailto:marco.serant...@gmail
>
> From: Carl Poirier
>To: Vesa Solonen
>Cc: KiCad Developers
>Sent: Thursday, January 23, 2014 4:41 AM
>Subject: Re: [Kicad-developers] Net names and net codes
>
>
>
>Maybe. Having no experience whatsoever in vectorization, I&#
ailto:marco.serant...@gmail.com>>
>Cc: Kicad Developers mailto:kicad-developers@lists.launchpad.net>>
>Sent: Wednesday, January 22, 2014 3:51 AM
>Subject: Re: [Kicad-developers] Net names and net codes
>
>
>
>There are some
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 wrote:
> 21/01/14 18:51, Carl Poirier kirjoitti:
> > There are some things in the code that don't like being m
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
ardo
wrote:
> >
> > From: Carl Poirier
> >To: Marco Serantoni
> >Cc: Kicad Developers
> >Sent: Wednesday, January 22, 2014 3:51 AM
> >Subject: Re: [Kicad-developers] Net names and net codes
> >
> >
> >
> >There are some things in th
>
> From: Carl Poirier
>To: Marco Serantoni
>Cc: Kicad Developers
>Sent: Wednesday, January 22, 2014 3:51 AM
>Subject: Re: [Kicad-developers] Net names and net codes
>
>
>
>There are some things in the code that don&#x
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
what's
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
wrote:
> 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.
>
>
>
> -
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
wrote:
> Great, now it seems that we have a group of people who are experienced
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 swit
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 wrote:
> 13/01/14 10:04, Maciej Sumiński kirjoitti:
>
> > I fully support t
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
Hi Carl,
That's great news. Do not hesitate to ask about the code if you have any
doubts. I keep fingers crossed.
Regards,
Orson
On 01/13/2014 03:46 PM, Carl Poirier wrote:
I read the small section about it in the wiki and have seen your
outcome. Having experience with not only OpenMP but
th
I read the small section about it in the wiki and have seen your outcome.
Having experience with not only OpenMP but threading/multiprocessing in
general (OpenCL, OpenMPI and GoRoutines), I will give the code a look. I'll
then let you know if I give it a go.
Regards,
Carl
On Mon, Jan 13, 2014 a
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 connected
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 con
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/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
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 t
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 i
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)
Theref
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 ev
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 even
> able to set a net name that does n
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 pad
32 matches
Mail list logo
