I don't put the death of PA-Risc at Itaniums door, since HP was from
all appearances one of the parents of the Itanium architecture and
perhaps the ones that sold it to Intel, rather than vice versa.

They certainly were co-conspirators, so to speak.

On Oct 23, 8:11 pm, ga... at (no spam) allegro.com (Gavin Scott) wrote:

For PA-RISC capability HP had very high hopes for dynamic translation.
One slide from fairly early on suggests they expected to get to 50%
of native performance using translation. In reality they failed to
scrounge up enough cleverness to do it well, and the PA-RISC
compatibility on IPF has always been poor enough that the performance
is commonly considered unacceptable even for business applications.

That's interesting:

IA64 seemed to have a close to complete superset of all PA-RISC
features/instructions, including some very funky address shift/
combination operations specifically claimed to be there to support PS-
RISC features.

The register set was so much larger that it could be mapped
statically.

If all this hw support didn't get at least 50%, then the clock rate
must have been very disappointing (which it was, right?).

If I remember the numbers Anton provided, 50% per clock for untuned

The only other Itanium platform I ever used was HP-UX, where the x86 was
not significant. By the time people were asking for our software on
Itanium Linux, our answer was "That's going to cost you more than you
are willing to pay."

Robert Myers <rbmyersusa at (no spam) gmail.com> writes:
[Speed of PA-RISC emulation on Itanium]

As I'm writing this, I'm wondering how code translators interact with
branch predictors.

Direct branches are translated to direct branches and are fast (and
work well with branch predictors). In general indirect branches have
to go through a translation table and are quite a bit slower; it may
be possible to translate some patterns in a way that avoids the
translation table overhead (like the code coming out of C compilers
for switch statements); AFAIK neither PA-RISC nor IA-64
implementations have indirect branch predictors, so branch prediction
does not come into play here.

Robert Myers <rbmyers... at (no spam) gmail.com> writes:

[Speed of PA-RISC emulation on Itanium]

If I remember the numbers Anton provided, 50% per clock for untuned
code and a less than optimal compiler seems about right

I don't know what you think you remember, but I have not presented
PA-RISC results, simply because we have no PA-RISC box (for Gforth)
and nobody has submitted PA-RISC results (for the latex benchmark).

For those who wonder what this is all about, the message that he means
is <2009Oct22.164... at (no spam) mips.complang.tuwien.ac.at>, and the results
referred to are

http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-sli...http://www.complang.tuwien.ac.at/franz/latex-bench
3.
I couldn't get the link to work when I wrote the post. On your scale,

Why not? It ran x86 code natively in an integrated manner on a
native Itanic OS. As with most things Merced the original cut wasn't
impressive in terms of speed, but the relative sizes of the x86 and
Itanic processors (especially given the amount of the chip area
dedicated to cache) made it clear that full-fledged x86 cores could
be included later if necessary as soon as the next process
generations appeared.

"Bill Todd" <billtodd at (no spam) metrocast.net> wrote in message
Save for the grace of AMD it still might have: without a credible,
inexpensive, and pervasive 64-bit alternative Intel could have just
waited until desktops began to demand 64-bit processors.

I don't put the death of PA-Risc at Itaniums door, since HP was from
all appearances one of the parents of the Itanium architecture and
perhaps the ones that sold it to Intel, rather than vice versa.

They certainly were co-conspirators, so to speak.

I used it bit. On both Merced and McKinley, the x86 had about one-third
of the throughput of native Itanium code: I was benchmarking with the
same source built both ways.
....
By the time people were asking for our software on
Itanium Linux, our answer was "That's going to cost you more than you
are willing to pay."

If I remember the numbers Anton provided, 50% per clock for untuned
code and a less than optimal compiler seems about right

As I'm writing this, I'm wondering how code translators interact with
branch predictors.

Judging from experience with Linux-Alpha, this probably means that the
kernel supports executing IA-32 executables, but needs a helper file
for that (on Linux-Alpha it was the emulator), and that file is
missing.

Robert Myers wrote

On your scale,
where ia32 is  1.0 performance per cycle,

Different IA32 implementations have different performance per cycle in
the range of 0.55-1.0.

Itanium was between 0.35 and
0.40, barely better than ARM XScale.

~0.39, In the same ballpark as the other non-IA32/AMD64 CPUs (~0.34-0.53)..

I took the ia32 to indicate a
compiler working with a processor that it was well-tuned to schedule
for and the Itanium results as indicative of how code that wasn't
analyzed or scheduled with much insight into ia64 would do.

So the PPC, Alpha and ARM results are also due to lack of insight into
the scheduling requirements of the CPU in your opinion?

My theory (which you can find in the text of that slide) is that the
better perfromance of the IA32 and AMD64 implementations on this
benchmark is because they perform indirect-branch prediction and most
of the others do not (hmm, the 21264B also has a kind of
indirect-branch predictor, but the performance is still not so great
at ~0.43; I have no theory for that).

Unless the PA-RISC implementation you are thinking of has an
indirect-branch predictor, I have no reason to expect it to perform
better than ~0.5.

I don't have enough insight into the other architectures to comment.

In article <2009Oct24.154356 at (no spam) mips.complang.tuwien.ac.at>,
anton at (no spam) mips.complang.tuwien.ac.at (Anton Ertl) wrote:

Judging from experience with Linux-Alpha, this probably means that the
kernel supports executing IA-32 executables, but needs a helper file
for that (on Linux-Alpha it was the emulator), and that file is
missing.

What do you get when you run ldd on the IA-32 executable?

I'm
wondering if it needs a different loader, since having one of those
missing is one way of producing the error message you quote.

On Oct 24, 10:02=A0am, an... at (no spam) mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-sli...h=
ttp://www.complang.tuwien.ac.at/franz/latex-bench
3.
I couldn't get the link to work when I wrote the post.

On your scale,
where ia32 is 1.0 performance per cycle,

Itanium was between 0.35 and
0.40, barely better than ARM XScale.

I took the ia32 to indicate a
compiler working with a processor that it was well-tuned to schedule
for and the Itanium results as indicative of how code that wasn't
analyzed or scheduled with much insight into ia64 would do.

One interesting property of quantum mechanics is that for irreversible
logic, there's a minimum amount of energy that is necessary to make it
happen.  Reversible logic does not have this drawback.  Therefore,
people investigate into reversible logic, even though the actual
components to get that benefit are not in sigh (not even carbon nanotube
switches have these properties, even though they are much closer to the
physical limits for irreversible logic).  Many people also forget that
quantum mechanics does not properly take changes in the system into
account, and that means that your reversible logic only works with the
predicted low power when the inputs are not changing any more - and this
is just the uninteresting case (the coherent one - changes in the system
lead to decoherence, and thereby to classical physics).

On Sat, 24 Oct 2009 12:25:40 -0700, Robert Myers wrote:
I don't have any insight into what being architecture-naive on the other
architectures might be, but, for Itanium, you have to start with deep
insight into the code in order to get a payback on all the fancy bells
and whistles.  Itanium should be getting more instructions per clock,
not significantly fewer (that *was* the idea, wasn't it?).

I've not used an Itanium, but it would seem to have quite a bit of
practical similarity to the Texas Instruments TIC6000 series of VLIW DSP
processors, in that it is essentially in-order VLIW with predicated
instructions and some instruction encoding funkiness.  That whole idea is
*predicated* on being able to software-pipeline loop bodies and do enough
iterations to make them a worthwhile fraction of your execution time.  
From memory, Anton's TeX benchmark is the exact opposite: strictly
integer code of the twistiest non-loopy conditional nature.  I would not
expect even a heroic compiler to get *any* significant parallel issues
going, at which point it falls back to being an in-order RISC-like
machine: not dramatically unlike a pre-Cortex ARM, or SPARC, as you said.

Now, Texas' compilers for the C6000 *are* heroic, and I've seen them
regularly schedule all eight possible instruction slots active per cycle,
for appropriate DSP code.  The interesting thing is that this process is
*extremely* fragile.  If the loop body contains too many instructions
(for whatever reason), or some other limitation, then the compiler seems
to throw up its hands and give you essentially single-instruction-per-
cycle code, which is (comparatively) hopeless.  Smells like a box full of
heuristics, rather than reliable proof.  The only way to proceed is to
hack the source code into little pieces and try variations until the
compiler behaves "well" again.

At least the TI parts *do* get low power consumption out of the deal, and
since they clock more slowly they don't have quite so many cycles to wait
for a cache miss.  And no-one is trying to run TeX on them...

I get so tense here, trying to make sure I don't make a grotesque