[Humor] McDonalds Drive-through Architecture

[Jon Scott Stevens <jo...@latchkey.com>]

After all the recent pipeline/valve discussion and code commits, I thought
that this humor was appropriate...:-)

-jon

------ Forwarded Message

Forwarded-by: gkm@petting-zoo.net (glen mccready)
Forwarded-by: Jeff Boerio <bo...@ichips.intel.com>
From: Jim Vaught

[For those who don't know, some McDonalds have a new setup where there
are two ordering systems merging into the drive through so two people
can order at a time.]

It seems to me that McDonalds could use a serious lesson in pipeline
architecture.  They started out well.  They recognized that their
classic 2 stage drive through pipeline (order, execute) could be
optimized by extending it to a 3 deep pipeline splitting the execute
stage into pay and pickup stages since the execute stage typically had
a higher latency than the order stage assuming well behaved instructions
whose operands are known at order time thus avoiding an order stall
condition.  So they had a high performance 3 stage pipeline (order, pay,
pickup) which worked rather well in my humble opinion.  But they
couldn't leave well enough alone.  They decided to attempt to get really
fancy with a full blown out of order machine (apart from the catastrophy
avoidance out-of-order "penalty box" for inordinately high latency
instructions which has existed for as long as I can remember).  Now they
have a 2 wide order unit feeding the rest of the pipeline allowing them
to simultaneously process the order stage of 2 instructions (I guess
they thought that the order stage had become the critical latency in
the pipe by a large enough amount to warrant such an architectural
change...).  The problem is that the execution engine can not keep up
with a 2-wide front end.  Invariably the pipeline stalls in execution
and leaves instructions which have already completed the order stage
stuck in the pipe preventing subsequent instructions from entering.
With the older system during peak processing times the execution engine
would have trouble keeping matching the throughput of a single order
unit, making any benefit from a higher throughput front end miniscule
at best during high load times.  In an almost empty system (perhaps that
is the condition they are designing to) there may be a moderate
improvement in throughput, but I can't imagine the overall benefit being
worthwhile.

Another problem is the lack of an arbitration mux to schedule
instructions from the front end into the execution pipeline.  The
combination of a lack of collision avoidance logic with the fact that
there are almost always 2 instructions stalled and waiting to enter the
execution pipeline is a fault waiting to happen...  Additionally, the
absence of scheduled control of entry for instructions from the front
end into the execution pipe prevents the instruction queue from being
able to correlate operands with instructions in the (frequent) event of
a collision.  This results in a increased risk of instructions executing
with other instructions' operands and an added "confirm" logic latency
in the pay pipestage.  All in all the new design strikes me as an overly
ambitious attempt at optimization which has resulted in a drive-through
model which offers no significant benefit over the simpler model but
plenty of drawbacks.

Of course, the analogy does have (at least) one gaping hole.  In a CPU
pipeline an instruction doesn't get irritated when 3 other instructions
which were issued behind it end up executing before it, dramatically
increasing its latency through the system. *grumble*

I'd be really interested in seeing some system latency, throughput, and
error rate data comparing the old system to the new.  I can't imagine
the new system shows any real benefit (although maybe I just don't have
a wild enough imagination).  I suspect it is simply an overarchitected
mess.  I hope they have someone doing performance validation on it.

Jim Vaught
(jvaught@ichips.intel.com)

------ End of Forwarded Message


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>