the x86 instruction proprietary extensions: a waste of time, money and energy
by Johan De Gelas on December 6, 2009 12:00 AM EST- Posted in
- IT Computing general
Agner Fog, a Danish expert in software optimization is making a plea for an open and standarized procedure for x86 instruction set extensions. Af first sight, this may seem a discussion that does not concern most of us. After all, the poor souls that have to program the insanely complex x86 compilers will take care of the complete chaos called "the x86 ISA", right? Why should the average the developer, system administrator or hardware enthusiast care?
Agner goes in great detail why the incompatible SSE-x.x additions and other ISA extensions were and are a pretty bad idea, but let me summarize it in a few quotes:
So I fully support Agner Fog in his quest to a (slightly) less chaotic and more standarized x86 instruction set.
Agner goes in great detail why the incompatible SSE-x.x additions and other ISA extensions were and are a pretty bad idea, but let me summarize it in a few quotes:
- "The total number of x86 instructions is well above one thousand" (!!)
- "CPU dispatching ... makes the code bigger, and it is so costly in terms of development time and maintenance costs that it is almost never done in a way that adequately optimizes for all brands of CPUs."
- "the decoding of instructions can be a serious bottleneck, and it becomes worse the more complicated the instruction codes are"
- The costs of supporting obsolete instructions is not negligible. You need large execution units to support a large number of instructions. This means more silicon space, longer data paths, more power consumption, and slower execution.
Summarized: Intel and AMD's proprietary x86 additions cost us all money. How much is hard to calculate, but our CPUs are consuming extra energy and underperform as decoders and execution units are unnecessary complicated. The software industry is wasting quite a bit of time and effort supporting different extensions.
Not convinced, still thinking that this only concerns the HPC crowd? The virtualization platforms contain up to 8% more code just to support the incompatible virtualization instructions which are offering almost exactly the same features. Each VMM is 4% bigger because of this. So whether you are running Hyper-V, VMware ESX or Xen, you are wasting valuable RAM space. It is not dramatic of course, but it unnecessary waste. Much worse is that this unstandarized x86 extention mess has made it a lot harder for datacenters to make the step towards a really dynamic environment where you can load balance VMs and thus move applications from one server to another on the fly. It is impossible to move (vmotion, live migrate) a VM from Intel to AMD servers, from newer to (some) older ones, and you need to fiddle with CPU masks in some situations just to make it work (and read complex tech documents). Should 99% of market lose money and flexibility because 1% of the market might get a performance boost?
The reason why Intel and AMD still continue with this is that some people inside feel that can create a "competitive edge". I believe this "competitive edge" is neglible: how many people have bought an Intel "Nehalem" CPU because it has the new SSE 4.2 instructions? How much software is supporting yet another x86 instruction addition?
Facebook
Twitter
RSS
108 Comments
View All Comments
Zool - Wednesday, December 9, 2009 - link
"Branch Prediction is on average no worse than 50% correct (if it guessed randomly), but often well above 90%. Doing both branches would mean 2x the power use for as little as 5% more speed overall."Than my question would be why branch prediction,speculation on today AMD adn Intel cpu-s takes so much space from the core die. For the 5% more speed overal ?
The thing is that with 15 and more stage super-scalar pipelines the penalty is much more than 5%. It depend on how much branches the code actualy contains. But they cant count on this and need to make the performance balanced in both cases. IBM power5 and 6 have 14 stage pipelines, Intel Nehalem 16 stage pipeline and amd phenom (i could find it only for opteron which is the same) 12 stage integer/17 stage floating point.
Doing both branches doesnt seem such a bad idea if u would have a very simple core and you could forget branch prediction/speculation.
jensend - Sunday, December 6, 2009 - link
If they did that they'd have at least $100 billion in antitrust fines rather than $1 billion.Shining Arcanine - Sunday, December 6, 2009 - link
Just don't buy AMD processors until they abandon their extensions in favor of Intel's extensions. Problem solved.There is absolutely no reason for AMD to make proprietary extensions to x86 that contradict Intel's extensions. Intel made x86 and whatever competitive advantage there is to doing so is negated by the fact that they have so little market share that no one cares about optimizing for their hardware.
Targon - Saturday, January 9, 2010 - link
Some basic facts, since you seem to have missed several generations worth of processor development:Intel started trying to make AMD processors incompatible with certain applications by adding SSE. AMD responded with 3DNow. As time went on, Intel stuck with the idea of trying to make AMD processors not run certain applications or not run them well with new instructions over time, while AMD really didn't do it beyond the 3DNow! set.
The move from 32 bit to 64 bit processors in the home market is ALL due to AMD adding 64 bit instructions to the set of 32 bit instructions of the time. This was not a case of trying to make some useless set of instructions, but was a true desire to bring 64 bit processing to the masses while providing improved performance in 32 bit applications. If you want to kill all AMD extensions, then you kill 64 bit support since Intel copied AMD instructions. Intel 64 bit is Itanium, which is a failed platform, even if there are a handful of systems running it.
You can't blame AMD for the useless extra instructions when Intel is to blame.
Exophase - Sunday, January 10, 2010 - link
Many years ago, long before any of the "media extension" instruction sets came to be, a legal agreement was reached between Intel, AMD, and other x86 manufacturers that allowed them to freely implement any instruction set changes that the others made.Intel didn't make SSE to try to make AMD processors incompatible. You have the order backwards anyway - 3DNow! came first with AMD K6-2, while SSE wasn't available until the later released Pentium 3. Intel went with SSE instead of 3DNow! because it's a less limited design, not because they wanted to split the market. This is indicated by the fact that AMD eventually moved to SSE support instead of 3DNow!.
I don't think any of the extensions are useless, although they might appear that way to people who don't have particular use for them. They're added because Intel or AMD believes that enough people will benefit from them, and this belief is usually based on programmer feedback. If you look at the instructions and possibly do a little research then it's not hard to see applications where they would prove beneficial. That doesn't make the decision justified in the long run, but I don't think that they're keen on adding expensive execution functionality to their cores just so they can have something to advertise. If that were their angle they'd probably just start making things up.
Targon - Saturday, January 9, 2010 - link
Some basic facts, since you seem to have missed several generations worth of processor development:Intel started trying to make AMD processors incompatible with certain applications by adding SSE. AMD responded with 3DNow. As time went on, Intel stuck with the idea of trying to make AMD processors not run certain applications or not run them well with new instructions over time, while AMD really didn't do it beyond the 3DNow! set.
The move from 32 bit to 64 bit processors in the home market is ALL due to AMD adding 64 bit instructions to the set of 32 bit instructions of the time. This was not a case of trying to make some useless set of instructions, but was a true desire to bring 64 bit processing to the masses while providing improved performance in 32 bit applications. If you want to kill all AMD extensions, then you kill 64 bit support since Intel copied AMD instructions. Intel 64 bit is Itanium, which is a failed platform, even if there are a handful of systems running it.
You can't blame AMD for the useless extra instructions when Intel is to blame.
WaltC - Friday, December 11, 2009 - link
/[Just don't buy AMD processors until they abandon their extensions in favor of Intel's extensions. Problem solved.]/Or we could solve it by not buying Intel cpus until Intel decided to go with 100% AMD instruction extensions (I actually haven't bought an Intel cpu since 1999, btw.) To some extent, that's actually what happened with Core 2 64-bit Intel x86 cpus, isn't it? AMD's allowed them to use x86-64 all these years, and since Intel threw in the towel and just wrote AMD a $1.25B check, their new cross-licensing agreement provides Intel with at least 5 more years of x86-64 utilization in its cpus.
I don't think that "not buying" either company's cpus is any kind of a solution, seriously. Most people aren't going to do that because most people don't care what brand of cpu they buy in their box--they're buying box brand and price, primarily, and don't know or care about the differences in x86 cpus inside.
I sympathize with the programmer's point of view, here--I really do. Standardizing instructions certainly would make things simpler for the programmer. However, I'm also a firm believer in competition, and two heads are always better than one, imo. x86-64 was 100% AMD's invention, and Intel had to pick it up because it was so successful. OTOH, there've been Intel instruction set extensions which AMD has picked up for the same reason. So for all intents and purposes, there are extraneous x86 extensions made by both companies which programmers should pretty much ignore--unless they want to specialize for a particular cpu--which means they'll be limiting themselves to a smaller market--which means they probably won't do it.
I think that if both companies "agreed" on a particular set of extensions then it would limit innovation and future product improvement and introduce a lot of stagnation into cpu development. It would surely simplify things for programmers, but it would also slow down product R&D.
The problem here is we've got two distinct viewpoints: the cpu manufacturers' and the programmers', and they aren't necessarily the same at all. Conflicts like this are inevitable in a competitive cpu market. It isn't Intel versus AMD that we are really talking about, it's Intel and AMD versus programmers who naturally would prefer to have everything much simpler...;)
Calin - Tuesday, December 8, 2009 - link
Yes, AMD should no longer use the AMD64, 64-bit instructions and instead go with Intel's 64-bit instructions......wait, the Intel 64-bit instructions are AMD's 64-bit instructions
piroroadkill - Monday, December 7, 2009 - link
Oh, so I guess we wouldn't be using AMD64 then?Shut the hell up.
Shining Arcanine - Monday, December 7, 2009 - link
It is now known as Intel E64MT.Stop being a fanboy.