To: Patrick Gainer who wrote (3275 ) 10/28/1997 11:16:00 PM From: Justin Banks Read Replies (2) | Respond to of 14451
Patrick -MIPS is a sucessful *embedded* processor It sells more units, period. If you want to qualify it as an embedded processor, that's fine. Fact is, it's been chosen time and time again over Sparc, for lots of products. It has better price/performance than any Sparc chip on the market.SGI has had an utterly dismal track record with the R10k. First, it was late. Can you say NEC?Then, as a result, it had mediocre integer performance. This is true. AFAIK, MIPS has never been strong on int. That's not really relevant to our past target market. This is changing.Embarassingly, the other vendors using the chip (like SNI) actually got better integer performance than SGI, suggesting SGI's compiler technology was second rate. Or we're tuning for other aspects of importance? I'd pit SGI compiler technology (C/C++) against anybody else's. DEC's probably got everybody except Cray beat for Fortran, though.Finally, SGI announced the 275 MHz R10K in Jan 1996 and has yet to ship a part over 200 MHz. Which makes me think the R12K you refer to is that effort. No, the R12k will ship in the first part of 98, and is not just a clocked-up R10k. And when you talk about being competitive with the 600 MHz Alpha, you are, no doubt, referring to the 21164, which is DEC's equivalent of the R10k. There is zero chance the R12k @ 300 MHz will be competitive with the 21264, due in the first half of 1998 and likely to be at least twice as fast as the 300 MHz R12K. Comparing clock speed is meaningless. I will go out on a limb here and say that on popular benchmarks, the R12k as first introduced will compare *very* favorably with the 21264 on integer perf, and will beat it on fp. Not much else I can say to convince you, except wait.The facts are that SGI has slipped (like everyone else) behind DEC in the processor race and are not likely to catch up. I'm not denying DEC has a really good architecture, it's just too bad they starve it for memory and other i/o. Finally, your comments regarding SPARC are absurd. Sun has had faster boxes than SGI when measured using any integer or commercial benchmark since the introduction of the UltraSPARC. Bullfeathers. Comparisons showing UltraCreator3D beating Octane on CAD packages are silly marketing FUD. The only way Sun can beat an Origin on TPC is by using a cluster. Jeez, a Challenge XL or Origin kicks any comparably equipped Ultra box I can think of. Fact is, Sun is high on dope if they think they can ship a 600mhz part by next year. I know it, they know it, and I think you know it too. I think that they'd announce it with the apparent attempt to injure other vendors insulting. Here's someone else inside SGI's take on UltraCreator, for example : > SUN's white paper on UltraCreator claims that all of system memory > is available dynamically for TRAM that's because they do texturing on the host cpu. and it quite frankly sucks rocks when enabled. the guys at the sun demo booths at siggraph claimed they didn't know how to turn on texturing for their demos. i showed them, and much to their chagrin, they learned how pitifully the system performs with it turned on. The octane's tram is a texture "cache". if the intended app is smart, it won't matter that the maximum texture size is 4M (i.e. if it will do tiling, paging, etc of its own). when i asked the sun demo guy why the cpu was basically torqued out during the demo with lighting turned on, he said "well, no-one does anything else when they're doing graphics, so its okay." -justinb