Re: Another security vulnerability

Liste des GroupesRevenir à c arch 
Sujet : Re: Another security vulnerability
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.arch
Date : 05. Apr 2024, 23:28:59
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <6111de53d996b394a458b86328fcd59f@www.novabbs.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : Rocksolid Light
Stefan Monnier wrote:

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), but ought to be quite good
at predicting prefetches.  If a pointer is loaded, chances are
very high that are it will be dereferenced.

I don't think it's that simple: prefetches only bring the data into L1
cache, so they're only useful if:

- The data is not already in L1.
- The data will be used soon (i.e. before it gets thrown away from the cache).
- The corresponding load doesn't occur right away.

In all other cases, the prefetch will be just wasted work.

It's easy for programmers to "predict" those (dependent) loads which will occur
right away, but those don't really benefit from a prefetch.
E.g. if the dependent load is done 2 cycles later, performing a prefetch
lets you start the memory access 2 cycles early, but since that access
is not in L1 it'll take more than 10 cycles, so shaving
2 cycles off isn't of great benefit.

Given that we're talking about performing a prefetch on the result of
a previous load, and loads tend to already have a fairly high latency
(3-5 cycles), "2 cycles later" really means "5-7 cycles after the
beginning of the load of that pointer".  That can easily translate to 20
instructions later.

My gut feeling is that it's difficult for programmers to predict what
will happen more than 20 instructions further without looking at
detailed profiling.
Difficult becomes impossible when the code has to operate "well" over
a range of implementations. {{With some suitable definition of "well"}}
Consider deciding how far into the future (counting instructions) a
prefetch has to be placed so that the data arrives before use. Then
consider the smallest execution window is 16 instructions and the largest execution window is 300 instructions; and you want the same
code to be semi-optimal on both.

        Stefan

Date Sujet#  Auteur
24 Mar 24 * Another security vulnerability58Stephen Fuld
24 Mar 24 +* Re: Another security vulnerability4MitchAlsup1
25 Mar 24 i+* Re: Another security vulnerability2Stefan Monnier
26 Mar 24 ii`- Re: Another security vulnerability1Michael S
26 Mar 24 i`- Re: Another security vulnerability1Michael S
24 Mar 24 +* Re: Another security vulnerability10Lawrence D'Oliveiro
25 Mar 24 i+- Re: Another security vulnerability1Stefan Monnier
25 Mar 24 i`* Re: Another security vulnerability8Stephen Fuld
25 Mar 24 i `* Re: Another security vulnerability7Lawrence D'Oliveiro
26 Mar 24 i  +* Re: Another security vulnerability5MitchAlsup1
26 Mar 24 i  i`* Re: Another security vulnerability4Lawrence D'Oliveiro
27 Mar 24 i  i `* Re: Another security vulnerability3Stephen Fuld
28 Mar 24 i  i  `* Re: Another security vulnerability2Lawrence D'Oliveiro
28 Mar 24 i  i   `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 i  `- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability18Thomas Koenig
25 Mar 24 i+* Re: Another security vulnerability16Anton Ertl
26 Mar 24 ii+* Re: Another security vulnerability13Lawrence D'Oliveiro
26 Mar 24 iii`* Re: Another security vulnerability12Anton Ertl
5 Jun 24 iii `* Re: Another security vulnerability11MitchAlsup1
5 Jun 24 iii  +* Re: Another security vulnerability9Anton Ertl
11 Jun 24 iii  i`* Re: Another security vulnerability8MitchAlsup1
11 Jun 24 iii  i +* Re: Another security vulnerability6Stephen Fuld
11 Jun 24 iii  i i`* Re: Another security vulnerability5MitchAlsup1
11 Jun 24 iii  i i `* Re: Another security vulnerability4Stephen Fuld
11 Jun 24 iii  i i  `* Re: Another security vulnerability3Terje Mathisen
11 Jun 24 iii  i i   `* SSDs (was: Another security vulnerability)2Stefan Monnier
11 Jun 24 iii  i i    `- Re: SSDs1Chris M. Thomasson
11 Jun 24 iii  i `- Re: Another security vulnerability1MitchAlsup1
11 Jun 24 iii  `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 ii`* Re: Another security vulnerability2Anton Ertl
26 Mar 24 ii `- Re: Another security vulnerability1Anton Ertl
25 Mar 24 i`- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability22Anton Ertl
26 Mar 24 i`* Re: Another security vulnerability21Michael S
27 Mar 24 i `* Re: Another security vulnerability20Thomas Koenig
27 Mar 24 i  +* Re: Another security vulnerability2Thomas Koenig
27 Mar 24 i  i`- Re: Another security vulnerability1Thomas Koenig
27 Mar 24 i  +- Re: Another security vulnerability1Anton Ertl
27 Mar 24 i  `* Re: Another security vulnerability16Anton Ertl
27 Mar 24 i   `* Re: Another security vulnerability15MitchAlsup1
28 Mar 24 i    +* Re: Another security vulnerability4MitchAlsup1
29 Mar 24 i    i`* Re: Another security vulnerability3Paul A. Clayton
29 Mar 24 i    i `* Re: Another security vulnerability2Paul A. Clayton
30 Mar 24 i    i  `- Re: Another security vulnerability1MitchAlsup1
3 Apr 24 i    `* Re: Another security vulnerability10Stefan Monnier
3 Apr 24 i     `* Re: Another security vulnerability9Thomas Koenig
3 Apr 24 i      +* Re: Another security vulnerability6MitchAlsup1
4 Apr 24 i      i`* Re: Another security vulnerability5Thomas Koenig
4 Apr 24 i      i `* Re: Another security vulnerability4MitchAlsup1
4 Apr 24 i      i  +- Re: Another security vulnerability1MitchAlsup1
7 Apr 24 i      i  `* Re: Another security vulnerability2Paul A. Clayton
8 Apr 24 i      i   `- Re: Another security vulnerability1MitchAlsup1
5 Apr 24 i      `* Re: Another security vulnerability2Stefan Monnier
5 Apr 24 i       `- Re: Another security vulnerability1MitchAlsup1
25 Mar 24 `* Re: Another security vulnerability3John Savard
25 Mar 24  `* Re: Another security vulnerability2Michael S
26 Mar 24   `- Re: Another security vulnerability1Lawrence D'Oliveiro

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal