From: Tatsuro MATSUOKA <matsuoka AT mol DOT nagoya-u DOT ac DOT jp>
To: cygwin AT cygwin DOT com
Cc: matsuoka AT nuce DOT nagoya-u DOT ac DOT jp
Date: Wed, 5 Sep 2007 08:03:21 +0900
Subject: Slowness problem due to  sjlj-exceptions for Octave
Message-Id: <20070905080321.29259AB0.matsuoka@mol.nagoya-u.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Dear sirs

I'm Tatsuro MATSUOKA.
This is the first time to post cygwin-app ML.

I'm now using cygwin for octave, gnuplot and shell command etc.
For the Octave society, it is very famous that building octave 
current standard gcc slows the octave
because the cygwin treats the silj-exceptions very slowly. 
I am purchasing the fast octave on cygwin and now trying to buid 
octave with GCC Ver. 4 and GCC Ver. 3
but built with '--disable-sjlj-exceptions'.The latter trial was 
partly successful. There remains bugs
but works well for most cases.  I am now distributing the octave 
binary built with the GCC configured
with '--disable-sjlj-exceptions'.

The URL is here
http://www.geocities.jp/tmacchant/

GCC on cygwin is updated to 3.4.4-3. That is good for most cases.
I can build the stable Octave with it unlkie GCC 3.4.4-2 or 3.4.4-1.
However slowness of Octave due to sjlj-exceptions still exits as the 
mail copy that was posted
octave-maintainers ML. (That was placed at the end of the this mail.)

In the mail JWE (Prof. John W. Eaton's) comments is written.

I do not entirely agree with his opinion, but I also have a question 
on sjlj-problem on cygwin.
This problem has been famous for a long time in the Octave society. I 
suppose it has been also
disscussed in cygwin ML.  My question is why the cygwin uses the slow 
sjlj exceptions instead of
dwarf2 which was used in old cygwin at the time gcc-3.2 was used.
Recetly the Octave can be built with the mingw. The mingw GCC also 
uses sjlj exceptions but the
slowness problem never be occured.  
I wonder why the sjlj exceptions slows the octave on cygwin.  In 
other platforms including mingw, such
phenomea does not happen.  

I would like to use normally prepared GCC for the octave building.
If the slowness proglem is solved, I can contribute the octave 2.9.13 
to be in the cygwin package.

Pherhaps this problem is quite difficult to solve but it should be 
solved for the cygwin system.

Tatsuro MATSUOKA


*****************************************
The mail posted to the octave-maintainers ML
*******
Hello

Previously jwe wrote:

***********************
http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-August/
003745.html

Given that Cygwin has its own packaging and distribution
system, perhaps the Cygwin binary should be dropped from
the Octave Forge site?  Doesn't it just cause trouble to
have a Cygwin binary that is separate from the Cygwin
package system?  I think that is especially true if the
separate binary is not even compiled with the normal
Cygwin compiler.  I think it would be much better to work
with the Cygwin people and find a way to fix the GCC
problems on Cygwin systems.  If that can't be done, then
maybe it's time to give up on Cygwin (at least as far as
Octave is concerned).  I don't see why that would be a
problem if we have a native Windows binary that works
better anyway.
*************************

I have building a binary of octave 2.9.13 by gcc-3.4.4-3
binary that was distrubuted in cygwin package.

Using Oregonator ODE (source was placed at the end of the
mail), we compare the solving time

octave 2.9.13 built with  gcc-3.4.4-3 in cygwin package 
octave:1> testOregoB
ans =  9.2500

octave 2.1.73 binary in cygwin package
octave:1> testOregoB
ans = 7.0930

my testing binary built specially confgiured gcc.
octave:1> testOregoB
ans =  2.7030          

To tell the truth I have not yet tested the speed of
octave built by normaly prepared gcc-3.4.4-3

For the gcc-3.4.4-3, the slowness problem concerning sjlj
exceptions has not been solved.  I do not know reason why.
 

Anyway I will throw the problem to the cygwin ML. 

The cygwin is useful tool for me.  I cannot give up easily
for the possibilty the octave on cygwin.

At first I have to take part in the Cygwin ML.^^;
 
Sincerely,

Tatsuro Matsuoka

testOregoB.m
******************************
clear;
function dx = oregonator_m (x, t)
 dx=zeros (3, 1);
 dx(1)=77.27*(x(2)-x(1)*x(2)+ x(1)-8.375e-06*x(1)^2);
 dx(2)=(x(3)-x(1)*x(2)-x(2))/77.27;
 dx(3)=0.161*(x(1)-x(3));
end

% The test of `oregonator'.
x0 = [ 4; 1.1; 4 ];
%t = [0, logspace (-1, log10(303), 150), logspace
(log10(304), log10(500), 150)];
%t=linspace(0,500,1000);
t=0:0.5:500;
ts=cputime();
y = lsode ('oregonator_m', x0, t);
cputime()-ts
plot (t',y(:,1),"",t',y(:,2),"",t',y(:,3));
 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/