Groups | Search | Server Info | Login | Register

Groups > comp.arch > #5852

Re: Lock Elision going to Product

Show all headers | View raw

On 2/9/2012 7:52 AM, Paul A. Clayton wrote:
> On Feb 9, 8:34 am, nedbrek<nedb...@yahoo.com>  wrote:
>> Saw this on Reddit:http://www.reddit.com/r/programming/comments/pfnkx/intel_details_hard...
>>
>> Not a bad turn around from research to product.
>
> This was also mentioned at the Real World Technologies forum:
> http://www.realworldtech.com/forums/index.cfm?action=detail&id=127168&threadid=127168&roomid=2
>
> Hardware Lock Elision will probably be adopted by software
> fairly quickly since it is backwards compatible (i.e., it
> will run correctly on older hardware).  Unfortunately,
> there is a lot of existing hardware that has enough
> parallelism that coarse grained locks (which would benefit
> the most from HLE) are not practical; but one has to
> start somewhere.
>
> The Restricted Transactional Memory facility will
> probably be adopted much more slowly.  Such requires the
> support of two code paths (HLE just re-executes without
> elision of the lock) and older hardware will only be
> able to use the non-transactional path.  There is also
> no indication of the capacity provided for any
> implementation or whether hardware support will be
> provided for nearly guaranteeing success of very small
> transactions (such might not be important, but some
> software developers might want almost failure-proof
> very small transactions).

Note that the compatible form, HLE (Hardware Lock Elision) is made 
possible because of NOP-prefixes - instruction prefixes that were 
treated as NOPs on earlier machines.  In this case the XACQUIRE prefix = 
REPNE, and the XRELEASE prefix = REPE.  The REPNE and REPE prefixes were 
ignored on older machines for instructions that were not loop based 
instructions t=like MOVSB.

"Compatible" in the sense that new code using the XACQUIRE/XRELEASE 
(REPNE/REPE) prefixes will run on old machines.  I never quite remember 
if that is forward or backward compatible. "NCOM" - New Code Old Machine.

Such NCOM compatibility is important because it means that developers do 
not have to ship two versions of a library.  They can ship one version, 
that will run on older machines, albeit with the very slight performance 
degradation caused by the instruction prefix, and the performance 
improvement when run on a new machine.

Note also that XRELEASE MOV mem, reg_or_imm is a "lock release store".
This might naturally have been done on the i486, with the LOCK prefix
- or, rather, the LOCK prefix was ignored on stores on some older 
machines.  But circa the P5 generation they started treating LOCK store 
as an undefined instruction, so you would not get the "New Code runs on 
Old Machine" advantage.

It took a while before people realized that the "loop" prefixes REPNE 
and REPE were NOP-prefixes on non-loop instructions.

There are other possible NOP-prefixes.  You might even use double 
prefixes, like two REPEs - but, although x86 supports that, existing 
hardware penalizes unusual prefix combinations.

---

A while back comp.arch discussed this, and people said that they could 
not imagine why you might ever want to not-trap on instruction encodings 
that are not in use. Well...

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Lock Elision going to Product nedbrek <nedbrek@yahoo.com> - 2012-02-09 08:34 -0500
  Re: Lock Elision going to Product "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-09 07:52 -0800
    Re: Lock Elision going to Product "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-09 12:05 -0800
    Re: Lock Elision going to Product Jason Riedy <jason@lovesgoodfood.com> - 2012-02-13 16:09 -0500
      Re: Lock Elision going to Product "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-13 17:24 -0800
  Re: Lock Elision going to Product Jim <jgoo052@gmail.com> - 2012-03-02 16:59 -0800

csiph-web