Re: Efficiency of in-order vs. OoO

Liste des GroupesRevenir à c arch 
Sujet : Re: Efficiency of in-order vs. OoO
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1) (mitchalsup@aol.com (MitchAlsup1))
Groupes : comp.arch
Date : 09. Mar 2024, 05:01:49
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <81072affd0e9b23260975a11cc07e9a8@www.novabbs.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : Rocksolid Light
Paul A. Clayton wrote:

On 2/26/24 10:48 AM, EricP wrote:
Paul A. Clayton wrote:
On 1/28/24 1:48 PM, EricP wrote:
[snip]
Multiple parallel pipelines is fine but it has to sequence the pipe exits
so the results retire in order for precise exceptions and interrupts.
>
In-order retire is not strictly required for precise exceptions
and certainly is not needed for interrupts. If the exception's
presence is determined before writeback of results from later
instructions, these writebacks can be prevented. One could
alternatively use a conservative filter of exception conditions
to stall writeback of later results (and stall those pipelines)
until it is known whether the exception occurs.
 Interrupts have to be restartable so in-order retire, where everything
older than the interrupt RIP is executed and retired and everything
after that RIP is not, is simplest and cheapest to implement.
Yes you could make it more complicated, but why?

The above described method still provides precise exceptions. The
absence of a earlier exception is required to allow such out-of-
order retirement.

This also means that handling of an asynchronous event might have
to be delayed (if one did not want to have two threads active)
until all instructions before the latest-in-program-order retired
instruction have retired.

For memory reads, the late failure generated by an uncorrectable
ECC error would probably have to be handled differently or there
would probably be little opportunity to exploit out-of-order
retirement. It might not be entirely unreasonable to treat such as
a fatal thread error that is asynchronous.
What about for memory stores where the ECC check on the delivered data fails ?? This seems to be just as fatal as a LD with an ECC fail.

I suspect general out-of-order retirement would not be worthwhile
with precise exceptions; it just sounds complex. My comment was
mainly to point out that such was possible not that it was wise.
We basically all converged on this about 1990.

[snip]
Moral of the story: don't use the exception mechanism for usuals
and then complain about the performance.



Date Sujet#  Auteur
9 Mar 24 * Re: Efficiency of in-order vs. OoO12Paul A. Clayton
9 Mar 24 +* Re: Efficiency of in-order vs. OoO8mitchalsup@aol.com (MitchAlsup1)
9 Mar 24 i+- Re: Efficiency of in-order vs. OoO1Paul A. Clayton
9 Mar 24 i+* Re: Efficiency of in-order vs. OoO5mitchalsup@aol.com (MitchAlsup1)
10 Mar 24 ii+- Re: Efficiency of in-order vs. OoO1MitchAlsup1
10 Mar 24 ii+- Re: Efficiency of in-order vs. OoO1MitchAlsup1
13 Mar 24 ii+- Re: Efficiency of in-order vs. OoO1MitchAlsup1
13 Mar 24 ii`- Re: Efficiency of in-order vs. OoO1MitchAlsup1
9 Mar 24 i`- Re: Efficiency of in-order vs. OoO1mitchalsup@aol.com (MitchAlsup1)
10 Mar 24 `* Re: Efficiency of in-order vs. OoO3MitchAlsup1
13 Mar 24  `* Re: Efficiency of in-order vs. OoO2MitchAlsup1
13 Mar 24   `- Re: Efficiency of in-order vs. OoO1MitchAlsup1

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal