[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: gnucap: Multi-disciplinary / mixed language simulation



On Wed, 2007-01-31 at 12:45 -0500, al davis wrote:

> The most useul one is "ADMS", which was developed by Freescale 
> Semiconductor (formerly Motorola). 
> (http://mot-adms.sourceforge.net).

Thanks.. I'll take a look

[snip]

> > An octave plugin to:
> 
> I am not familiar with octave plug-ins.

They link a binary, ".oct" file which is dynamically loaded. Allows
coding of functions in "C", or other languages - bypassing the
interpreter if you wish.

> > A plugin to gnucap which:
> >
> > a) Can write octave's data file format(s)
> 
> That would be useful.  Something that looks like a device or 
> model to gnucap, so you can write interactive models as .m 
> files.

I'm not sure if you're commenting directly about point "a)" above.. that
point really meant being able to output the results in a data-format
natively understood by octave.

I'm not really sure exactly how it would work, but something
interactive / scriptable in Octave would be interesting. 

> > I'm actually avoiding octave as much as I can.. its maths
> > libaries are nice, but as an interpreted language, doing real
> > tasks in it (if they have loops) is really slow.
>
> Have you tried "R"?  It too is interpreted but for matrix 
> operations it is very fast.  It is a derivative of "S" which 
> was developed at Bell Labs, but somehow became a commercial 
> product.  The creator of "S" is now developing "R" which is 
> GPL.

I'd heard of it, but have never worked with it.

> Interpreted languages are not necessarily slow.  For example, if 
> matrix operations are built-in, you don't suffer the speed 
> penalty for the loops that process matrices, and might benefit 
> from optimized built-in algorithms that are more optimized than 
> you would do.

Some of Octave is good, but for example... the ODE45 solver (which is
replacing matlab's one of the same name) lacks proper argument passing,
and is written in the interpreted ".m" language. I translated roughly
line by line into C++, and got a massive speedup. Agreed, this was
largely due to having a function which is very loopy and worked on
really tiny matrices.

The algorithm used was the same in both cases - the speedup was from
cutting out the interpreter.

> > Since I inherited some Matlab code, I am using octave - it
> > makes great glue for trying things out, but I resort to C/C++
> > when I hit bottlenecks.
> >
> > Numpy / Scipy have been suggested as an alternative. (For the
> > glue).
> 
> Py = python?  -- the same interpreter issue as octave?

Indeed, py=python, although that has some advantage in that it
pre-compiles for loading speed. I'm not sure if its byte-code is faster
or not.

Octave does seem to either pre-compile / parse, or cache functions it is
using. Editing a file called from a program loop already running doesn't
take effect until after the run completes.

Matlab reportedly has the edge on loops because it JIT-compiles the
code. I'm not sure how that compares to Python or octave.

I think the point is that glue can be written in an interpreted
language, but certain program loops ought to be written in a compiled
language. No reason why they can't use the internal maths libraries
though.


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user