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

Groups > comp.arch > #1637

Re: Why is complex lea slow?

Show all headers | View raw

On 5/17/2011 5:42 AM, Piotr Wyderski wrote:
> Andy "Krazy" Glew wrote:
>
>> 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.
>
> Being a big fan of the dataflow approach, a question arises: does
> it make sense to make an OOO engine in a purely dataflow manner?
> Maybe decoding should be excluded, but I can imagine a blob which
> execution spawns more blobs which finally get combined into the
> final result.

Welcome to the cult! Here, have a glass of kool-aid.

Modern OOO engines are dataflow - but they are a limited form of 
dataflow.  Every dataflow node gets executed once and only once - with 
the  possible exception of replay.

This isn't even really Dennis' static dataflow, where a node could be 
executed more than once, e.g. for iterations of a loop.  But in a funny 
way, Dennis' static  dataflow nodes were in-orderr - each node tended to 
produce results in iteration order - whereas when a loop is unrolled 
into the (dataflow) instruction window on a modern OOO machine, the 
iterations of an instruction can execute out-of-order.

But, certainly, modern OOO machines are not generating new  blobs. 
Unless you count branch prediction - which is really the in-order 
instruction fetch engine generating new dataflow nodes.  Or speculative 
multithreading.

There have been attempts to create more dataflow-like mechanisms.  E.g. 
I seem to remember Bob Wedig and Augustus Uht having a paper design 
where each scheduler entry could represent several iterations of a variable.

Also, Dick Wilmot (?) had his data surfer.   On the more academic side, 
Amir Roth has stuff like  this, although he tends to start less 
aggressive than dataflow.

I chose my advisor for my abandoned-when-my-daughter-was-born Ph.D. 
because he was  the only guy other than me who admitted that he was 
trying to build a dataflow machine.  I thought that DMT and SpMT would 
have been built by 2000, and that dataflow would be the step after 
speculative threading.  Instead, I got bogged down in details of how to 
build a large instruction window (hence my L1/L2 instruction window).

Now, if Mikko Lipasti et al are correct with the work recently discussed 
here, perhaps I should not have been so hasty.  I was assuming that the 
dataflow hardware is expensive, so you would want to build a really 
large amount of L2 instruction window, with a small amount of L1 
instruction window (actually, probably several). But Mikko almost has me 
persuaded that the cost equation haschanged, so that you want to leave 
the data in place, even in fairly complex circuit blocks.  Almost... it 
still seems to me that if you have large data, you might be better 
communicating it around a bypass network of a small number of ALUs, 
communicating small instructions rather than large data.

Ultrascalar, Wavescalar ... many of these folk may not appreciate me 
saying that they are similar to dataflow.  And some are only in a small way.

Most of my work has been based on implicitlt dataflow-izing existing 
code --- because I worked for existing companies.

I think that the best opportunities may arise if you shed this 
straitjacket, and figure out what a real dataflow instruction set looks 
like. Who are  the blobs that spawn more blobs?  Like I said, at the 
moment the dataflow nodes are generated by a non-dataflow instruction 
sequence.  Even plural.

At the very least, I think that we may need to have very, very, dynamic 
thread forking.  E.g. a thread fork where the number of threads to fork 
is dynamic.  Possibly even tree driven - fork for all non-null children. 
  This gets us into the dataflow nodes spawning instruction sequencers, 
which themselves spawn dataflow nodes.

Or you can get into the coarse grain dataflow world.  Instead of single 
instruction dataflow blobs, multi-instruction dataflow blobs.  But this 
is where the old dataflow machines went awry: they basically became 
coarse-grain dataflow, or fine grain multithreaded, and they said that 
they did not need OOO because they were getting lots of parallelism at 
the coarse grain of their threadlets.   Well, history says otherwise.

It seems to me that it should be possible to reconcile the instruction 
level dataflow of OOO, with a larger dataflow level.  In some ways, this 
is what I want my L2 scheduler instruction window to do.

---

Last words in this rant:  dataflow never really figured out how to 
handle memory.  They handle memory by making believe it doesn't exist: 
single use memory locations, etc.  Wrap a monad round it.

But memory seems to be fundamental.  We have bitcells, and they can 
change their value.

Perhaps we have reached a point where this is now reasonable:  single 
assignment, functional. Or maybe the real advance is garbage collection: 
  just blindly act as if you have infinte memory, and garbage collect 
the stuff no longer needed.

Back to comp.arch | Previous | Next — Previous 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