"Dwight K. Elvey" wrote:
>
> >From: "Ross Archer" <dogbert_at_mindless.com>
> >
> >Jerome H. Fine wrote:
> >
> >>>Jim Kearney wrote:
> >>>
> >>>
> >>
> >>
> >>
> >>>I just had an email exchange with someone at Intel's Museum
> >>>(http://www.intel.com/intel/intelis/museum/index.htm)
> >>>
> >>>
> >>
> >>Jerome Fine replies:
> >>
> >>I am not sure why the information is so blatant in its
> >>stupid attempt to ignore anything but Intel hardware
> >>as far a anything that even look like a CPU chip, but
> >>I guess it is an "Intel" museum.
> >>
> >>Of course, even now, Intel, in my opinion, is so far
> >>behind from a technical point of view that is is a sad
> >>comment just to read about the products that were
> >>way behind, and still are, the excellence of other
> >>products. No question that if the Pentium 4 had been
> >>produced 10 years ago, it would have been a major
> >>accomplishment.
> >>
> >Harsh! :)
> >
> >Guess it depends on what you mean by "far behind from a
> >technical point of view."
> >
> >If you mean that x86 is an ugly legacy architecture, with
> >not nearly enough registers, an instruction set which
> >doesn't fit any reasonable pipeline, that's ugly to decode
> >and not particularly orthogonal, that from purely technical
> >reasons ought to have died a timely death in 1990,
> >I'd have to agree.
> >
> >However, look at the performance. P4 is up near the
> >top of the tree with the best RISC CPUs, which have
> >the advantage of clean design and careful evolution.
> >
> >It surely takes a great deal of inspiration, creativity,
> >and engineering talent to take something as ill-suited
> >as the x86 architecture and get this kind of performance
> >out of it. IMHO.
> >
> >In other words, making x86 fast must be a lot like
> >getting Dumbo off the air. That ought to count as
> >some kind of technical achievement. :)
>
> ---snip---
>
> It is all done with smoke and mirrors.
Anything the results in a net faster CPU isn't, in my book,
akin to smoke and mirrors.
If anyone's guilty of "smoke and mirrors", it's probably
Intel by making a ridiculous long (20-24 stage) pipeline
just to allow the wayupcrankinzee of clock rates so they can
be first CPU to X Ghz. Why not a 50 stage pipeline that hits
8 Ghz, nevermind the hideous branch-misprediction penalties
and exception overhead?
> We do the same
> here at AMD. The trick is to trade immediate execution
> for known execution. The x86 code is translated to run
> on a normal RISC engine.
Yes, and this in and of itself must be rather tricky, no?
X86 instructions are variable-length, far from load/store,
have gobs of complexity in protected nonflat mode, etc.
I'd bet a significant portion of the Athlon or P4 is devoted
just to figuring out how to
translate/align/schedule/dispatch
such a mess with a RISC core under the hood. :)
> This means that the same tricks
> on a normal RISC engine would most likely only buy about
> a couple percent. It would only show up on the initial
> load of the local cache. Once that is done, there is
> really little difference.
> Choices of pipeline depth, out of order execution, multiple
> execution engines and such are just the fine tuning.
> Intel, like us is just closer to the fine edge of what
> the silicon process can do than anything tricky that
> people like MIPS don't know about.
Well, why isn't something elegant like Alpha, HP-PA, or MIPS
at the top of the performance tree then? (Or are they and
I'm
just not aware of the latest new products.)
My pet theory is that the higher code density of x86
vs. mainline RISC helps utilize the memory subsystem
more efficiently, or at least overtaxes it less often.
The decoding for RISC is a lot simpler, but
if the caching systems can't completely compensate for the
higher
memory bandwidth requirements, you're stalling more often or
limiting
the maximum internal CPU speed indirectly due to the
mismatch.
And decoding on-chip can go much faster than any sort of
external
memory these days.
This isn't really a discussion for classiccmp, but I
couldn't
resist since I'm sure at least some folks enjoy
speculationalism
on such topics. :)
>
> On a separate subject, I was very disappointed in the
> Intel Museum. I'd thought it might be a good place to
> research early software or early IC's. They have vary
> little to offer to someone looking into this level of
> stuff. Any local library has better references on this
> kind of stuff ( and that isn't saying much ).
> Dwight
n
Received on Wed Oct 09 2002 - 15:03:00 BST