[Top][All Lists]

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

Re: Divergence from Solving functional nonlinear equation

From: Jaroslav Hajek
Subject: Re: Divergence from Solving functional nonlinear equation
Date: Tue, 29 Dec 2009 05:37:00 +0100

On Tue, Dec 29, 2009 at 12:42 AM, Jason Martin
<address@hidden> wrote:
> Thomas,
> I don't have a slow system, and I don't fully understand Octave yet so
> please bear with me as I go through this.  I am running on windows 7
> professional x64 with 4 Gbs RAM and an AMD Turon II CPU.  If I were to
> following this post,
> and self compile Octave I am suspecting that my delay issues will be taken
> care of.  Please correct me if I am wrong.
> Using your m-file and octave 3.2.3|gnuplot 4.2 I get:
>> spdtst
> Elapsed time is 7.92482 seconds.
> octave-3.2.3.exe:15:C:\octave\3.2.3_gcc-4.4.0\matlab
> Whereas if I use backend("fltk") instead of gnuplot I get:
>> spdtst
> Elapsed time is 1.3416 seconds.
> octave-3.2.3.exe:5:C:\Octave\3.2.3_gcc-4.4.0\matlab
> Now, I know that I can get better performance by making Octave on my system,
> I haven't had time for it.  Also, the complaint was that using a matrix of
> size 100 generated a long wait time.
> I modified the m-file to:
> function vout = spdtst(valmat)
> tic;
> x=linspace(.1,1,160); y=x; [xx,yy]=meshgrid(x,y);
> for a = rand(1,valmat)*2
>   b=1/a;zz=-b*(xx.*yy).^(b-1)+xx.^(b-1)+yy.^(b-1);
>   figure; surf(xx,yy,zz);shading interp;fflush(1);
> end
> toc;
> and called it by spdtst(5).  This resulted in the following times:
> gnuplot:
> octave-3.2.3.exe:9:C:\Octave\3.2.3_gcc-4.4.0\matlab
>> spdtst(5)
> Elapsed time is 12.4465 seconds.
> octave-3.2.3.exe:10:C:\Octave\3.2.3_gcc-4.4.0\matlab
> fltk:
> octave-3.2.3.exe:13:C:\Octave\3.2.3_gcc-4.4.0\matlab
>> spdtst(5)
> Elapsed time is 1.44106 seconds.
> octave-3.2.3.exe:14:C:\Octave\3.2.3_gcc-4.4.0\matlab
> *note that the gnuplot version takes almost twice as long as the hard coded
> version of the same m-file.
> for a 25 element matrix:
>> backend("fltk")
> octave-3.2.3.exe:18:C:\Octave\3.2.3_gcc-4.4.0\matlab
>> spdtst(25)
> Elapsed time is 6.64428 seconds.
> octave-3.2.3.exe:19:C:\Octave\3.2.3_gcc-4.4.0\matlab
>> backend("gnuplot")
> octave-3.2.3.exe:20:C:\Octave\3.2.3_gcc-4.4.0\matlab
>> spdtst(25)
> Elapsed time is 79.4634 seconds.
> octave-3.2.3.exe:21:C:\Octave\3.2.3_gcc-4.4.0\matlab
> For a small number of points, I don't think that it matters which version
> you use. For a large number of values however, it looks like fltk is faster,
> at least on my system.  I also didn't add in the time it took to actually
> draw each graph using the different backends.  FLTK was almost
> instantaneous, whild GNUPLOT was slow going.  It might be due to my graphics
> card, I am not sure.
> Jason

Hi Jason,

the inherent problem with the Gnuplot backend is that the data need to
be sent to another process through a pipe.
Just for the record, using your spdtst on Core 2 Duo @1.83GHz Ubuntu
9.04, spdtst(25) took about 5 seconds with FLTK and 10 seconds with
Gnuplot, i.e. just 1/2 ratio. I think pipes are slower on Windows,
that may account for the difference. The FLTK backend doesn't need
interprocess communication.

Compiling newest Octave will bring you a lot of benefits, but I'm
afraid that you won't see much (if any) improvement in the
Octave->Gnuplot communication speed; I don't think there were any
relevant changes to that part since 3.2.x. It is now clear that FLTK
is the future; the question of course is how long will it take until
it becomes the standard backend.

RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic

reply via email to

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