[Top][All Lists]

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

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

From: James R. Phillips
Subject: RE: Fwd: [Bug c++/14563] octave built under Cygwin very slow]
Date: Tue, 9 Aug 2005 13:25:42 -0700 (PDT)

--- 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:


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.

reply via email to

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