Author: Robert Hyatt
Date: 08:33:24 02/12/03
Go up one level in this thread
On February 12, 2003 at 04:45:42, Tom Kerrigan wrote: >On February 12, 2003 at 01:58:36, Matt Taylor wrote: > >>Branch prediction is mostly unrelated to OOOE. The IA-64 does have branch >>prediction. It does not have OOOE. > >Of course it's related. Compilers have to rely on static branch prediction (80% >accuracy) if they're going to effectively advance instructions before branches. You keep saying this but it isn't true. I can pull _any_ instruction and insert it before a branch, assuming it is architecturally feasible. On a sparc, with 32 GP registers, I can do this easily. On the X86, with only four GP registers and eight (barely) overall, I often don't have a register to use. There renaming saves the day and it has to be done by the hardware since I can't see the rename space. So, as I said earlier, OOOE and renaming work on intel, but _only_ because the architecture has some legacy shortcomings that prevent a compiler from doing its job properly. Newer architectures don't inherit these shortcomings and the compilers can do far better. Enough better than OOOE doesn't work _nearly_ as well as it does on the X86 architecture. It will always work to some extent, don't get me wrong. But the compiler can actually do some things better than OOOE, even though in some cases the inverse is also true, particularly when you have a crappy architecture API like the X86. > >>On a final note, the Athlon has a 72-entry integer scheduler and IIRC a 36-entry >>FP scheduler. Athlon can therefore see up to 72 instructions ahead. (Remember -- >>1 DirectPath instruction translates 1:1 with a macro-op, or this is the >>impression I get from the docs anyway.) The compiler can still see futher. > >Indeed. It's a shame only IA-64 chips run compiled code... oh, wait... Notice his point, however. The OOOE can only execute what it can "see". Which is typically a pretty narrow "peephole" into the machine language instructions. Compilers also do what is known as "peephole optimizations" but the peephole "size" can be varied depending on how much time you are willing to invest in the optimization phase of the compilation process. > >>No. Predication is the IA-64's answer to branch prediction. Predication is >>completely unrelated to OOOE. > >What, exactly, do you think the point of predication is, then? It's to allow >instructions to execute before the condition is determined, in other words, out >of order. (Or at least in order without being dependent.) If you think >predicated instructions are only executed after the condition is determined, >then what is the difference between a "predicated branch" and a normal branch, >besides some extra instructions? But they _are_ different. Predication just says "do all of this crap and we'll sort out later which was crap and which was important." A compiler can do this on an old 286, for example, although its pipeline was not capable of executing multiple instructions per clock so it would be pointless. But the concept works for _any_ architecture. The hardware can do it, or the compiler can do it, or, in the case of X86, both can do it. > >>Dr. Hyatt's figures "in practice" still show an 1 GHz McKinley 4 times faster >>clock-for-clock than a Pentium 4. > >And every other SPEC program shows that "in practice" McKinley is clearly slower >than a P4. Slower. But you missed the key phrase above "clock-for-clock". Show me _any_ 1.0ghz X86 that can search (running crafty) 1.6M nodes per second. There isn't one. In fact, there isn't any X86 I know of that can do that at any clock rate, yet. My 2.8's peg at 1.0-1.2M nodes per second, and these are xeons with SMT on. > >>The last two questions are more an answer to the question, "How will the IA-64 >>scale?" The question I am answering (and the question originally asked) is, "How >>fast currently is the IA-64 compared to the IA-32/AA-64 in Chess?" > >Your confusion about the original question continues. Somebody asked what the >relative advantages of x86-64 and IA-64 are. It had nothing to do with IA-32. I >have no way to prove this because the post seems to be gone, but I also >distinctly remember writing a post with lists of advantages for each chip and >not mentioning anything about IA-32. > >As for all the extraneous trivia you provided about the chips in question, don't >bother. I already know it. > >-Tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.