Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Another security vulnerability
Date: Thu, 4 Apr 2024 20:57:45 +0000
Organization: Rocksolid Light
Message-ID: <0574ba752b8642130dc751c693b1f86b@www.novabbs.org>
References: <utpoi2$b6to$1@dont-email.me> <uu0kt1$2nr9j$1@dont-email.me> <VpVMN.731075$p%Mb.618266@fx15.iad> <2024Mar27.191411@mips.complang.tuwien.ac.at> <HH_MN.732789$p%Mb.8039@fx15.iad> <5fc6ea8088c0afe8618d2862cbacebab@www.novabbs.org> <TfhNN.110764$_a1e.90012@fx16.iad> <jwvedbmco81.fsf-monnier+comp.arch@gnu.org> <uukcpe$4g83$2@dont-email.me> <561654fafbeb5e542817dbc5f0ee993e@www.novabbs.org> <uumpan$pq1o$1@dont-email.me> <2908eb802c45ff7a998f0cc49d09f67f@www.novabbs.org> <4aEPN.165923$46Te.41285@fx38.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="101646"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$WDTq2v5Qjc36FHn2jvJdDu9aIhOdmExGYnK.K9HV5j4F9HZQMr7tq
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3335
Lines: 62

Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>Thomas Koenig wrote:
>>
>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>> Thomas Koenig wrote:
>>>>
>>>>> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>>>>>> Since each chased pointer starts back at LSQ, the cost is no different
>>>>>>> than an explicit Prefetch instruction, except without (a),(b) and (c)
>>>>>>> having been applied first.
>>>>>>
>>>>>> I thought the important difference is that the decision to prefetch or
>>>>>> not can be done dynamically based on past history.
>>>>
>>>>> Programmers and compilers are notoriously bad at predicting
>>>>> branches (except for error branches), 
>>>>
>>>> Which are always predicted to have no error.
>>
>>There I mean that the programmer wrote the code::
>>
>>      if( no error so far ) 
>>      {
>>          then continue
>>      }
>>      else
>>      {
>>          deal with the error
>>      }
>>
>>Many times, the "deal with the error" code is never even fetched.
>>
>>> On the second or third time, certainly.  Hmmm... given hot/cold
>>> splitting which is fairly standard by now, do branch predictors
>>> take this into account?
>>
>>First we are talking about predicting branches at compile time and
>>the way the programmer writes the source code, not about the dynamic
>>predictions of HW.

> gcc provides a way to "annotate" a condition with the expected
> common result:

> #define likely(x)     __builtin_expect(!!(x), 1)
> #define unlikely(x)   __builtin_expect(!!(x), 0)


>    if (likely(bus_enable.s.enabled)) {
>       do something
>    } else {
>       do something else
>    }

> This will affect the layout of the code (e.g. deferring generation
> of the else clause with the result that it ends up in a different
> cache line or page).

> It's used in the linux kernel, and in certain cpu bound applications.


Thank you for pointing this out.