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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,4e5770c49b971630
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!postnews.google.com!w24g2000yqb.googlegroups.com!not-for-mail
From: Cyrille <comar@eu.adacore.com>
Newsgroups: comp.lang.ada
Subject: Re: High-Integrity OO and controlled types
Date: Thu, 5 May 2011 03:58:26 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <d718cefa-1bd2-4dd2-95e9-0139b5c9fdee@w24g2000yqb.googlegroups.com>
References: <d8204576-14ff-41a4-b850-ace9c15872d4@v8g2000yqb.googlegroups.com>
 <f6e72476-0dca-4ab8-bfdf-94a0ddf7a7dc@j26g2000yqa.googlegroups.com>
 <4dbfe6cc$0$7664$9b4e6d93@newsspool1.arcor-online.net>
 <1in9ypl17vu1t$.1shivr91x8zw6.dlg@40tude.net>
 <4dc01dca$0$6885$9b4e6d93@newsspool2.arcor-online.net>
 <1ds39akl3dbii$.mlyj7piip5o3.dlg@40tude.net>
 <4dc112cf$0$6772$9b4e6d93@newsspool3.arcor-online.net>
 <gbwm0iuo4ed4$.1e5m2ye4kvqqj$.dlg@40tude.net>
 <4dc166bd$0$6973$9b4e6d93@newsspool4.arcor-online.net>
 <1ligthpgu6ogv$.dquevy2bn4tw$.dlg@40tude.net>
 <4dc16ff7$0$6985$9b4e6d93@newsspool4.arcor-online.net>
 <1wtqj5ym270iw.11hopx6y7w1co$.dlg@40tude.net>
 <4dc187af$0$6991$9b4e6d93@newsspool4.arcor-online.net>
 <15h978k5yukhl.kga2durs3cjl.dlg@40tude.net>
 <1356f246-a883-4b9b-92f5-7426cc945084@o26g2000vby.googlegroups.com>
NNTP-Posting-Host: 194.98.77.125
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1304593106 13601 127.0.0.1 (5 May 2011 10:58:26
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 5 May 2011 10:58:26 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: w24g2000yqb.googlegroups.com; posting-host=194.98.77.125;
 posting-account=bNhsVwoAAAB6XmNPWgYcbUm6npIwL2C4
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.16)
 Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:20139
Date: 2011-05-05T03:58:26-07:00
List-Id: <comp.lang.ada>

On May 5, 9:13=A0am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On May 4, 10:16=A0pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > Performance optimization is a different angle. There is no obvious reas=
on
> > why following or ignoring Ravenscar's restrictions should result in eit=
her
> > faster or slower program.
>
> For one thing, with Ravenscar restrictions the compiler need not
> generate abort deferral related code, because without ATC it would be
> a dead code anyway. This might reduce the size of generated code and
> consequently make it faster.
> I have no hard data on what are the actual gains, however.

not mentioning that the ravenscar profile has been designed, among
other things, to allow ultra-efficient tasking runtimes (compared to
those having to support all of the Ada tasking model). For instance,
assuming a single core config, one can implement protect objects
without any locking mechanism... and such implementations exist in
several Ada technologies as far as I know...