Thirteen New Instructions - SSE3

Back at IDF we learned about the thirteen new instructions that Prescott would bring to the world; although they were only referred to as the Prescott New Instructions (PNI) back then, it wasn't tough to guess that their marketing name would be SSE3.

The new instructions are as follows:

FISTTP, ADDSUBPS, ADDSUBPD, MOVSLDUP, MOVSHDUP, MOVDDUP, LDDQU, HADDPS, HSUBPS, HADDPD, HSUBPD, MONITOR, MWAIT

The instructions can be grouped into the following categories:

x87 to integer conversion
Complex arithmetic
Video Encoding
Graphics
Thread synchronization

You have to keep in mind that unlike the other Prescott enhancements we've mentioned today, these instructions do require updated software to take advantage of. Applications will either have to be recompiled or patched with these instructions in mind. With that said, let's get to highlighting what some of these instructions do.

The FISTTP instruction is useful in x87 floating point to integer conversion, which is an instruction that will be used by applications that are not using SSE for their floating point math.

The ADDSUBPS, ADDSUBPD, MOVSLDUP, MOVSHDUP and MOVDDUP instructions are all grouped into the realm of "complex arithmetic" instructions. These instructions are mostly designed to reduce latencies in carrying out some of these complex arithmetic instructions. One example are the move instructions, which are useful in loading a value into a register and adding it to other registers. The remaining complex arithmetic instructions are particularly useful in Fourier Transforms and convolution operations - particularly common in any sort of signal processing (e.g. audio editing) or heavy frequency calculations (e.g. voice recognition).

The LDDQU instruction is one Intel is particularly proud of as it helps accelerate video encoding and it is implemented in the DivX 5.1.1 codec. More information on how it is used can be found in Intel's developer documentation here.

In response to developer requests Intel has included the following instructions for 3D programs (e.g. games): haddps, hsubps, haddpd, hsubpd. Intel told us that developers are more than happy with these instructions, but just to make sure we asked our good friend Tim Sweeney - Founder and Lead Developer of Epic Games Inc (the creators of Unreal, Unreal Tournament, Unreal Tournament 2003 and 2004). Here's what he had to say:

Most 3D programmers been requesting a dot product instruction (similar to the shader assembly language dp4 instruction) ever since the first SSE spec was sent around, and the HADDP is piece of a dot product operation: a pmul followed by two haddp's is a dot product.

This isn't exactly the instruction developers have been asking for, but it allows for performing a dot product in fewer instructions than was possible in the previous SSE versions. Intel's approach with HADDP and most of SSE in general is more rigorous than the shader assembly language instructions. For example, HADDP is precisely defined relative to the IEEE 754 floating-point spec, whereas dp4 leaves undefined the order of addition and the rounding points of the components additions, so different hardware implementing dp4 might return different results for the same operation, whereas that can't happen with HADDP.

As far as where these instructions are used, Tim had the following to say:

Dot products are a fundamental operation in any sort of 3D programming scenario, such as BSP traversal, view frustum tests, etc. So it's going to be a measurable performance component of any CPU algorithm doing scene traversal, collision detection, etc.

The HSUBP ops are just HADDP ops with the second argument's sign reversed (sign-reversal is a free operation on floating-point values). It's natural to support a subtract operation wherever one supports an add.

So the instructions are useful and will lead to performance improvements in games that do take advantage of them down the road. The instructions aren't everything developers have wanted, but it's good to see that Intel is paying attention to the game development community, which is something they have done a poor job of doing in the past.

Finally we have the two thread synchronization instructions - monitor and mwait. These two instructions work hand in hand to improve Hyper Threading performance. The instructions work by determining whether a thread being sent to the core is the OS' idle thread or other non-productive threads generated by device drivers and then instructing the core to worry about those threads after working on whatever more useful thread it is working on at the time. Unfortunately monitor and mwait will both require OS support to be used, meaning that we will either be waiting for Longhorn or the next Service Pack of Windows for these two instructions.

Intel would not confirm whether the instructions can be used in a simple service pack update; they simply indicated that they were working with Microsoft of including support for them. We'd assume that they would be a bit more excited about the ability to bring the instructions to Prescott users via a simple service pack update, maybe indicating that we will have to wait for the next version of Windows before seeing these two in use.

Larger, Slower Cache Half-Time Summary
Comments Locked

104 Comments

View All Comments

  • INTC - Monday, February 2, 2004 - link

    Ummmm yea, kinda reminds me of cooking an egg on an Athlon XP http://www.biggaybear.co.uk/Menu/Aegg/Aeggs.html
  • cliffa3 - Monday, February 2, 2004 - link

    something good to include on the mb compatibility article would be what boards would house the 2.8/533...i'm wondering myself if the E7205 chipset would...i have a p4g8x, and it would be a welcome upgrade with HT and all the other goodies if it oc's well.
  • Stlr22 - Monday, February 2, 2004 - link

    They didn't burn down, but the proc were running hot. Not to mention, these are the FIRST releases in the Prescott line. What's it gonna be like later on?....

    Just think, a P4 based computer that turns your living room into your very own Sauna!!....WHOOO-HOOO!!.....now that's what I call a bargain!


  • INTC - Monday, February 2, 2004 - link

    The message is clear: Anandtech and all of the other review sites didn't burn down so I guess it's not a flame thrower.

    Prescott is not as fast as I had hoped but is definitely not the step backwards as some were rumoring it to be. I think a Prescott 2.8 @ 250 MHz FSB will be really nice to play with until I see what Intel announces at IDF in a few weeks.
  • Icewind - Monday, February 2, 2004 - link

    The message is clear: Im buying an Athlon 64.
  • Vanners - Sunday, February 1, 2004 - link

    Did anyone catch the error in Pipelining: 101?

    if you halve the time for a stage in the pipeline and double the number of stages. Yes this means you can run at 2GHz instead of 1GHz but the reality is you're still taking 5ns to complete the pipe.

    Look at it like a motorbike: You drop down a gear and rev harder; you make more noise but you are still doing the same speed.
    The only reasons to drop down a gear are to break through your gears (i.e. slow down) or to rev significantly higher than the change in gear ratio in order to move faster (with more torque).

    The trouble Intel has is that they drop down a gear then rev 6 months to a year later.
  • kamper - Sunday, February 1, 2004 - link

    Just curious, Anand or Derek: what board did you use to get the 3.72 GHz oc? Obviously it wasn't the intel board used in the benches. I guess we'll hear all about this in the compatibility review though :)

    keep up the good work, that last point about smaller margins at higher clockspeeds (vs. Northwood) was cool. Let's just hope the pattern continues.
  • Stlr22 - Sunday, February 1, 2004 - link

    Seems to me like people either got cought up in some of the hype and expected to much or some people expected to little and that history would repeat itself (Willamette vs Palomino)

    The fact that the Prescott fared much better in it's launch compared to the Willamette might be a hint to not underestimate it. Prescott isn't really looking bad now, and I think it will hit stride faster then the Willamette core did.

    The next couple of years are gonna be really interesting.

    Damn, ya just gotta love it!
  • ntrights - Sunday, February 1, 2004 - link

    Great review!
  • KF - Sunday, February 1, 2004 - link

    I've grown to appreciate CRAMITPAL. If you read around the opinionated diatribes, he has some good stuff that people avoid saying for fear of retaliation. I suppose if I were in love with Intel, he would tick me off.

    But, it does look like Intel has created a CPU that should ramp up to speeds high enough to beat the A64 in 32bit mode, and that is all they needed to do.

    Regardless of how much heat that is going to take, Intel must have some way in the works to handle it.

    Looks like they might not charge an arm and leg for it, which is the biggest shock.

Log in

Don't have an account? Sign up now