SSE3 Technology In Intel Prescott

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."

Comments

sse?

[Anonymous Coward]

I was going to bitch about not defining SSE in the summary, but then I see it's not defined in the first page of the article either, so the poster probably is as clueless as me?

Re:sse?

[drgnvale]

From the article, top of the second page...
"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

[Drakon]

if the opteron is NOT all its hyped up to be, I'm never buying another x86 again.

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 as it needs to be ... Maybe

Re:the x86 is at a dead end

[PD]

Ummmmm, sure. Why do you care what processor you run on? Why would anyone other than an embedded systems guy care? Are you writing your code in assembler?

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

[Graelin]

All things being equal, you're right. But this is the real world. The underlying architecture plays a VERY important role, it's much deeper than "just the processor." I believe the OP was not referring to X86 processors themselves, but the entire platform.

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

[Synic]

yeah, where the heck is my terabyte modules for x86...??

Re:the x86 is at a dead end

[Anonymous Coward]

If x86 disgusts you so badly, why would you even consider an Opteron?

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

[OldMiner]

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.

Well, yes and no. How about I quote an article that vaguely touches on the matter? Here's a random article that came up when I searched for "microinstructions x86". 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, 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 (including (E)SP, even though it's ignored when POPA is called). 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 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. 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

[OldMiner]

The last time there was a major instruction set update was the Pentium Pro

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 performance. Near as I can tell, this addition is no more or less big than any of the other recent additions (MMX, SSE, SSE2).

And, as a matter of fact, the last large instruction set update would then have to be 286->386 when we gained 32-bit, protected mode, many new instructions, and several new forms of old instructions -- and even then, the protected mode features in the 386 already existed in the 286 for the most part.

Re:the x86 is at a dead end

[Glock27]

Itanium, Sparc, Power-series, etc. are designed from the start for high-performance, IT services.

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 least for the time being, yet it isn't substantially faster than Opteron (in fact, it is substantially slower than Opteron at integer ops). It is also far more expensive than Opteron will be.

x86 supports the latest memory technologies and front-bus speeds, and also the fastest graphics interconnects. Are any of the other "high performance" platforms supporting AGP 8x yet?

That's great, but x86 doesn't support "larger memories."

Repeat after me..."Opteron". You can say it.

Also, I think the Xeons can use some kind of bank switching approach (how quaint!) to address 16 GB of RAM, IIRC.

Re:the x86 is at a dead end

[Graelin]

So is x86 (P4, Xeon, Athlon, Opteron).

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 "Macintosh".

For some reason I ommited Apple, I don't know why. Their hardware is usually of high quality and the platform is very fast. Makes for a great Linux server. I wish them luck with their server products but they need to get out of the desktop mindset with these machines. Nobody uses IDE/Firewire in a large production environemnt.

Only where 64 bit processing is necessary, and this is exactly where Opteron is aimed. Itanium is Intel's 64-bit solution, at least for the time being, yet it isn't substantially faster than Opteron (in fact, it is substantially slower than Opteron at integer ops). It is also far more expensive than Opteron will be.

Intel is ignoring market forces with this whole "You don't need 64 bit" thing. It doesn't really matter who is technically right. Intel is GIVING the low/mid end 64bit computing market to AMD. IMO, at least.

Repeat after me..."Opteron". You can say it.

Sure, Opteron gives you large memory access. You also get 64-bit registers and pipelines and so forth which should make applications somewhat faster.

My problem is, to meet today's demands the x86 platform has been "extended." Extended-Mode, Protected-Mode,SSE,SSE2,MMX,3d Now, and now "-64". Eventually, you have to stop bolting on and build something DESIGNED for the future. I think this is what Intel is trying with Itanium but they're not having much success at it.

Also, I think the Xeons can use some kind of bank switching approach (how quaint!) to address 16 GB of RAM, IIRC.

Yes it does, and you won't believe how crappy this "bold on" feels. The page switching is quite expensive, cycle wise, and your OS must now jump through hoops to keep track of it all. If none of this were a big problem, we'd all be happy with Real-mode.... Ahh the memories, A000:F0CC.

Re:the x86 is at a dead end

[Glock27]

My problem is, to meet today's demands the x86 platform has been "extended." Extended-Mode, Protected-Mode,SSE,SSE2,MMX,3d Now, and now "-64".

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 think this is what Intel is trying with Itanium but they're not having much success at it.

What I was trying to point out with my comment about Itanium is that Intel took a ground-up approach with Itanium, losing all that "x86 baggage". Yet, Itanic ended up using a huge die, and not being particularly fast.

Intel must be peeing itself over Opteron. ;-)

Prescott?

[Spudley]

Hmmm.... so Intel are naming their new processor after a British politician who's most noticable feature is that he's an overwight bully.

I wonder if they'll spot the irony in that?

Re:Prescott?

[kilonad]

I'm giving up mod points in here for this. They're probably naming it (oddly enough) after Prescott, Wisconsin. That's where the St. Croix River meets the Mississippi River, on the border of Wisconsin and Minnesota and is home to a National Scenic Waterway. Intel likes to name future processors after rivers and national parks.

Past examples: Tualatin River Basin, Katmai National Park & Preserve, Deschutes River, Coppermine River, Lake Tahoe, Klamath River, Covington River, Mendocino National Forest, Willamette River, Flagstaff River, Merced River. I'm sure there's others too.

Intel Prescott??

[rasteri]

Is this one going to punch journalists too?

Dual caching

[Jamesie]

But will it have dual Jag caches? Is it egg resistant and how many ppm (pies per minute) will it consume?