RE: Fwd: [Bug c++/14563] octave built under Cygwin very slow]

[Paul Billings]

I can confirm the benefits of ATLAS and FFTW as well, which is what prompted
me to build octave in the first place.  I was thinking that a non-sjlj
compiler would improve these as well as octave, but I just realized that
they are both in C.  Duh!  (which doesn't have exceptions for those as slow
as me...)

Much of my code "modifies" existing arrays, but that winds up being
implemented with allocations.  For example:
  a = comp_newval(a);  % a typically 256x256 or more

The pass-by-value semantics will require a lot of allocations -- just about
every assignment -- so I am still hopeful that a non-sjlj compiler would
show a pretty big improvement.  I realize that the above is quickly assigned
via reference counting, but the answer buffer had to be allocated inside the
function.

Paul


> -----Original Message-----
> From: James R. Phillips [mailto:address@hidden
> Sent: Tuesday, August 09, 2005 10:26 AM
>
> --- Paul Billingswrote:
>
> > I had no trouble building octave 2.1.71 with gcc3.4.4.
> Unfortunately, it
> > does not bring up a command prompt (or any of the initial text
> output) --
> > just hangs with CPU usage 0% and ctrl-c doesn't work.  I haven't traced
> > through to see what it's waiting for.  Since my real desire is
> octave speed
> > and from other negative comments I've seen about that version,
> I don't think
> > I will pursue the gcc3.4.4 route.
> >
> > I started to build gcc3.3.3 with --disable-sjlj-exceptions, but
> having never
> > done it before, I was a bit overwhelmed by what seemed to be required.
> >
> > Paul
>
> Your experience with gcc3.4.4 exactly mirrors mine.
>
> The gcc bug referred to in the thread title is documented at:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
>
> The bug was opened based on a regression of gcc 3.3 results vs
> gcc 3.2 results.
>  It was never closed for gcc 3.3, and remains open for gcc 3.4 on
> cygwin/mingw.
>
> Based on the information in the bug database, it appears that a
> faster octave
> on cygwin might result from building octave with a custom
> compiler on cygwin,
> using the modification you are suggesting.  I would have to say
> the evidence in
> the bug database is stale, even wrt gcc 3.3, so this would need
> verification.
>
> I have plenty of fresh and solid evidence, however, to support
> the value of
> building optimized atlas libraries to speed up octave.  The cygwin lapack
> source package supports this, with instructions provided in the
> source tree.
> Depending on your application, this might provide more speed-up than a
> customized compiler.  Also, (speculation alert) preallocating
> arrays in your
> m-file coding might avoid repetitive calls in octave to
> new/delete, which are
> apparently a large part of the compiler problem.
>
> To answer jwe's question, Corrina Vinschen indicates in the
> cygwin thread that
> the cygwin dll is built with exceptions disabled, so the sjlj
> compiler flag
> wouldn't make any difference in the way the cygwin library works.