kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sat, Apr 27, 2013 at 11:11:54AM -0500, Dick Hollenbeck wrote:
> But how important is that really?  Will it result in a reduction in pay?
> 
> The "common" user has been a hobbyist, and is becoming a corporate employee as the
> software gets better.

OK, even most of the corporate employees have probably 0% of
understanding a boolean expression. Unless he's a digital designer :D
woes on him in that case

> So while I agree, I think the importance of this concern is minimal.  Actually zero.
> If we like it, that should be good enough.  We are corporate employees, and are paying to
> make this software useable for our needs.  You said yourself the same thing.

Agree on that. But if it's possible to make it usable for the
non-programmer people (without too much work) then it's better.
Otherwise I'd looking for components using grep instead of the component
browser for example (the sad thing is that often grepping is more
effective...)

> Great idea, do it.  It seems we are all still open to the best ideas.

In a previous message I wrote about how CAM350/gerbtool do DRC. The CAM
products are for 60% DRC beasts so they know how to do their job:D

Eagle has a simple netclass-to-netclass clearance. I haven't used any
other of the 'big ones' (Altium, Allegro, PADS or Expedition) so I don't
really know how they handle it. Many entry level products don't have even
a netclass notion, so we already are way above them:D

> Is there a way we can provide a python expression, but do most of the work in C++?, by
> implementing the functions being called in C++ behind the expression, by following the
> python C API.
> 
> This is a slight variation on the original idea, which can be a way to turbo charge it,
> maybe to cut out a few lookups at runtime.
> 
> Obviously the python expressions can all be "pre-compiled", but I don't think they can be
> "pre-evalutated" when "both" is in play, since that is a dynamic match maker.

Caching (memoizing, actually) strategies for the python calls would
depend on the data available to the call. Assuming the function is pure
(i.e. depending only on the passed parameters) you could cull *a lot* of
calls.

Example (in C, I don't know python enough): function returning
the clearance (one of the contended values) between two netclasses and
the current layer; with only the minimum data we'd have:

int dynamic_clearance(const char *netclass1, const char *netclass2,
                      const char *layer);

*iif* the implementation is pure, as from the hypothesis, there are no
external dependancies and no collateral effects so *every* call with
a tuple (triplet) would always return the same value. Put it in a map
(memoize it) and you have just resolved the clearance issues between
these two classes on that layer with just one python call. AFAIK
memoizing is a standard idiom in python, too.

More flexibility reduces optimization possibilities. Let's say we pass
the netnames too (don't ask why, maybe the user wants more granularity
than netnames, no idea)

int dynamic_clearance(const char *netclass1, const char *netclass2,
                      const char *netname1, const char *netname2,
                      const char *layer);

Here memoizing is a lot less effective... you only cache clearance
between two nets (the netclasses are actually redundant and passed as
convenience). However you would optimize the common case of buses
wandering around the board. Still a good improvement, probably.

At the other end, if the decision function has the whole segment
information at hand:

int dynamic_clearance(const char *netclass1, const char *netclass2,
                      const char *netname1, const char *netname2,
                      const char *layer, int stuff, int other_stuff...)

Then we gain *no* performance since (ideally) every segment is tested
against any other segment just once. In fact caching overhead would
probably make it slower than without.

That said, maybe a python call is just so fast that the big time is
spent computing distances maybe. Or the bottleneck is in the string
comparison. If it was LUA instead of Python I'd say to directly call the
function without any doubt (LUA strings are interned so the string
equality is pointer equality for example, and the byte code interpreter
is... well, fast).

As you said instrumented profiling is needed, at least to compare the cost
of a python call to the rest of the stuff in the DRC routines.

-- 
Lorenzo Marcantonio
Logos Srl