Re: [Gnucap-devel] faster queueing

[al davis]

On Tue, 23 Feb 2016 10:36:36 +0100
Felix Salfelder <address@hidden> wrote:
> As you had pointed out, CARD_LIST::tr_queue_eval iterates over the whole
> circuit instead of over all the non-constant components.
> 
> to work around that, i have added another list to CARD_LIST holding the
> pointers to the components that are not constant (during precalc_last).

seems like a good idea, for now.  My intent, long ago, was to replace
what is there with some kind of shorter list.

> using this list instead of the full list decreases tr simulation time by
> a factor of almost two (eq4-9217.tran.ckt).

I am suspicious of this.  If the implementation is correct, the results
would be exactly the same, including the same number of iterations, the
same number of model evaluations.

What is changing, the potential for time saving, is to reduce the
number of times the question "needs_eval?" is asked when the answer can
be predicted in advance to be "no".

I see a few things wrong.

Devices with storage may need evaluation even when constant, to
accommodate step changes.

tr_advance is needed, constant values or not.  

tr_review is needed, constant values or not.

> the changes involve one uglyness, that i think you are already aware
> of... the dc sweep pointer-hacks elements and sets them non-constant, so
> they are queued. this non-const setting comes after the non-const queue
> has been set up (too late). my current workaround adds these elements to
> the evaluation queue of the top level circuit.

The whole dc sweep pointer hack is ugly.  With params, it shouldn't be
needed any more, but I haven't had the time to do it.


> 
> i have attached a patch, it is against -uf. i think it transports the
> idea, and gives some numbers on the speed impact. i will backport as
> soon as i know a proper way to deal with the dc-hack.