help-gnucap
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnucap] Linux Distribution


From: al davis
Subject: Re: [Help-gnucap] Linux Distribution
Date: Tue, 18 Dec 2012 23:49:18 -0500
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

On Tuesday 18 December 2012, address@hidden wrote:
> I would like to know if some of you use a real time linux
> distribution  with Gnucap ?
> 
> I was thinking about RTLinux, on the other hand i was
> thinking about  using a Gentoo, do you guys have any idea
> about performance gain and what compilation options to use
> to make Gnucap as fast as possible !

I haven't tried it but I think Orestes is correct.

If you really want "as fast as possible" you could help it by 
carefully choosing the options and simulation parameters.

A few pointers ......

1. Minimize the output ....  Select only the probes you want.

2. For a transient analysis, (bad hangover from spice syntax) 
specify a VERY LARGE step size, but add the option "trace all" 
which prints every data point.  This may seem backwards, but 
gnucap's step control does a good job at determining the best 
stepping.  If you manually specify a step size smaller than 
needed, it will run slower.

3. The stable version 0.35 reads in faster than the snapshot.  
Known problem, known solution, will be fixed.

4. Make sure you set the compile options for speed, in 
particular, asserts off "-DNDEBUG".  The default is to do it 
this way, but check to be sure.  The debug build (asserts and 
trace on) is about 2x slower.

For the future, maybe ....

I have considered using "MPTL" to support multiprocessors.  
There are several spots where it should be a  simple matter of 
substituting a MPTL loop for a for or STL loop.  The code is 
designed with parallel in mind, but I have not had the time to 
follow through.  Two key places .. one is parallel model 
evaluation, the other is to split the matrix into sections and 
solve the sections in parallel.  The split already happens.  
Need to do the rest.  Still, that's at best only a linear 
function of how many processors.  At worst, it might even be 
slower.

http://spc.unige.ch/doku.php?id=mptl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]