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