Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!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: References: <20240722130827.00004fea@yahoo.com> <2024Jul22.145235@mips.complang.tuwien.ac.at> <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 writes: >>On Wed, 24 Jul 2024 13:22:46 GMT, Scott Lurndal wrote: >> >>> Lawrence D'Oliveiro 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