Is it time to stop research in Computer Architecture ?
|
From: Gavin Scott on 26 Oct 2009 14:08 nmm1(a)cam.ac.uk wrote: > 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. At least under HP-UX this was not my experience. I've seen no more compiler related issues under Itanium than I did under PA-RISC, though we didn't really start doing significant work with it until customers actually started having the machines in production so there were probably more problems early on. These days Itanium under HP-UX seems to be as stable and reliable a development platform as any other. > 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. The Itanium Linux project was reasonably well supported by HP, but it didn't have anyhting like the mindshare it needed to get done well and quickly, so IIRC it was mostly just a few guys in HP having to figure out how to re-invent everything without very much help from the Linux community at large. G.
From: Tom on 26 Oct 2009 14:25 "Andy \"Krazy\" Glew" <ag-news(a)patten-glew.net> wrote in news:4AE3A728.3040001(a)patten-glew.net: > nmm1(a)cam.ac.uk wrote: >> In article <4AE12FA9.1000706(a)patten-glew.net>, >> Andy \"Krazy\" Glew <ag-news(a)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. I worked in HP Labs (but nowhere near the Itanium) when such an announcement was made. My reaction was "What? WHAT? Bloody hell!" It was about that time that I really became disenchanted with the Itanium and made the decision that I would consciously ignore it.
From: Gavin Scott on 26 Oct 2009 14:33 "Andy \"Krazy\" Glew" <ag-news(a)patten-glew.net> wrote: > 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. Yes, I think we're all talking about the same thing, but being outside the implementaiton world the difference between the "x86 on the side" and the "x86 front end" is easy to miss/ignore. G.
From: Gavin Scott on 26 Oct 2009 14:49 Stephen Sprunk <stephen(a)sprunk.org> wrote: > 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. Just to add to the list, when HP migrated their "Classic" stack-based architecture that ran their HP-3000 servers of the day onto PA-RISC, they provided very good binary compatibility via both static translation and run-time emulation (neither really counts as dynamic translation though). I've told this story before, but the run-time emulator for the 16-bit classic architecture consisted of hand-coded PA-RISC that managed to do the emulation in something like an average of 7 PA-RISC instructions per classic instruction. One of the engineers suggested to me that they suspected there were cases where the emulated 16-bit code might run faster than native PA-RISC due to the fact that the smaller 16- bit code plus the emulator could entirely fit into the cache where the 32-bit PA-RISC code might not. The static translation version eliminated the instruction decode step and could omit things like condition code generation when it was not needed. The translated code was much larger than the original though and got tacked onto the end of the original bianry file. In any case it was very impressive and I can't help but think that part of the problem with PA-RISC -> Itanium translation was that they just didn't mange to get a small enough team of clever enough people assigned to it. G.
From: Gavin Scott on 26 Oct 2009 16:27
Terje Mathisen <terje.wiig.mathisen(a)gmail.com> wrote: > 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. Yes, and the virtual addressing scheme is practically identical to PA-RISC 2.0. There are some differences, like PA-RISC offering both pre- and post- increment on memory ops, but it's the sort of thing translation should not have had a big problem with. Someone in HP did once say to me that they had changed the PA-RISC compilers several years earlier to (allegedly) start scheduling for optimal execution on Itanium (without telling anyone) long before the Itanium sytems became available, which is a clever trick. > The register set was so much larger that it could be mapped > statically. The low 32 non-rotating registers map pretty well to the PA-RISC register set, but again some oddities like gr0 being read-only on IPF (IIRC anyway). I suspect that dealing with corner cases caused them more grief than they expected, and the cost of switching between translated code and handling exceptions that required falling back to emulation of some sort might have been an issue, but that's just speculation and I've never really tried to go look at what it's doing. G. |