Hi Maciej, I will do very soon as well as send you a patch for my changes.
Carl On Mon, Jan 27, 2014 at 5:47 AM, Maciej Sumiński <maciej.sumin...@cern.ch>wrote: > That is a good start, I hope we can get even more performance boost now. > Could you please try the lp:~cern-kicad/kicad/ratsnest_threadsafe branch > to check if it solves the problem with createDelaunay() function? > It would be great if you shared your changes (especially if they crash the > application), so I could test them as well and look for fixes. > > Regards, > Orson > > > On 01/24/2014 04:35 PM, Carl Poirier wrote: > >> >> I think that we will have a very great speedup if each thread can have >> its own Triangulation. Just by parallelizing the loop in >> RN_DATA::recalculate() but going sequentially with one Triangulation, I >> still have ~25% gain in calculation time. >> >> On Wed, Jan 22, 2014 at 2:59 PM, Maciej Sumiński >> <maciej.sumin...@cern.ch <mailto:maciej.sumin...@cern.ch>> wrote: >> >> Hi Carl, >> >> Thank you for putting efforts to boost the performance of the >> ratsnest. >> The function is brought by an external library >> (http://www.sintef.no/__Projectweb/Geometry-Toolkits/__TTL/ >> <http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/>), I am not >> >> sure what is exactly inside. The expected output should be a >> Delaunay triangulation of all nodes that are taken into account >> while computing ratsnest. >> The only issue I am aware of, is the function does not handle well >> empty containers, but it should not be the case right now. >> >> Now, when I looked again to the source code, RN_DATA is derived >> after hed::Node class (include/ttl/halfedge/__hetriang.h), which >> >> contains a static field. Another thing is (I believe this is the >> main source of troubles) static hed::Triangulation >> (include/ttl/halfedge/__hetraits.h:73). >> >> Sorry that I did not say about that before, but I have just >> discovered that it is done that way. I will try to change it, but >> unfortunately there are little chances that I manage to do that >> before Sunday. >> >> Regards, >> Orson >> >> >> >> On 01/22/2014 06:08 PM, Carl Poirier wrote: >> >> Maciej, >> >> Can you summarize to me how the function >> "Triangulation::__createDelaunay( >> >> nodes.begin(), nodes.end() )" works, and what are the data >> structures >> involved? >> >> I believe there are some dependencies in there. >> >> >> On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo >> <cirilo_berna...@yahoo.com <mailto:cirilo_berna...@yahoo.com> >> <mailto:cirilo_bernardo@yahoo.__com >> <mailto:cirilo_berna...@yahoo.com>>> wrote: >> >> >__________________________________ >> >> > From: Carl Poirier <carl.poirie...@gmail.com >> <mailto:carl.poirie...@gmail.com> >> <mailto:carl.poirier.2@gmail.__com >> >> <mailto:carl.poirie...@gmail.com>>> >> >To: Marco Serantoni <marco.serant...@gmail.com >> <mailto:marco.serant...@gmail.com> >> <mailto:marco.serantoni@gmail.__com >> >> <mailto:marco.serant...@gmail.com>>> >> >Cc: Kicad Developers >> <kicad-developers@lists.__launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> <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 >> > >> > >> > >> >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 >> the problem now. >> > >> > >> > >> This sounds to me like data is being altered by different >> threads >> and possibly there is some memory reallocation happening >> (growing >> arrays, etc). Locks are only needed when there is contention >> somewhere and of course locks should only be held for as >> short as >> needed. Another pitfall with threading is that some >> variables may >> need to be declared 'volatile' if they can be altered in >> another >> thread while one function is executing. For example, let's >> say the >> variable 'bool someX' can be altered in 2 threads; >> something like >> this can happen: >> >> 1. FunctionA starts, and runs a loop while(!someX) { ... } >> 2. FunctionB sets 'someX' to 'true' >> 3. FunctionA continues to run the loop, which is not the >> intended >> behavior >> >> Of course similar things can happen when using shared >> memory and >> forked processes. >> >> Threading has other problems to watch out for - for >> example, are >> there any static variables in functions? If so then you >> simply >> cannot thread those functions without locks. >> >> - Cirilo >> >> >> >> >> _________________________________________________ >> Mailing list: https://launchpad.net/~kicad-__developers >> <https://launchpad.net/~kicad-developers> >> Post to : kicad-developers@lists.__launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~kicad-__developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/__ListHelp >> <https://help.launchpad.net/ListHelp> >> >> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
