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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,904e84d5dc020db1
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
X-Received: by 10.224.208.9 with SMTP id ga9mr2269420qab.8.1360919478754;
        Fri, 15 Feb 2013 01:11:18 -0800 (PST)
X-Received: by 10.49.58.167 with SMTP id s7mr55024qeq.5.1360919478739; Fri, 15
 Feb 2013 01:11:18 -0800 (PST)
Path: 
 k2ni33058qap.0!nntp.google.com!t1no1146631qaz.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 15 Feb 2013 01:11:18 -0800 (PST)
In-Reply-To: <e6c99c16-e511-463f-a842-926f9b5be43b@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=89.159.206.116;
 posting-account=Iggr9woAAAAgws9p-w0sNB_7y6hLoOxg
NNTP-Posting-Host: 89.159.206.116
References: <947b0951-54e4-4a4d-bd26-760eb66390c3@googlegroups.com>
 <bf027023-8b59-4d12-a077-d2e757a5a58d@googlegroups.com>
 <wcchale5zpm.fsf@shell01.TheWorld.com>
 <e6c99c16-e511-463f-a842-926f9b5be43b@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <96a91f86-46af-445c-82a4-0fc7ac7e74b7@googlegroups.com>
Subject: Re: Question about concurrent access to array
From: "cjpsimon@gmail.com" <cjpsimon@gmail.com>
Injection-Date: Fri, 15 Feb 2013 09:11:18 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 2013-02-15T01:11:18-08:00
List-Id: <comp.lang.ada>

Le vendredi 15 f=E9vrier 2013 00:31:59 UTC+1, Adam Beneschan a =E9crit=A0:
> On Thursday, February 14, 2013 1:53:57 PM UTC-8, Robert A Duff wrote:
>=20
>=20
>=20
> > >...Otherwise
>=20
> > > there's the risk that two consecutive array elements that "belong" to
>=20
> > > different tasks might share part of a "word" (or something), and the
>=20
> > > code to write into an element might involve reading the entire word,
>=20
> > > modifying part of the word, then writing it back.
>=20
> >=20

Data locality  is the most important parameter to consider for good speedup=
.
Sometimes it is preferable that each task works on a copy of the data (in t=
he stack, for example) in order to improve their affinity with the processo=
r and avoid false sharing in the cache.=20
It depends on the hardware configuration (multi-processor vs. mulit-core, s=
hared cache or not, cache levels) and volume calculation to be performed on=
 each data.

>=20
> > That would be incorrect code generation, assuming there's no Pack
>=20
> > or Component_Size clause.
>=20
>=20
>=20
> You're right.  I missed the clause in 9.10 that specifies that.
>=20
>=20
>=20
>                                 -- Adam