help-octave
[Top][All Lists]
Advanced

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

Re: gnuplot in Octave review


From: Sergei Steshenko
Subject: Re: gnuplot in Octave review
Date: Wed, 11 Feb 2009 07:49:09 -0800 (PST)



--- On Wed, 2/11/09, Jordi Gutiérrez Hermoso <address@hidden> wrote:

> From: Jordi Gutiérrez Hermoso <address@hidden>
> Subject: Re: gnuplot in Octave review
> To: address@hidden
> Cc: address@hidden
> Date: Wednesday, February 11, 2009, 7:04 AM
> 2009/2/11 Sergei Steshenko <address@hidden>:
> > I once had 200+ 'gnuplot' windows created by
> just one 'octave' session,
> > cumulative memory consumption of the session + the
> windows was much more that 4GB (architectural limit of a 32
> bits system), and it was on a
> > 32 bits system.
> 
> I don't understand. Why is it good that the memory
> usage is much more
> than 4 GB? How could it be more than 4 GB on a 32 bit
> system? Wouldn't
> that bring your system to a trash?
> 
> Moreover, why did you have 200 windows open? And why would
> a separate
> process be better to have 200 windows open?
> 
> - Jordi G. H.

Jordi, if you have a 32 bits system, the 4GB limit is _per process_.

I had 8GB of swap in addition to 2GB of physical RAM.

I had 200+ plot windows open because I wanted to see results from a number
of inner loops.

So, in this case the fact that 'gnuplot' is a separate process _did_ help.

Had plotting been a part of 'octave' process, the whole run would have failed 
at 4GB memory consumption.

With separate processes the OS allocates space per process, and since I 
wasn't looking at all the plots simultaneously, the processes of inactive
plot windows were swapped out by the OS almost immediately.

So, even though this conglomerate of processes consumed much more than
4GB, there was even no extensive thrashing - 'octave' was running at 100% 
CPU because it was _the_ active process.

So, again, I think it's a _great_ advantage that currently plotting is
implemented as separate processes.

Regards,
  Sergei.


      



reply via email to

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