From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ef051e30307e2ff9
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Performance issue
Date: 1996/04/03
Message-ID: <dewar.828579988@schonberg>#1/1
X-Deja-AN: 145728041
references: <4xrau69js6.fsf@leibniz.enst-bretagne.fr>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-04-03T00:00:00+00:00
List-Id: <comp.lang.ada>

Laurent said

"--  Simple test to measure the speed improvement between GNAT 3.03 and GNAT
--  3.04 for "zero cost exception handling" (no more setjmps).
"

That's not quite right, we do not yet have true zero cost exception 
handling. What we *did* do is to eliminate the use of the standard
setjmp/longjmp, and replace it with an inernal implementation of
these primitives.

The gain will vary from machine to machine. On some machines there will
be very little gain, but on the Sparc the gain is huge. The Sun folks
seem to think that they have to do a system call (gasp!!!) to do a
setjmp, and in fact this is quite unnecessry, as this fix shows.

We still intend to do true zero cost exception handling in the future
(this is hard to do in a target independent manner), but meanwhile,
at least GNAT 3.04 eliminates the quite ludicrous overhead of defining
exception handlers on SunOS and Solaris.