[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 Kienzle |
Subject: |
Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow] |
Date: |
Sat, 27 Mar 2004 11:03:30 -0500 |
Octave's signal handlers set a flag saying that octave should quit. The
OCTAVE_QUIT macro tests this flag and throws an exception. For your
needs you don't need to handle Ctrl-C, so skip it:
#define OCTAVE_QUIT do {} while(0)
We don't want to have to modify external libraries to include
OCTAVE_QUIT
so instead we do setjmp around the external code and throw an exception
back to octave if the longjmp is called. This is buried in macros:
BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE
call function
END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE
You should be able to skip these as well:
#define BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1 do {} while(0)
#define BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2 do {} while(0)
#define END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE do {} while(0)
You will need to modify liboctave/misc/quit.cc so that throw is not
used.
The F77_XFCN in libcruft/misc/f77-fcn.h does something similar in
addition
to calling the code. Replace it with something like:
#define F77_XFCN(f,F,args) do { F77_FUNC(F,F) args; } while (0)
When fortran code calls back to octave, the exceptions must be
converted into
longjmp. This is done using:
BEGIN_INTERRUPT_WITH_EXCEPTIONS;
octave code;
END_INTERRUPT_WITH_EXCEPTIONS;
These macros can be ignored for your purposes:
#define BEGIN_INTERRUPT_WITH_EXCEPTIONS do {} while (0)
#define END_INTERRUPT_WITH_EXCEPTIONS do {} while (0)
The only other place where I see try/catch code is in src/toplev.cc.
This
will also have to be modified to eliminate exceptions.
I have no idea whether these changes will actually compile or not, but
assuming they do, you can compare the speed of 3.3 and 3.2 compilers
using them. Do it without profiling so we can see what the real cost of
safe Ctrl-C is.
Paul Kienzle
address@hidden
On Mar 26, 2004, at 12:43 PM, Paul Thomas wrote:
After I followed up John's suggestion of looking through the list
just after the release of 2.139, I realise that I understand nothing
about signal and error handling; this will have been apparent from my
two last messages! I have a weekend of contemplation of such matters
in front of me.....
Paul T
Paul K, I think your suggestion of masking out the sjlj calls is a
good one - I just have to figure out how to go about it.
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.
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
- Re: Profiling Octave, (continued)
[Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Thomas, 2004/03/25
- [Fwd: [Bug c++/14563] octave built under Cygwin very slow], John W. Eaton, 2004/03/25
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Thomas, 2004/03/26
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow],
Paul Kienzle <=
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Thomas, 2004/03/27
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Kienzle, 2004/03/27
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Thomas, 2004/03/28
- Message not available
- Message not available
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Kienzle, 2004/03/28
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Thomas, 2004/03/28
- Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow], Paul Kienzle, 2004/03/28