We NEED an Itanium 3!

Robert Myers wrote:
The problem is that you have no way of predicting the actual state of
the cache at run time. Even if you have the only job on the machine,
you still have to share cache with the kernel, and with the
discrepancy between clock speed and memory latency, unexpected cache
misses with fixed instruction scheduling are an absolute disaster.

?? How is this the problem? I know of no microarchitecture that can
look at the cache contents and take that information into account when
scheduling for instruction dispatch. That EPIC finds this difficult to
do does not make it any worse than PPC or x86 or 68k, since none of them
do it either.

Last sentence. Ah, you are talking about out of order execution. There
are workarounds to cover memory latency in EPIC besides trying to graft
an out-of-order queue on the frontend. Solutions that work just about
as good but are much cleaner and easier to deal with.

Alex
--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)

On Mon, 5 Apr 2004 09:32:39 -0700, "spinlock"
wrote, in part:

Don't confuse the issue by whining about the current
implementation(power, 32bit degradation, etc).

EPIC indeed may be a good idea. But it won't succeed in the
marketplace if it isn't allowed to become the "standard", and if Intel
instead chooses to abandon it. If that's what developers see coming,
it won't be supported.

I see however that SSE (Streaming SIMD Extensions) apparently is the
128-bit MMX that I felt the Itanium should have had as one feature.

John Savard
http://home.ecn.ab.ca/~jsavard/index.html

On Tue, 06 Apr 2004 08:18:43 -0400, Alex Johnson
wrote:

snip

Last sentence. Ah, you are talking about out of order execution. There
are workarounds to cover memory latency in EPIC besides trying to graft
an out-of-order queue on the frontend. Solutions that work just about
as good but are much cleaner and easier to deal with.


If I'm not mistaken, I pointed you toward papers that describe some
possible solutions. It's true that not all work-arounds involve
run-time scheduling, but I predict that Itanium, if it survives, will
eventually use some kind of run-time scheduling.

In any case, for a core that was supposed to be simple because it
didn't need all that on-board scheduling circuitry, the Itanium core
sure uses alot of transistors and alot of watts. Now Yousuf Khan will
be certain that I am an imposter.

RM

On 6 Apr 2004 01:02:35 -0700, (Black
Jack) wrote:

Robert Myers wrote in message . ..

snip


Whoa! Who are you, and what have you done with Robert Myers? :-)

I am the resident Itanium bigot of at least two other newsgroups, if
not of this one. The idea of freezing scheduling at compile time just
isn't going to fly, and Intel is working on ways to wriggle out of
that straitjacket.

Ah, that's more like it, but I'm still not convinced that it's you.
Say something optimistic about Itanium.


You will notice that just about every time I mention Itanium these
days, I use the phrase "if it survives."

Looking at this particular post and my use of "if it survives," you
might be tempted to believe I had changed my religion, but I haven't.

I still look to Intel and to Itanium as the most likely places for
something really interesting to happen in computer architecture. For
recent speculation about flirtation with the impossible, see Dick
Wilmot's recent post on what he refers to as "Data Surfing" on
comp.arch.

The "if it survives" part is my recognition that all of Intel's lines
have to be on the table at the moment. What to do about NetBurst has
to be issue number one, but if Intel is looking for a moment of
maximum noise and confusion at which to sink Itanium beneath the waves
of the North Atlantic, this would be it. That said, I do expect
Itanium to survive.

I would imagine that by now you are fully reassured that it's really
me. :-).

RM

Robert Myers wrote in message . ..
You will notice that just about every time I mention Itanium these
days, I use the phrase "if it survives."

Actually, no I hadn't noticed that you started using that little
phrase, but of course now I have. Dial-up connections, you know. :-)

The "if it survives" part is my recognition that all of Intel's lines
have to be on the table at the moment. What to do about NetBurst has
to be issue number one, but if Intel is looking for a moment of
maximum noise and confusion at which to sink Itanium beneath the waves
of the North Atlantic, this would be it. That said, I do expect
Itanium to survive.

If NetBurst is replaced by the latest Pentium-M revisions, then the
latest P4 motherboards will likely survive, but I'm not sure about the
latest Intel gimicks like Hyperthreading which was designed to mask
one of the various P4 shortcomings. Hyperthreading was needed for P4,
but it probably won't be needed on P-M. I wonder how Intel is going to
explain the deletion of Hyperthreading to the public after so much
hype about it just a few months before? I'm sure there will be some
****ed off people who will believe that now they won't be able to
multitask without it. :-)

Yousuf Khan

Robert Myers wrote:

If I'm not mistaken, I pointed you toward papers that describe some
possible solutions. It's true that not all work-arounds involve
run-time scheduling, but I predict that Itanium, if it survives, will
eventually use some kind of run-time scheduling.

Yes, there will be a few flavors of run-time tweaking of the scheduling
in future Itanium, but I do not think a full out-of-order solution is
likely. If so, it will take almost as long to appear as it did in x86.

In any case, for a core that was supposed to be simple because it
didn't need all that on-board scheduling circuitry, the Itanium core
sure uses alot of transistors and alot of watts.

Was that the claim? I think the claim was that the simplified core
would allow those extra transistors and watts to be used for other
features to further improve performance. Huge tracts of land were
devoted to predication, speculation (control and data), expansive
register files, additional protection structures on data paths and
busses, more modern interrupt implementation, etc. It almost looks like
one faction said "Let's cut this headache out of the chip and we'll be
able to make dies in half the area" when another faction said "Look at
all this unused reticle space! I have an idea we can use it for...."

Alex
--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)