A New SSE Instruction Set: AMD Announces SSE5
by Ryan Smith on August 30, 2007 4:00 PM EST- Posted in
- CPUs
Unlike AMD's Lightweight Profiling Proposal, today we're not looking at an idea for a possible future, but instead a specification for something that will happen. While AMD is still soliciting feedback for their earlier proposal, as of today they are moving at full speed ahead with SSE5. A SSE5 software simulator should be released today that will allow developers to experiment with SSE5 optimized code and see how well it will perform, well over a year ahead of when they will be able to see real engineering sample processors to test their code on. 2008 and beyond will see SSE5 support coming to the GCC compiler, along with AMD's optimized software libraries. AMD is going through great efforts to spur the adoption of SSE5.
It bears mentioning that there exists some potential issues between now and then however. First and foremost is the 800lb gorilla: Intel. Under normal conditions Intel's support is critical for new extensions to take off, the only exception to that has been AMD64/x86-64, which came at a time when that specification was far better suited for the computing industry than Intel's own IA64 specification. Simply put, we believe AMD will be unsuccessful with SSE5 if Intel is unwilling to add it to their own processors; the performance improvements are important, but it's not an AMD64 situation where AMD has the influence and technical advantages to get what it wants. Without Intel's support developers will code for the least-common-denominator among the extensions, or worse will focus on any Intel-only extensions should the two CPU families further diverge, something that is more likely to result now due to AMD's failure to include full SSE4 support on Bulldozer.
There's also the issue of the all-important compiler. Although AMD will have SSE5 support in GCC, and likely in the Visual Studio Compiler too, Intel failing to support SSE5 at the hardware level will mean that they will also not include it with their compiler. Intel's compilers are near-legendary in their ability to optimize code in the right situations (and in snubbing AMD chips at times), with developers working on computationally intensive applications likely unwilling to move away from using Intel's compiler.
Finally there's AMDs own hardware issues. It's impossible to predict what their situation will be like in 2 years, but we are always more concerned about them than Intel due to AMD's operating position. SSE5 is reliant on Bulldozer, AMD will need to get Bulldozer out on time if they want SSE5 to launch without a hitch. A late CPU can lead to SSE5 missing a chance to get in to new software development cycles.
But with those warnings out of the way, don't take this as a disapproval of SSE5. We believe that this will be the most important extension to the x86 instruction set since SSE2, and the new instructions like MADD in particular can offer the kind of performance improvements AMD wants to hit while avoiding the need to increase clock speeds significantly and the problems that result from such. What such a performance increase will be on actual applications however is something we're going to have to wait on the delivery of Bulldozer silicon to find out.
Finally, this isn't the last announcement from AMD we will see on the subject of AMD's instruction set performance initiative. We're still waiting on the rest of the proposals for the Hardware Extensions for Software Parallelism to be released, at which point we'll have a better idea of how AMD is going to tackle thread-level parallelism in the next few years. AMD hasn't put a date on that, but we'd expect something before the end of the year.
17 Comments
View All Comments
redpriest_ - Thursday, August 30, 2007 - link
SSE5 is far more robust than SSE4.ltcommanderdata - Thursday, August 30, 2007 - link
I was wondering whether there are any copyrights to the SSE and MMX names that Intel owns? SSE was originally started as a polarized opposition to 3DNow!, but I think having both Intel and AMD developing something dubbed "SSE" without a unified standard will get very convoluted very quickly. Like an SSE4a that appears to be a superset of SSE4 but is actually exclusive and SSE5 being only a partial superset. I can only imagine what would happen if Intel decided to label their next instruction set "the real SSE5" or introduce a SSE6 that completely skips over AMD's SSE5.You know, one of the things I've found interesting is how there are little things that Intel and AMD are doing can be viewed as appealing to Apple. Intel's Penryn for example has their Super Shuffle Engine which improves SSE packing, unpacking etc. which can be viewed as an attempt to meet the functionality of the Vector Permute Unit in the G4e and G5. Similarly, the move to 3-operand SSE also seems like an appeal to Altivec programmers.
MikeyJ79 - Thursday, August 30, 2007 - link
If I remember correctly, when AMD put MMX instructions in their K6 processor. Intel tried to sue them, but AMD won out. I don't remember the specific details, but I believe that was the jist of it.rcc - Thursday, August 30, 2007 - link
You don't horn in on other companys' naming schemes etc. It's actually more likely that someone seeing SSE5 will think it's an Intel spec than an AMD spec. I really dislike the whole lawsuit happy system we have going, but AMD needs to be slapped for this one.DigitalFreak - Thursday, August 30, 2007 - link
It's just AMD marketing BS, trying to make themselves look like they are leading again, like in the x64 days, instead of following. I wouldn't be surprised in the least if this ended up being called something else by the time it finally arrives.Omega215D - Friday, August 31, 2007 - link
Like AMD64 for Intel is called EM64T? Despite their competitive nature they still license tech from each other here and there.crimson117 - Thursday, August 30, 2007 - link
How does this benefit AMD?Does appearing to be (or becoming) a specification leader give them an advantage; for example is it easier for their chip designers to use AMD-developed specs than Intel-developed specs?
It seems like this cannot be a low-cost endeavor.