| Deutsch English Français Italiano |
|
<cfdc79a2dcf70e18792093605f27ef67@www.novabbs.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Chipsandcheese article on the CDC6600
Date: Thu, 25 Jul 2024 17:22:44 +0000
Organization: Rocksolid Light
Message-ID: <cfdc79a2dcf70e18792093605f27ef67@www.novabbs.org>
References: <v7fss8$3f712$1@dont-email.me> <v7k0gm$8pms$13@dont-email.me> <a11cff7fe912529a0a7962163afe43d8@www.novabbs.org> <v7k7ok$a7tn$5@dont-email.me> <lg6gtgFlcf1U1@mid.individual.net> <20240722130827.00004fea@yahoo.com> <2024Jul22.145235@mips.complang.tuwien.ac.at> <CCunO.76231$oGQf.17922@fx10.iad> <v7n2pg$t929$7@dont-email.me> <p6OnO.164803$SLqf.57968@fx15.iad> <v7ph70$1dsq8$6@dont-email.me> <Ge7oO.153178$sE%9.112738@fx14.iad> <v7s3n9$1uqcm$5@dont-email.me> <2024Jul25.125916@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="334058"; mail-complaints-to="usenet@i2pn2.org";
posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$1fMaej1P4SjIY3phbPFzZOHiryyJBdEp5s8Hf2YDk6/u4u7HMBaka
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3224
Lines: 40
On Thu, 25 Jul 2024 10:59:16 +0000, Anton Ertl wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Wed, 24 Jul 2024 13:22:46 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>>I was wondering how those code patches would
>>>>impact on shared code.
>>>
>>> Global branch prediction, of course.
>>
>>But the characteristics of a program run in one thread/process might not
>>match those in another.
>
> They might not, or they might. When the hardware branch predictor
> researchers looked into it, they found that there is more synergy than
> interference. Consequently, they did not take measures to avoid
> sharing. And for the approach of patching the hints in the code, the
> results of sharing will be beneficial on average, too, because the
> only difference from the 2-bit/branch predictor is that the latter is
> in microarchitectural state instead of in the code.
>
> Now somebody will point out that sharing makes it possible for an
> attacker to train branch predictors in one process to attack a
> different process through Spectre and friends. While preventing
> sharing would close that, it does not close training the predictors in
> the same thread.
Not allowing a dependent AGEN to happen when the first AGEN takes
a fault ALSO prevents SPectré like attacks {Whether the crack is
opened up by the BP, IBP, or any other predictor.} Then not modifying
any cache prior to instruction retirement cements the door closed.
>
> Closing Spectre through invisible speculation (several papers exist
> about that) makes it irrelevant (for Spectre) whether the predictors
> are shared or not. Of course, for invisible speculation the permanent
> branch predictors must not be updated speculatively, but that's
> probably better anyway.
>
> - anton