Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1626

Re: Why is complex lea slow?

Show all headers | View raw

On 5/16/2011 10:01 PM, MitchAlsup wrote:
> On May 16, 1:02 pm, "Paul A. Clayton"<paaronclay...@gmail.com>  wrote:

>> By the way, do the high performance processors take
>> advantage of the common use of immediate shift amounts to
>> warm-up the shifter?
>
> I never did, the data-path gets setup to deal with the latest data
> arrival (non-constant shifts), so the mux doing the choosing is placed
> somewhat late in the path congruent to the arrival of data. At best,
> instruction decode logic can get the constant to the shifter, but any
> timing of the shifter (dynamic logic, latches, output drivers...) will
> be timed for the dynamic<late>  data.

I agree with Mitch, I have never seen immediate shift count get 
optimized for.


>>   (ISTR reading that some Itanium
>> processor had different latency for immediate shifts versus
>> register-based shifts.)  Early warm-up for register-based
>> shifts might be possible by early operand read (and storing
>> the register operand as an immediate in the instruction
>> payload)
>
> It is my opinion that you are chasing timing ghosts, and that you will
> make more forward progress, faster, by consentrating on the hard (i.e.
> late) stuff rather than trying to eak out a gat delay on the easy
> stuff.

I won't go so far as Mitch, though: some of my research for the Ph.D. 
that I never completed at Wisconsin[*] was on taking advantage of 
inter-operand arrival time skew.  One operand arriving before the other. 
Immediate shift count would be an example.

However, I only really tried to take advantage of skews on the order of 
a cycle.  The best example was the [[Dynamic Instruction Rewriting]] or 
[[Flattening]] that I've talked about here before; other examples 
included skew in multiplier operands, preparing the Booth encodings 
and/or 3X, 5X, etc. products so that you could use higher radix 
multipliers.  (Usually the products.)

Taking advantage of skews on the order of immediate shift count would be 
difficult on a machine that only had a single shifter.   If shift 
immediate were 1 cycle, and shift variable were 2 cycles, then you would 
have a writeback port collision "hazard" (what do you call this), if 
your workload intermixed 1 and 2 cycle operations on the same pipeline.

(By the way, the difficulty/performance impact of intermixing operations 
of different latencies may explain the 3 cycle LEA discussed  in another 
thread.)

You could take advantage of immediate shiftcount to, for example, 
convert shift by 1 into an ADD - you may have more adders than shifters. 
  But that should already be done by the compiler.

If you had lots of EUs you could have multiple pipelines of different 
latencies.  Multiple shifters.

Heck, you could have two writeback ports for any single shifter, 1 or 2 
cycles.

But these all cost.

I must admit that this tyranny of pipeline latency frustrates me.  One 
of the things that first attracted me to OOO execution was the 
possibility of being able to take advantage of data dependent latencies. 
  But you can only really do this if you are not acgeiving higher 
throughput by pipelining.   In some ways, pipeling is a bandwidth 
optimization, while OOO is a latency optimization, and they conflict.

I've similarly been attracted to asynchronous logic - but the same 
problem occurs.  Asynchronous logic can take advantage of many data 
dependent timings - but when you pipeline the asynchronous logic, there 
is a lossage.  Short latency operations may get stuck behind long 
latency operations in the same asynchronous pipeline.  Q: what does 
asynchronous bypassing look like?

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

Thread

Re: Why is complex lea slow? "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-16 11:02 -0700
  Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-16 22:01 -0700
    Re: Why is complex lea slow? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-16 22:50 -0700
      Re: Why is complex lea slow? Piotr Wyderski <peter.pan@neverland.mil> - 2011-05-17 14:42 +0200
        Re: Why is complex lea slow? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-17 08:17 -0700

csiph-web