You are correct that Crusoe does the translation in software. Aside from that, it's the same idea, and it makes the ISA largely irrelevant for the same reasons.
I think you have the impression that the traces are nothing but concatenated sequences of u-ops translated dumbly from the CISC instructions. I was under the impression that the hardware was capable of doing some straightforward optimizations on them.
If it is a simple concatenation, then I see your point, and I agree that the CISC instructions are problematic. However, a future rev of the Pentium could conceivably do things like register renaming once, and store the result in the trace cache, making that operation essentially free.
In effect, there's no reason the chip couldn't do more and more of the work of the compiler. That's essentially what Transmeta did.
No, since you cannot use the stack registers to hold information for a long time, but have to put it somewhere else (or recalculate).
That's spilling (and rematerialization). Now that I think about it, I guess the traces probably can't get rid of spills, and they probably can't do rematerialization. You may have a point there.
However, why can't I store something on the stack for a long time? Push...do a million things...pop. As long as I don't overflow the stack in the mean time, I can store things there as long as I want. Overflowing the stack is a matter of register pressure, which affects non-stack-based ISAs too.
1) Each time the compiler is forced into using a more complex instruction than needed because the simpler instruction isn't available in the ISA,
These should get translated into the appropriate u-ops. Bingo, no problem.
2) Stack handling imposed on the code by the lack of general purpose registers (the effect of this is somewhat reduced by caches),
This is spilling. I'll grant you that one.:-) Though, as you say, caches should make that relatively cheap. Spills inside a hot loop should always be cache hits, and spills outside a hot loop don't matter from a performance perspective.
3) mov instructions forced into the code by special purpose registers.
You mean movs from one register to another? Those would disappear in the traces, if they do any kind of register renaming.
I do not understand how you can say that a CISC layer does not slow the system down and that the ISA is "almost irrelevant". I have interpret that as pure ignorance.
Well, maybe it's ignorance, but I haven't yet seen anything in your post that explains why the CISC instruction set impedes performance.
Your best example was the FP stack. However, does that not internally become traces that can access the FP registers in arbitrary ways? Can the traces not eliminate extra spills, dups, swaps, and other artifacts of stack-based computation? If it doesn't currently do so (which would surprise me) then I would expect that a future version of the Pentium certainly could.
I say the ISA is almost irrelevant because the compiler's optimizations occur with RISC-like instructions, and then the actual execution (u-ops) occurs with RISC-like instructions. The CISC ISA doesn't actually do anything except communicate the former to the latter. Certainly there is overhead for translating the ISA to u-ops, but hot code is usually executed many times, and so the translation cost is amortized over a large number of iterations, making it negligible.
AMD's whitepapers on x86-64 claim that the x86 ISA is a good one for their moden processors because they get the code density of CISC with the register usage and ABI models of RISC. Clearly they may be biased because they have a technology to promote, but I think their arguments have merit.
Perhaps you could give an example of how the P4's internal u-op traces are sub-optimal because of the CISC ISA?
I doubt it could do much better than the P4's own hardware. Internally, the CISC instructions are turned into RISC traces, based on dynamic information that the compiler doesn't have, and also architectural information that presumably changes with each version of the chip.
The only advantage left to the compiler is complex dataflow analysis, etc., and that can be done just fine with CISC instructions. Compiler intermediate representations are RISC-like anyway.
Thus, the combination of optimizing compilers plus P4's trace cache makes the ISA almost irrelevant. Even the lack of general-purpose registers can be largely made irrelevant by the trace cache.
(Translation: the whole system is now so complex that it's nearly impossible to tell what effect a change may have.:-)
The expansion of instruction sets have two drawbacks: 1) bloated designs and 2) more and more complex compilers. That is why RISC is leading the way (in a CISC suite) and CISC is degraded into keyboard controllers etc.
I'm not sure what a "CISC suite" is, but I presume you're referring to Pentiums and such as being RISC internally with a CISC ISA? In that case, your point #2 doesn't apply. Compilers see only the ISA.
The Walking With X series is a dramatization of a modern nature show using the best available facts. I think you're taking it way too seriously. You might as well criticize Jurassic Park.
If you have any other examples, I'd be interested to know what they are. Otherwise, you have simply jumped to a broad, unfounded conclusion about "most pre-history books and television shows" from a single work of science fiction. That may explain people's reaction.
Obviously the constant multipliers in execution time can be more important, in practice, than the asymptotic complexity. However, "Big-O" notation is specifically designed to disregard constant multipliers, in order to understand how an algorithm will behave with widely-varying input sizes.
Big-O has a specific meaning. If it doesn't match what you're trying to say, then just don't use it.
Let me re-iterate the portion of my post that you didn't quote:
Code is unlike almost anything else: the more you use it, the better it works.
Let me explain what I mean...
According to your logic, we should all stop using libraries like glibc and write our own routines for string manipulation, file manipulation, etc. for each program we write; and in so doing, the system of programs as a whole would become more robust because every bug would be confined to one program.
The fallacy here is that by re-implementing the same functionality repeatedly, the chances of having a bug increase at least as quickly as the number of implementations. In practice, it is likely to increase much more quickly, because each implementation is getting less exercise.
I would much prefer a single implementation of some given functionality shared among dozens of programs. It would be exercised much more heavily, making bugs less likely for all the programs.
If all of your code is relying on the same routines to handle regular expressions, or argument processing, or anything else you can name, you'd better be pretty damned sure that code is bugfree. Everything is depending on it.
I think it's exactly the opposite. If they all share the same code, and that code works for one case, then it works for all of them.
Code is unlike almost anything else: the more you use it, the better it works.
Thanks for the clarification, but I don't buy it. If BusyBox has a buffer overflow when argv[0] is set to, say, "vi", then that would be no more and no less damaging than if a regular system had a buffer overflow in vi.
True but, anything over 6 FPS isn;'t noticable by the human eye.
Well, this is patently false. Otherwise, why don't you set your monitor's refresh rate to 6FPS and see how you like it? I presume you must have meant "60 FPS". Regardless, even that is false.
I, for one, am reasonably confident that I could do a blind taste test and descern 60fps from 100fps. How?
The answer is motion blur. Real life has motion blur because your retinas don't react instantaneously. When an image moves rapidly across our retina, all the receptors between points A and B are stimulated. In contrast, video games don't yet do any motion blur. Therefore, you get a rapid succession of motionless frames. If the frames are far enough apart, some retinal receptors between A and B will not be stimulated. The effect is disorienting, and even sometimes a bit nauseating.
Did you see Gladiator? Remember how disorienting the initial battle scene was? That's because they used a technique to greatly reduce motion blur (effectively, to 12fps). It's the same effect, and if you get disoriented in a game, you lose.
Without actual motion blur, the best the games can do is crank the frame rate way up, and simulate motion blur with many, many frames rendered close together. The more frames you have per second, the more realistic the motion will appear.
Ok, well if that distinction is worth the extra $699 USD, to you, then go for it. I think I'll spend the money on another computer to use while the first one reboots.
Slashdot Mirror
You are correct that Crusoe does the translation in software. Aside from that, it's the same idea, and it makes the ISA largely irrelevant for the same reasons.
If it is a simple concatenation, then I see your point, and I agree that the CISC instructions are problematic. However, a future rev of the Pentium could conceivably do things like register renaming once, and store the result in the trace cache, making that operation essentially free.
In effect, there's no reason the chip couldn't do more and more of the work of the compiler. That's essentially what Transmeta did.
However, why can't I store something on the stack for a long time? Push...do a million things...pop. As long as I don't overflow the stack in the mean time, I can store things there as long as I want. Overflowing the stack is a matter of register pressure, which affects non-stack-based ISAs too.
These should get translated into the appropriate u-ops. Bingo, no problem. This is spilling. I'll grant you that one.Your best example was the FP stack. However, does that not internally become traces that can access the FP registers in arbitrary ways? Can the traces not eliminate extra spills, dups, swaps, and other artifacts of stack-based computation? If it doesn't currently do so (which would surprise me) then I would expect that a future version of the Pentium certainly could.
I say the ISA is almost irrelevant because the compiler's optimizations occur with RISC-like instructions, and then the actual execution (u-ops) occurs with RISC-like instructions. The CISC ISA doesn't actually do anything except communicate the former to the latter. Certainly there is overhead for translating the ISA to u-ops, but hot code is usually executed many times, and so the translation cost is amortized over a large number of iterations, making it negligible.
AMD's whitepapers on x86-64 claim that the x86 ISA is a good one for their moden processors because they get the code density of CISC with the register usage and ABI models of RISC. Clearly they may be biased because they have a technology to promote, but I think their arguments have merit.
Perhaps you could give an example of how the P4's internal u-op traces are sub-optimal because of the CISC ISA?
The only advantage left to the compiler is complex dataflow analysis, etc., and that can be done just fine with CISC instructions. Compiler intermediate representations are RISC-like anyway.
Thus, the combination of optimizing compilers plus P4's trace cache makes the ISA almost irrelevant. Even the lack of general-purpose registers can be largely made irrelevant by the trace cache.
(Translation: the whole system is now so complex that it's nearly impossible to tell what effect a change may have. :-)
Look again. M-W has both pronunciations.
The Walking With X series is a dramatization of a modern nature show using the best available facts. I think you're taking it way too seriously. You might as well criticize Jurassic Park.
If you have any other examples, I'd be interested to know what they are. Otherwise, you have simply jumped to a broad, unfounded conclusion about "most pre-history books and television shows" from a single work of science fiction. That may explain people's reaction.
You, in particular, could use it like this:
Big-O has a specific meaning. If it doesn't match what you're trying to say, then just don't use it.
Also, the PDF seems to be broken. It won't display on my system. (Anyone else have that problem?)
Overall, pretty impressive.
The version on the USENIX site seems at least to have the correct spelling in the title, but you need a password to download the PDF there.
According to your logic, we should all stop using libraries like glibc and write our own routines for string manipulation, file manipulation, etc. for each program we write; and in so doing, the system of programs as a whole would become more robust because every bug would be confined to one program.
The fallacy here is that by re-implementing the same functionality repeatedly, the chances of having a bug increase at least as quickly as the number of implementations. In practice, it is likely to increase much more quickly, because each implementation is getting less exercise.
I would much prefer a single implementation of some given functionality shared among dozens of programs. It would be exercised much more heavily, making bugs less likely for all the programs.
Code is unlike almost anything else: the more you use it, the better it works.
Thanks for the clarification, but I don't buy it. If BusyBox has a buffer overflow when argv[0] is set to, say, "vi", then that would be no more and no less damaging than if a regular system had a buffer overflow in vi.
What exactly is the failure scenario you're afraid of here?
I do know I can't stand a monitor refresh rate less than 70Hz though. However, that's not a motion blur issue. I don't know what issue that is.
I, for one, am reasonably confident that I could do a blind taste test and descern 60fps from 100fps. How?
The answer is motion blur. Real life has motion blur because your retinas don't react instantaneously. When an image moves rapidly across our retina, all the receptors between points A and B are stimulated. In contrast, video games don't yet do any motion blur. Therefore, you get a rapid succession of motionless frames. If the frames are far enough apart, some retinal receptors between A and B will not be stimulated. The effect is disorienting, and even sometimes a bit nauseating.
Did you see Gladiator? Remember how disorienting the initial battle scene was? That's because they used a technique to greatly reduce motion blur (effectively, to 12fps). It's the same effect, and if you get disoriented in a game, you lose.
Without actual motion blur, the best the games can do is crank the frame rate way up, and simulate motion blur with many, many frames rendered close together. The more frames you have per second, the more realistic the motion will appear.
On the bright side, if the poles flip, Earth's north pole will actually be a magnetic north.
Ok, well if that distinction is worth the extra $699 USD, to you, then go for it. I think I'll spend the money on another computer to use while the first one reboots.