Is it time to stop research in Computer Architecture ?
|
From: nmm1 on 24 Oct 2009 09:59 In article <hbmdnY6DTMGrYH_XnZ2dnUVZ8tKdnZ2d(a)giganews.com>, <jgd(a)cix.compulink.co.uk> wrote: > >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." 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. Regards, Nick Maclaren.
From: Anton Ertl on 24 Oct 2009 09:43 jgd(a)cix.compulink.co.uk writes: >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." Our IA-64 box is running under Linux reacts as follows when trying to run an IA-32 executable: -bash: ./gforth: No such file or directory (Note that ./gforth exists and is executable). In contrast, when I try to execute an AMD64 or Alpha executable, I see: -bash: ./gforth: cannot execute binary file 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. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: Anton Ertl on 24 Oct 2009 10:02 Robert Myers <rbmyersusa(a)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.164225(a)mips.complang.tuwien.ac.at>, and the results referred to are http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-slides.pdf http://www.complang.tuwien.ac.at/franz/latex-bench >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. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: nmm1 on 24 Oct 2009 10:18 In article <2009Oct24.160207(a)mips.complang.tuwien.ac.at>, Anton Ertl <anton(a)mips.complang.tuwien.ac.at> wrote: >Robert Myers <rbmyersusa(a)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. In my rather ancient experience (for other translations), that's not the problem. It's the cases where a very commonly used instruction in the original needs a conditional in the target, of the sort that is hard for an automatic optimiser to remove. Delights like whether right shift of negative values propagate the sign bit or not, If you need a conditional every time you can't be certain of the sign of the integer being shifted, that's bad news. Especially as the direction of the branch may not be predictable based solely on the location of the shift. Regards, Nick Maclaren.
From: jgd on 24 Oct 2009 10:39
In article <2009Oct24.154356(a)mips.complang.tuwien.ac.at>, anton(a)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? Just interested, no need to worry if checking this isn't trivial. 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. -- John Dallman, jgd(a)cix.co.uk, HTML mail is treated as probable spam. |