public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "paulthomas2 at wanadoo dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/14563] octave built under Cygwin very slow
Date: Thu, 25 Mar 2004 16:41:00 -0000	[thread overview]
Message-ID: <20040325164123.6396.qmail@sources.redhat.com> (raw)
In-Reply-To: <20040312233606.14563.paulthomas2@wanadoo.fr>


------- Additional Comments From paulthomas2 at wanadoo dot fr  2004-03-25 16:41 -------
Subject: Re:  octave built under Cygwin very slow

Hey come on!  For the "bug database dude" your grown-up talk is 
impressive enough to a toddler like me. Anyway,  I thank you for the 
explanation of setjmp/longjmp - it has been on my list of things to gen 
up on for a while.  It crosses my mind in discussing this that it is a 
bit aberrant to keep doing this within a loop of interpreted code, isn't it?

Anyhow, you will have seen Ben's message about trying a build with 
-fno-exceptions; as I suspected it did not get past quit.h.  I will put 
the question about the timing of the introduction of exceptions onto the 
list.  This perhaps will be the best route to settle the question as to 
whether or not sjlj is the root cause of the slow-down.

Thanks again

Paul Thomas

bangerth at dealii dot org wrote:

>------- Additional Comments From bangerth at dealii dot org  2004-03-25 14:36 -------
>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. 
> 
>Now back to the question how we can figure out what the problem is: if 
>using -fno-exceptions doesn't work, is there a possibility you repeat 
>your experiments with an octave version prior to the introduction of 
>exceptions? 
> 
>W. 
>
>  
>




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563


  parent reply	other threads:[~2004-03-25 16:41 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12 23:36 [Bug c++/14563] New: " paulthomas2 at wanadoo dot fr
2004-03-13  7:24 ` [Bug c++/14563] " pinskia at gcc dot gnu dot org
2004-03-13  8:06 ` paulthomas2 at wanadoo dot fr
2004-03-14 20:33 ` bangerth at dealii dot org
2004-03-24  9:52 ` paulthomas2 at wanadoo dot fr
2004-03-24 15:57 ` bangerth at dealii dot org
2004-03-24 16:38 ` paulthomas2 at wanadoo dot fr
2004-03-24 17:03 ` bangerth at dealii dot org
2004-03-24 21:07 ` Ben dot Diedrich at noaa dot gov
2004-03-24 22:58 ` dannysmith at users dot sourceforge dot net
2004-03-25  6:40 ` paulthomas2 at wanadoo dot fr
2004-03-25 13:43 ` bangerth at dealii dot org
2004-03-25 14:16 ` Ben dot Diedrich at noaa dot gov
2004-03-25 14:17 ` paulthomas2 at wanadoo dot fr
2004-03-25 14:26 ` paulthomas2 at wanadoo dot fr
2004-03-25 14:37 ` bangerth at dealii dot org
2004-03-25 15:37 ` Ben dot Diedrich at noaa dot gov
2004-03-25 16:41 ` paulthomas2 at wanadoo dot fr [this message]
2004-03-28 21:19 ` paulthomas2 at wanadoo dot fr
2004-03-28 22:28 ` pkienzle at users dot sf dot net
2004-03-31  0:21 ` paulthomas2 at wanadoo dot fr
2004-04-02 17:43 ` paulthomas2 at wanadoo dot fr
2004-04-02 19:55 ` bangerth at dealii dot org
2004-04-02 20:35 ` dannysmith at users dot sourceforge dot net
2004-04-02 20:41 ` pcarlini at suse dot de
2004-04-02 20:44 ` bangerth at dealii dot org
2004-04-03  9:10 ` paulthomas2 at wanadoo dot fr
2004-04-03 17:19 ` epanelelytha at kellertimo dot de
2004-04-03 17:54 ` paulthomas2 at wanadoo dot fr
2004-04-03 18:00 ` epanelelytha at kellertimo dot de
2004-04-03 18:24 ` paulthomas2 at wanadoo dot fr
2004-07-12 14:50 ` [Bug libstdc++/14563] new/delete much slower than malloc/free pinskia at gcc dot gnu dot org
2004-07-12 19:21 ` paulthomas2 at wanadoo dot fr
2004-07-12 20:55 ` bangerth at dealii dot org
2004-07-13  4:17 ` paulthomas2 at wanadoo dot fr
2004-07-28  2:50 ` ron_hylton at hotmail dot com
2004-07-28  3:57 ` ron_hylton at hotmail dot com
2004-07-28  6:03 ` [Bug target/14563] " pinskia at gcc dot gnu dot org
2004-07-29  4:23 ` ron_hylton at hotmail dot com
2004-08-08  9:24 ` paulthomas2 at wanadoo dot fr
2004-11-10  8:21 ` [Bug target/14563] [3.3/3.4/4.0 Regression] new/delete much slower than malloc/free because of sjlj exceptions giovannibajo at libero dot it
2004-11-10  8:21 ` giovannibajo at libero dot it
2004-11-10  9:10 ` dannysmith at users dot sourceforge dot net
2004-11-10 12:46 ` [Bug target/14563] " pinskia at gcc dot gnu dot org
2004-11-10 16:20 ` ron_hylton at hotmail dot com
2004-11-10 17:05 ` kjd at duda dot org
2004-11-13 11:03 ` paulthomas2 at wanadoo dot fr
2004-11-14 17:03 ` ken dot duda at gmail dot com
2004-11-14 18:04 ` paulthomas2 at wanadoo dot fr
2004-11-14 22:40 ` ken dot duda at gmail dot com
2005-05-12 14:53 ` pinskia at gcc dot gnu dot org
2005-05-12 14:54 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040325164123.6396.qmail@sources.redhat.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).