SSE3 Technology In Intel Prescott 17
topmo writes "X-bit labs has posted an article called 'SSE Technology in New Intel Prescott Processors.' In this detailed technology coverage they talking about the SSE (SSE3?) technology implemented in future Intel Prescott processors, its exciting history, its peculiarities and advantages offered to the software developers. Also they compare the cons and pros of the new PNI (Prescott New Instructions) with AMD x86-64."
Re:sse? (Score:3, Informative)
"And what is SSE? Before going further, let's recall the meaning of the abbreviations: SSE is Streaming SIMD Extension, SIMD is Single Instruction Multiple Data (several operands are processed by a single command)."
the x86 is at a dead end (Score:1)
It's a 20 year old architecture with backwards compatibility to 20 year old applications
The last time there was a major instruction set update was the Pentium Pro
If the Alpha was brought to todays manufacturing methods, it would still be the fastest chip on the planet. As it stands, I have high hopes for the Itanium, but I haven't seen much to impress me
Maybe that new beastly chip from IBM will be as impressive a
Re:the x86 is at a dead end (Score:1)
As long as the thing supports things like larger memories and larger integers, and as long as it continues to get faster, then the processor is completely irrelevant.
Re:the x86 is at a dead end (Score:5, Informative)
Itanium, Sparc, Power-series, etc. are designed from the start for high-performance, IT services. Would they make a great desktop? Who knows, probably not. Do they kick x86's arse in the server / workstation world? You betcha.
I agree with the OP that the x86 architecture is probably limited by it's high degree of backward compatibility. I don't have technical facts to back this up, but I think common-sense would agree with me here.
Now to contradict myself... It's important to note that Sparc has always been (and continues to be) backward compatible. I can run code from my SparcStation on an E10k and it will run exactly the same. In this way, the x86 platform is flawed. It was not designed for a lot of the tasks we need it to do TODAY. Sparc was, or they just got lucky, or both...
As long as the thing supports things like larger memories and larger integers, and as long as it continues to get faster, then the processor is completely irrelevant.
That's great, but x86 doesn't support "larger memories."
Re:the x86 is at a dead end (Score:2, Funny)
Re:the x86 is at a dead end (Score:5, Interesting)
Well, yes and no. How about I quote an article that vaguely touches on the matter? Here's a random article that came up [digit-life.com] when I searched for "microinstructions x86" [google.com]. It somewhat explains the issues (though the author doesn't seem to understand that floating point registers, MMX registers, and SSE registers are all general purpose registers for most purposes).
Ah, but my point. The x86 is natively CISC (Complex Instruciton Set Computer) which means instructions have variable length and variable arguments. (Of course, SSE and MMX are both SIMD and have instructions varrying from 2 to 5 bytes long, so they're working against the whole RISC idea, but they've got their own special units.) Meanwhile, the SPARC is RISC based. In short, it's easier to make a RISC processor run faster. But that might not matter so much.
x86 implementation of the present day is essentially a RISC processor on the back end. The native CISC instructions are transformed into micro-instructions. This transformation is done in a decoder. So long as that transformation can be done quickly and the micro-instructions well pipelined, the decoder unit shouldn't be too much of a killer.
Having said that, it's worth mentioning some of the strange things that the decoder has to dedicate silicon to. Some trouble instructions are problematic in more than one way, as noted previously with plex86 [slashdot.org], PUSHF which pushes the current CPU flags (e.g. interrupt flag (enabled/disabled), zero flag (last comparison equal/last sub result in a zero)) onto the stack is problematic. Then there are others which are just a bad idea. PUSHA is an old instruction which pushes all of the 386 general purpose registers on to the stack [dowling.edu] (including (E)SP, even though it's ignored when POPA is called [dowling.edu]). These instructions are those sort of useless instructions which came from the philosophy that computers should, on the lower level, start to emulate the higher level languages they're normally programmed in. That idea didn't pan out, especially as RISC became clearly superior. Another similar strangeness is found in XLATB [dowling.edu] which I haven't seen used in my natural life by a human nor a compiler, but is still supported in modern CPUs. That's not even to get into BCD instructions...
As it stands, though, last I checked what most hurt computer performance in real situations are cache misses and branch mispredictions. I have seen HP make a processor that was completely backwards incompatible that solved this problem [hp.com]. That is, it forced you to recompile all of your old code. It packed instructions around every branch which indicated the full length of both paths. Then both paths could be evaluated at a low cost, and the results of the untaken path thrown away. Other similar things were done to increase the success of cache prefetch and whatnot. Server only, of course -- no one wants a non-backwards compatible processor on their desktop.
But, back to the article which is about new instructions which will improve some processing intensive applications. However, the article notes, problems with branch misprediction are not solved in the new Intel chip. The processor will be clocked faster (and hence, so will the cache) so the problem may be a bit less noticable.
But therein is the
Re:the x86 is at a dead end (Score:2)
So is x86 (P4, Xeon, Athlon, Opteron).
Would they make a great desktop? Who knows, probably not.
I guess you've not seen that arcane computer called "Macintosh".
A little slow, but a definitely a nice computer!
Do they kick x86's arse in the server / workstation world? You betcha.
Only where 64 bit processing is necessary, and this is exactly where Opteron is aimed. Itanium is Intel's 64-bit solution, at
Re:the x86 is at a dead end (Score:2)
Not quite, P4 and Athlon are targeted at the home / desktop market. Xeon is targeted at low/mid range servers but is still 32 bit. Athlon MP was targeted at servers / workstations, and has been somewhat successful at it, but it pales in comparison to the Xeon. Where is my 8-way Athlon MP I was promised? Heck, even a 4-way? Happy hunting, you'll come up empty. The Opteron has great potential, but see below...
I guess you've not seen that arcane computer called "
Re:the x86 is at a dead end (Score:2)
Well, the SSE stuff (all that really matters at this point) is an extension and isn't too horrible to deal with. Opteron has SSE2, though I saw today that Intel may be shipping SSE3 soon. *sigh*
x86-64 is a fairly clean shot at extending x86 to 64 bit. Nothing wrong with that.
Eventually, you have to stop bolting on and build something DESIGNED for the future. I
Re:the x86 is at a dead end (Score:1, Interesting)
Maybe because it's fast, cheap, and runs all your software? (Because after all, YOUR software is important, but my software is 20 year old backward compatible crap.)
Face it, people like yourself is the reason that x86 is on top. Look in the mirror and see the enemy.
Re:the x86 is at a dead end (Score:2, Interesting)
Come again? I don't see where this statement is justified. IIRC, the Pentium Pro's significant additions were merely conditional moves, floating points compares whose result was put in the CPU flags, and fast system call instructions. Useful to a degree, but nothing revolutionary. Meanwhile, MMX and SSE2 both introduced about the same number of instructions which could potentially cause much larger increase in processor perfor
Prescott? (Score:3, Interesting)
I wonder if they'll spot the irony in that?
Re:Prescott? (Score:3, Insightful)
Past examples: Tualatin River Basin, Katmai National Park & Preserve, Deschutes River, Coppermine River, Lake Tahoe, Klamath River, Covington River, Mendocino National Forest,
Intel Prescott?? (Score:1)
Dual caching (Score:1)