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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Paul Billings
I have read as much as this thread as I can, including all the traffic on
the gcc bugzilla report.  I gather that there are two issues, possibly
related: 1) SJLJ exceptions and 2) allocations w/ new are very slow.  My
question is do these issues still exist in the cygwin-distribution of gcc
3.4.4 (where SJLJ is enabled)?  Is the problem present in the currently
distributed octave executable in cygwin?

Paul

$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with:
/gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --
exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib -
-man
dir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,
f77,
java,objc --enable-nls --without-included-gettext --enable-version-specific-
runt
ime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib -
-ena
ble-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-
gc=b
oehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchro
niza
tion --enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

Reply | Threaded
Open this post in threaded view
|

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

James R. Phillips-2


--- Paul Billings  wrote:

> I have read as much as this thread as I can, including all the traffic on
> the gcc bugzilla report. ...  Is the problem present in the currently
> distributed octave executable in cygwin?
>
> Paul
>

There is bad news, and there is good news.  The good news is that octave on
cygwin is currently built with gcc3.3, which doesn't have this bug.  The bad
news is that this is done because the problems with building octave on cygwin
with gcc3.4 are so severe that the build hangs before producing its first user
prompt.

I build octave on cygwin so I can use it myself, and it is pretty speedy,
particularly if you install lapack source and build an optimized blas library.

Feel free to try it, and post questions to [hidden email]

Jim Phillips
octave cygwin maintainer


Reply | Threaded
Open this post in threaded view
|

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

Paul Thomas-10
In reply to this post by Paul Billings
Paul,

>I have read as much as this thread as I can, including all the traffic on
>the gcc bugzilla report.  I gather that there are two issues, possibly
>related: 1) SJLJ exceptions and 2) allocations w/ new are very slow.  My
>question is do these issues still exist in the cygwin-distribution of gcc
>3.4.4 (where SJLJ is enabled)?  Is the problem present in the currently
>distributed octave executable in cygwin?
>  
>

The two issues are related, as the correspondence in the PR shows.  I
believe that other features in C++ are slowed up by SJLJ exceptions too
(vtable access?) because I could never make the timing figures or the
profiling come close to adding up.

I only build octave with a dwarf2-enabled gcc-3.2 and have been sticking
to an ancient version of Cygwin, where memory limits are not an issue.
 I therefore cannot answer your questions.  To judge by the
correspondence on the octave lists, I would think that the answers to
both would be "yes".

Best wishes

Paul Thomas


Reply | Threaded
Open this post in threaded view
|

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

Andy Adler
In reply to this post by James R. Phillips-2
On Fri, 5 Aug 2005, James R. Phillips wrote:

> --- Paul Billings  wrote:
>
> > I have read as much as this thread as I can, including all the traffic on
> > the gcc bugzilla report. ...  Is the problem present in the currently
> > distributed octave executable in cygwin?
>
> There is bad news, and there is good news.  The good news is that octave on
> cygwin is currently built with gcc3.3, which doesn't have this bug.  The bad
> news is that this is done because the problems with building octave on cygwin
> with gcc3.4 are so severe that the build hangs before producing its first user
> prompt.
>
> I build octave on cygwin so I can use it myself, and it is pretty speedy,
> particularly if you install lapack source and build an optimized blas library.

Gcc3.3, as supplied by cygwin, uses SJLJ. Thus James' octave version
will have this issue.

I have two comments:
  - I'm also seeing the compile problems with gcc3.4; however Paul
    Soderlind sent me a note that he had no problem with gcc3.4.
    Would anyone else like to comment on their experiences with
    octave/cygwin/gcc3.4?

  - Has anyone tried to compile octave with a gcc version compiled
    with --disable-sjlj-exceptions?

--
Andy Adler

Reply | Threaded
Open this post in threaded view
|

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

Shai Ayal-2
I had problems with gcc 3.4.1 on cygwin. It's all documented in this thread

http://www.octave.org/octave-lists/archive/bug-octave.2005/msg00269.html

Shai

On 8/6/05, Andy Adler <[hidden email]> wrote:

> On Fri, 5 Aug 2005, James R. Phillips wrote:
> > --- Paul Billings  wrote:
> >
> > > I have read as much as this thread as I can, including all the traffic on
> > > the gcc bugzilla report. ...  Is the problem present in the currently
> > > distributed octave executable in cygwin?
> >
> > There is bad news, and there is good news.  The good news is that octave on
> > cygwin is currently built with gcc3.3, which doesn't have this bug.  The bad
> > news is that this is done because the problems with building octave on cygwin
> > with gcc3.4 are so severe that the build hangs before producing its first user
> > prompt.
> >
> > I build octave on cygwin so I can use it myself, and it is pretty speedy,
> > particularly if you install lapack source and build an optimized blas library.
>
> Gcc3.3, as supplied by cygwin, uses SJLJ. Thus James' octave version
> will have this issue.
>
> I have two comments:
>   - I'm also seeing the compile problems with gcc3.4; however Paul
>     Soderlind sent me a note that he had no problem with gcc3.4.
>     Would anyone else like to comment on their experiences with
>     octave/cygwin/gcc3.4?
>
>   - Has anyone tried to compile octave with a gcc version compiled
>     with --disable-sjlj-exceptions?
>
> --
> Andy Adler
>
>

Reply | Threaded
Open this post in threaded view
|

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

Paul Thomas-10
In reply to this post by Andy Adler
Andy,

>  - Has anyone tried to compile octave with a gcc version compiled
>    with --disable-sjlj-exceptions?
>
>  
>

Yes, with gcc-3.4.  Not very hard, though.  Something was a rather
broken (readline?) and large quantities of symbols were  emitted to the
console at start-up.  Once it settled down, though, it ran as quickly as
with the samizdat gcc-3.2.

Paul T

Reply | Threaded
Open this post in threaded view
|

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

James R. Phillips-2
--- Paul Thomas  wrote:

> Andy,
>
> >  - Has anyone tried to compile octave with a gcc version compiled
> >    with --disable-sjlj-exceptions?
> >
> >  
> >
>
> Yes, with gcc-3.4.  Not very hard, though.  Something was a rather
> broken (readline?) and large quantities of symbols were  emitted to the
> console at start-up.  Once it settled down, though, it ran as quickly as
> with the samizdat gcc-3.2.
>
> Paul T

I am completely unfamiliar with the original bug report. I would suggest that
those most interested in the issue try to replicate the bug with the current
cygwin octave release, which is compiled with gcc 3.3.3.  To experiment with
the above-defined flag, download the cygwin octave source, and modify the build
script to incorporate the compiler flag. I do suggest staying with gcc 3.3 for
this experiment, as use of gcc 3.4 will almost certainly break the build, and
bring in many other issues.

If solid evidence of a bug develops, which bug could be corrected by
modification of the build process, I will be more than happy to re-release the
package to the cygwin project.  Before I spend time on this effort however, I
need to see evidence that it will produce a measureably faster or more reliable
package.

I would like very much to see cygwin begin the porting process on the gcc 4.0
compiler, which Debian and other linux distributions are transitioning to right
now.  Anecdotal evidence suggests (to me) that gcc 3.4 may never be completely
solid for building C++ applications, even on linux.  However, there is no
cygwin mailing list activity indicating this interest is shared by the cygwin
gcc maintainer.

James R. Phillips
cygwin octave maintainer

Reply | Threaded
Open this post in threaded view
|

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

Shai Ayal-2
I think the problem is that the --disable-sjlj-exceptions is not a
compiler flag, rather it is a flag you give when you compile the
compiler. Thus to test it one would have to get the souces of GCC
3.3.3 and compile it on cygwin with the above flag, than use this
compiler to compile octave. This is a very time consuming effort since
compilation on cygwin are painfully slow -- on my P4 with winXP it
take several hours to compile octave -- I don't know exactly how many
since I always just leave it overnight

Shai

On 8/9/05, James R. Phillips <[hidden email]> wrote:

> --- Paul Thomas  wrote:
>
> > Andy,
> >
> > >  - Has anyone tried to compile octave with a gcc version compiled
> > >    with --disable-sjlj-exceptions?
> > >
> > >
> > >
> >
> > Yes, with gcc-3.4.  Not very hard, though.  Something was a rather
> > broken (readline?) and large quantities of symbols were  emitted to the
> > console at start-up.  Once it settled down, though, it ran as quickly as
> > with the samizdat gcc-3.2.
> >
> > Paul T
>
> I am completely unfamiliar with the original bug report. I would suggest that
> those most interested in the issue try to replicate the bug with the current
> cygwin octave release, which is compiled with gcc 3.3.3.  To experiment with
> the above-defined flag, download the cygwin octave source, and modify the build
> script to incorporate the compiler flag. I do suggest staying with gcc 3.3 for
> this experiment, as use of gcc 3.4 will almost certainly break the build, and
> bring in many other issues.
>
> If solid evidence of a bug develops, which bug could be corrected by
> modification of the build process, I will be more than happy to re-release the
> package to the cygwin project.  Before I spend time on this effort however, I
> need to see evidence that it will produce a measureably faster or more reliable
> package.
>
> I would like very much to see cygwin begin the porting process on the gcc 4.0
> compiler, which Debian and other linux distributions are transitioning to right
> now.  Anecdotal evidence suggests (to me) that gcc 3.4 may never be completely
> solid for building C++ applications, even on linux.  However, there is no
> cygwin mailing list activity indicating this interest is shared by the cygwin
> gcc maintainer.
>
> James R. Phillips
> cygwin octave maintainer
>
>

Reply | Threaded
Open this post in threaded view
|

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

John W. Eaton-6
On  9-Aug-2005, Shai Ayal wrote:

| I think the problem is that the --disable-sjlj-exceptions is not a
| compiler flag, rather it is a flag you give when you compile the
| compiler. Thus to test it one would have to get the souces of GCC
| 3.3.3 and compile it on cygwin with the above flag, than use this
| compiler to compile octave. This is a very time consuming effort since
| compilation on cygwin are painfully slow -- on my P4 with winXP it
| take several hours to compile octave -- I don't know exactly how many
| since I always just leave it overnight

Does the Cygwin DLL also use exception handling?  If so, I suspect
that you would need to compile it with the same compiler so that the
exception handling model matches the one used by applications that
depend on the Cygwin DLL.  But I'm not sure of the details, so that
might not be required.

jwe

Reply | Threaded
Open this post in threaded view
|

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

Paul Billings
In reply to this post by Andy Adler
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


> -----Original Message-----
> From: Andy Adler [mailto:[hidden email]]
> Sent: Saturday, August 06, 2005 2:31 AM
> I have two comments:
>   - I'm also seeing the compile problems with gcc3.4; however Paul
>     Soderlind sent me a note that he had no problem with gcc3.4.
>     Would anyone else like to comment on their experiences with
>     octave/cygwin/gcc3.4?
>
>   - Has anyone tried to compile octave with a gcc version compiled
>     with --disable-sjlj-exceptions?
>
> --
> Andy Adler

Reply | Threaded
Open this post in threaded view
|

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

James R. Phillips-2


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

Reply | Threaded
Open this post in threaded view
|

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

Bill Denney
On Tue, 9 Aug 2005, James R. Phillips wrote:

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

I'm 99% sure that this helps in both octave and matlab.  It doesn't have
to reallocate memory which becomes more difficult when the allocation is
trying to keep memory from being fragmented and it has to search for a
larger block of space free.

I've actually had code in matlab that would run out of memory unless I
pre-allocated one particularly large array (it was using about 512M of 1G
of my RAM).

Bill

--
"Instead of torturing the on-air talent, torture kittens. While not
eliminating pledge drives, this would significantly shorten their length.
'Okay, we have 10 callers on the line. It looks like Fluffy gets a little
breather.'"  -- NPR Fund-Raising Alternative (www.netfunny.com)

Reply | Threaded
Open this post in threaded view
|

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

Paul Billings
In reply to this post by James R. Phillips-2
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:[hidden email]]
> 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.