The other problem with even native IA64 code was reliability. The
skill needed to track down problems that might be code generation
bugs or obscure race conditions was MUCH greater than that needed
for other systems. So a lot of code was very unreliable.

I should be interested if anyone used desktop GUIs and applications
compiled natively, to know what they thought. The HPC people were
distinctly unhappy - SGI got the Altix going, but several owners
of 'ordinary' Linux Itanium boxes turned them off as unsupportable
for an amount of effort that made them cost-effective.

nmm1 at (no spam) cam.ac.uk wrote:
In article <4AE12FA9.1000706 at (no spam) patten-glew.net>,
Andy \"Krazy\" Glew <ag-news at (no spam) patten-glew.net> wrote:
Robert Myers wrote:

I am not aware of an Itanium shipped or proposed that had an "x86 core
on the side".

I am. I can't say how far the proposal got - it may never have got
beyond the back of the envelope stage, and then got flattened as a
project by management.

I am reasonably certain that you are misremembering or misunderstanding
a presentation that may have oversimplified things.

Perhaps the problem is terminology: to me, and to people at Intel, "x86
on the side" means that you have an x86 core right next to the Itanium
core, connected at the bus, or perhaps the L1 or L2 cache.

IIRC, HP's Dynamo, a run-time PA-RISC to PA-RISC binary translator, was
able to achieve a significant performance gain over just running the
binary natively. They also ported it to x86 under the name DynamoRIO,
though I can't recall the performance results.

DEC's binary translator (FX32?) made the Alpha, for a few months at
least, the fastest "x86" machine in existence.

MS's .NET stuff seems to run pretty fast, especially when you consider
all the safety checks that it always does which are usually left out of
native C/C++ binaries, garbage collection, etc. Some tests show that
it's actually _faster_ than native code, once you subtract the start-up
time hit.

Apple seems to be committed to their LLVM stuff, which is already
reaping huge graphics performance gains. Rosetta was pretty darn fast,
enough to be useful and transparent, though not quite as fast as native
code.

Run-time translation seems to have a lot of success stories; the
miserable failures of Transmeta and Intel may just be well-publicized
anomalies.

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.

Sidenote about reversible computing: Often, people use a "history" to
make storing values in memory reversible. However, creating information
is just as costly as destroying it, so creating a history has no energy
benefit over replacing old information in a memory cell. The only
energy efficient reversible memory operation is to swap memory and
register values.

Sidenote about reversible computing: Often, people use a "history" to
make storing values in memory reversible. However, creating information
is just as costly as destroying it, so creating a history has no energy
benefit over replacing old information in a memory cell.  The only
energy efficient reversible memory operation is to swap memory and
register values.

This problem does seem fundamental to me at my current level of

On Oct 23, 1:45 pm, Mayan Moudgill <ma... at (no spam) bestweb.net> wrote:
Andy "Krazy" Glew wrote:
Problem is with the standard. H.264 specifies that the frame is CABAC
encoded.

Not quite:

H.264 defines two alternate encoding schemes, of which CABAC gets the
better compression, but it is fully compliant to use the other (I
don't remember the name of it) if the encoder wants to.

However, since a decoder has to be able to handle CABAC as well, that
limits the maximum bitrate that you can support in sw.

Andy "Krazy" Glew wrote:
For example: divide the image up into subblocks, and run CABAC on each
subblock in parallel. To obtain similar compression ratios you would

This is the only silver lining: Possibly due to the fact that they were
working on PS3 at the time, Sony specified that Bluray frames are all
split into 4 independent quadrants, which means that they could
trivially split the job across four of the 7 or 8 cell cores.

This also reduced the size of each subframe, in 1080i, to 256 K pixels.

Heck: Willamette / Pentium 4 was brought to you by peopled who thought
OOO was a bad idea. The original concept was anti-OOO. They were
forced to implement OOO, badly, because the anti-OOO approach did not fly.

If I make the following assumptions:
* Transistors are free
* But power is the most important thing
* and you have a lot of parallelism
as is true of some supercomputer workloads (and even virtual
reality graphics for the home)

Then I think that you can reasonably extrapolate that the best
computer architecture is MIMD, with the simplest possible,
non-pipelined, blocking on a cache miss, processor cores.