octave-maintainers
[Top][All Lists]
Advanced

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

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


From: Paul Thomas
Subject: Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow]
Date: Fri, 26 Mar 2004 12:52:41 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

John,

Thanks for researching the logs for us. I'll take a look at the 2.1.39, or earlier, source this weekend.

Also, thanks for the suggestion about tracking down the use of quit.h in the time consuming bits of code. I had already started that just before going on the present trip. There is at least one occurrence; from the scribbles in my journal, the chain is

tree_simple_for_command => do_for_loop_once => quit_loop_now => OCTAVE_QUIT

Thus in the profiling tests, OCTAVE_QUIT was getting called 1 million times.

Wolfgang, who is in charge of the gcc bug database, wrote me the following:

"SJLJ stands for "setjmp/longjmp". I'm not an expert in this field (as I know virtually nothing about the gcc interiors anyway, I'm just the bug database dude), but here's the idea: when you call a function that may or may not throw an exception, and the calling function needs to run destructors of local objects in case an exception is thrown, you need to put down the address of the cleanup code somewhere. One way to do this is to set this address via setjmp, and throwing an exception then transfers control to this place via longjmp. This is expensive since you have to call setjmp every time a cleanup is necessary. The other possibility is to use lookup tables that the compiler generates statically, so this is cheap at run-time, but incurs some code overhead. If you generate an exception, you have to somehow look up where to transfer execution. Don't ask me how exactly this works, but it is to my best knowledge how dwarf2 exception unwinding works. Corrections on this topic my more knowledgable people are certainly welcome."


gcc-3.2 uses dwarf2 and gcc-3.3 uses SJLJ. It is interesting that it is _Unwind_SjLj_Register which is coming up as a time consumer in the slow build.

Regards

Paul T


John W. Eaton wrote:

On 25-Mar-2004, Paul Thomas <address@hidden> wrote:

| (i) To try to build octave with -fno-exceptions. Ben Diedrich tried | this but the build did not get past quit.cc.

I don't think it would be easy to do that.  Octave code now assumes
that exception handling works.  When we made the change to use
exceptions to handle the return to the command loop after interrupts,
we decided that it would not be worth the effort of trying to maintain
additional code to support systems that don't do exceptions properly.

| (ii) To build and compare octave-before-exceptions with the two | different gcc's. Does anybody know what version number we should be | looking at?

According to libcruft/ChangeLog, the code for handling exceptions with
interrupts was added around 2002-11-07 (you could check the mailing
list archives around that time to confirm as I think there was some
discussion about it).  According to the src/ChangeLog file, the
version was changed to 2.1.39 on 2002-11-01 and 2.1.40 on 2002-11-20,
so you proably want 2.1.39 or earlier to get a version that doesn't
use exception handling very extensively.

If you think it might be exception handling, then you might also look
at the uses of the macros related to exception handling that are
defined in libcruft/misc/quit.h and see if they now appear in places
that would be executed by code that demonstrates the slowdown.

jwe






reply via email to

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