On Mon, Sep 14, 2009 at 6:07 PM, Nicolas Boulay <[email protected]> wrote: >>> So they use a core beside the cpu ? >> >> No. The only special hardware they have is texture decompression. > > It's a kind of load/Store unit on steroid ? It's a must to avoid > stupid bits move.
The determined that this was a worth-while co-processor. They wanted to make the hardware as general as possible, only adding specialized logic if it was a substantial improvement over software. This turned out to be the case here. >>> I think that the challenge is not in the performance of the chip but >>> how it's easy to use or not. >>> >> >> I'm tempted to make an argument that pushes off complexity into the >> compiler. But we've seen the negative effects of that a thousand >> times over (e.g. Itanium, Common Lisp). >> > > itanium use 2 or 3 bundle of 3 instructions. It's a lot compare to the > average ipc of 3 for a typical code. A LIW with 2 or 3 instructions > should not have the same issue. It could be a typical RISC pipeline, > with the fpu pipeline. The idea is to have the fpu used every cycle. Itanium's trouble wasn't about the way instructions were packed. It was that the processor is in-order and therefore requires the compiler to order the instructions optimally. Cache misses, however, make latencies nondeterministic, making it impossible for the compiler to do a perfect job of scheduling instructions. An OOO processor, which schedules dynamically, will do a better job. (Although it will require more hardware.) Also, Itanium partially relied on predication for its efficiency, but predication is notoriously difficult to use well by a compiler. After all these years, they STILL don't have a compiler that can use predication well. > If you use massive SMT technics, aren't you afraid of having more > muxes than fpu ? The idea is to round-robin the instructions from different threads. We don't need MUXes. Just tags indicating which thread the instruction is for. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
