Re: dtrace: catching thread yield
Re: dtrace: catching thread yield
- Subject: Re: dtrace: catching thread yield
- From: Terry Lambert <email@hidden>
- Date: Wed, 26 Aug 2009 12:19:17 -0700
On Aug 26, 2009, at 10:27 AM, Jamison Hope <email@hidden> wrote:
They just need to have a taller slide so that the ratio of sliding
time to waiting time is improved. And they can make it a pipelined
slide so that multiple children can be in transit from top to bottom
simultaneously. The only problem is that if there's a blocking
instruction somewhere along the line (e.g. a fat kid gets stuck), it
may be difficult to flush the pipe safely. There would definitely be
advantages to having parallel slides, but you know that it's
inevitable that there would be a large degree of slide affinity
which would keep throughput well below the theoretical maximum ("But
I don't like this slide! I wanna go on the same slide that Tommy's
on!").
;-)
We never solved the scalability issues for execution units, or
execution window size, or tag broadcast efficiency, to make dataflow
architectures competitive with Von Neumann architectures. Also, I am
pretty sure no one is selling 2G sticks of content addressable memory.
8-).
The perceived need for procedural affinity, on the other hand, is
mostly just bad problem decomposition by people who think finite state
automata are hard..
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden