Re:Mmm, content-free article...
on
Emergence of SMT
·
· Score: 1
Here's more information on another processor that does implement SMT....to handle network traffic.
(From Microprocessor Forum)
http://www.eet.com/story/OEG20001009S0061
The XStream core can execute eight instructions per cycle, the same as the two cores in SiByte Inc.'s Mercurian SB-1250 network processor implementation. In SiByte's case, however, each core is limited by the parallelism in the code. SiByte claims its cores each average about 1.5 instructions/cycle, after accounting for data dependencies and pipeline stalls. The simpler cores found in most network processors average less than 1 instruction/cycle.
The magic of SMT is that the XStream core issues instructions from up to eight threads at the same time. That is, the eight instructions per cycle could each come from different threads. Since each thread has its own register space, this eliminates data dependencies, keeping the issue rate high.
If one or more threads stall while waiting for memory, the chip can issue as many as four instructions from a single thread, keeping the core operating near peak efficiency. As a result, the XStream core averages about 6 instructions/cycle, Nemirovsky said, or twice the rate of the two SiByte cores combined.
XStream, however, did not disclose the clock speed of its core. While SiByte is pushing the leading edge at 1 GHz, most other network processor vendors are toiling at a few hundred megahertz. In the end, XStream's core may not execute significantly more instructions than SiByte's SB-1250.
In the article there's this paragraph: Now, let me just stop and say that a number of folks, in their effort to show that they've "seen it all before" and can't be taken in by the hype, have tried to compare Code Morphing to Alpha's FX!32 or to an emulation program like SoftWindows. Such comparisons are like comparing a MinuteMan missile to a bottle rocket. In this case, you should feel free to believe the hype; Code Morphing is cool. I'd have to say that code morphing has been around. One only needs to look at executor from ARDI. It dynamically recompiles 68k code into x86 code using an instruction generator. i think ardi has a whitepaper on this on their site. Besides that, there's not that much difference between FX!32 and code morphing from the software perspective except for the fact that Crusoe had more hardware support of fixups (via the shadow register file and the gated store buffer), FX!32 runs offline instead of dynamically, and the threshold for code generation is much higher (FX!32 translates based on profile info, Crusoe probably only translates when they're enough blocks to make the translatation overhead worthwhile.) In addition, there *has* been work doing dynamic recompilation. That's essentially what a JIT is. Or you can look at a paper in the 1998 ASPLOS proceedings. There's a paper there describing such a system (called Shogun, I think), unfortunately, the target arch didn't have all the crusoe's aforementioned hardware hooks, so the performance isn't quite as high. Even VMware has done this stuff before, well VMware started off as simOS, which did have a dynamic translation as well as interpreted mode. Its just that no one has integrated the translator and added the hardware hooks to make it as efficient.
Slashdot Mirror
Here's more information on another processor that does implement SMT....to handle network traffic. (From Microprocessor Forum) http://www.eet.com/story/OEG20001009S0061 The XStream core can execute eight instructions per cycle, the same as the two cores in SiByte Inc.'s Mercurian SB-1250 network processor implementation. In SiByte's case, however, each core is limited by the parallelism in the code. SiByte claims its cores each average about 1.5 instructions/cycle, after accounting for data dependencies and pipeline stalls. The simpler cores found in most network processors average less than 1 instruction/cycle. The magic of SMT is that the XStream core issues instructions from up to eight threads at the same time. That is, the eight instructions per cycle could each come from different threads. Since each thread has its own register space, this eliminates data dependencies, keeping the issue rate high. If one or more threads stall while waiting for memory, the chip can issue as many as four instructions from a single thread, keeping the core operating near peak efficiency. As a result, the XStream core averages about 6 instructions/cycle, Nemirovsky said, or twice the rate of the two SiByte cores combined. XStream, however, did not disclose the clock speed of its core. While SiByte is pushing the leading edge at 1 GHz, most other network processor vendors are toiling at a few hundred megahertz. In the end, XStream's core may not execute significantly more instructions than SiByte's SB-1250.
In the article there's this paragraph: Now, let me just stop and say that a number of folks, in their effort to show that they've "seen it all before" and can't be taken in by the hype, have tried to compare Code Morphing to Alpha's FX!32 or to an emulation program like SoftWindows. Such comparisons are like comparing a MinuteMan missile to a bottle rocket. In this case, you should feel free to believe the hype; Code Morphing is cool. I'd have to say that code morphing has been around. One only needs to look at executor from ARDI. It dynamically recompiles 68k code into x86 code using an instruction generator. i think ardi has a whitepaper on this on their site. Besides that, there's not that much difference between FX!32 and code morphing from the software perspective except for the fact that Crusoe had more hardware support of fixups (via the shadow register file and the gated store buffer), FX!32 runs offline instead of dynamically, and the threshold for code generation is much higher (FX!32 translates based on profile info, Crusoe probably only translates when they're enough blocks to make the translatation overhead worthwhile.) In addition, there *has* been work doing dynamic recompilation. That's essentially what a JIT is. Or you can look at a paper in the 1998 ASPLOS proceedings. There's a paper there describing such a system (called Shogun, I think), unfortunately, the target arch didn't have all the crusoe's aforementioned hardware hooks, so the performance isn't quite as high. Even VMware has done this stuff before, well VMware started off as simOS, which did have a dynamic translation as well as interpreted mode. Its just that no one has integrated the translator and added the hardware hooks to make it as efficient.