I don't think you would have to do that. Couldn't you write a tool that just patches out the "be stupid if this is an AMD chip" code from an intel-compiled binary?
Intel's compiler would check for the presence of a feature (SSE etc.) and also for "GenuineIntel". So you could simply remove the latter part and it should work fine, I think.
You don't need to these days (since 2011) - there have been numerous benchmarks over the years showing ICC generate binaries that perform better than MSVC++ for AMD processors.
Afaict AMD is putting their compiler-engineering effort into trying to improve gcc performance on their chips, rather than starting a separate compiler project. They are a lot smaller than Intel, so I'm not sure they can spare the resources to build an AMD analog to Intel's icc.
On the other hand, Intels compiler does really dumb things with vanilla application code and has never performed better for any code I've ever written.
Number crunching workloads, or the narrow HPC niche in which it works on a workstation rather than a cluster but you still need maximum performance from it - some physicists, astronomers, and geneticists. It's a fairly small niche but they buy new CPUs more than other people.
According to this article, Zen has not taped out yet:
Devinder Kumar, AMD CFO :
Zen was a clean sheet design that started a few years ago. We are in the final stage of executing and you know the milestone that you want to hear us talk about is Zen taping out, which should be over the next several months, and then putting samples in the hands of our customers and then starting first full year of revenue in 2017. And by the way, because we have this reuse approach for cores, you will see us with Zen cores in the high-end desktops first and then the servers from our overall products standpoint.
This article omitted one interesting part of the story, which is how AMD led the way to the x86_64 architecture while Intel was attempting to migrate to a conceptually radical architecture in its own products (Itanium). As I understood it, AMD's success in the early 2000s was largely due to their leadership in 64-bit, and Intel had to play catch-up to adopt AMD's approach. (But when they did, they reclaimed the throne.)
AMD definitely did x86-64 better than the ill fated Itanic's reliance on fictional compiler magic that largely would never materialize, but I don't know how much of an edge of provided. It was still too early for 64bit to really provide any benefit and operating system support was weak. At least people I remember saw it for what it was- marketing. It happens that in the long term it ended up being the way to go, but at the time the Athlon64's were coming around there wasn't much point (for consumers at least). By the time 64bit came of age Intel had already buried AMD by a combination of foul play and legitimate innovation.
IMO AMD could compete because the manufacturing and design processes were still accessible enough that they could still produce chips with competitive performance without the massive amount of capital Intel invests in new designs today due simply to diminishing returns in processor performance. Nowadays the difficulty of new processes means that very very few foundries are capable of using the latest fabrication processes and Intel has a stranglehold on them. It's harder for AMD to play catch-up, because there is less slack for them to work with using the next-best-thing. Nowadays, all the money AMD could spend on innovating with genuinely new technology is instead spent trying to keep up just keep up, whereas before they had more breathing room.
There's a comparison to draw with the engine wars in Formula 1 in the 90s. The sport was in major trouble financially, because teams were spending gigantic sums of money chasing small gains in engine performance on the extreme tail end of diminishing returns. The small teams were imploding trying to keep up because while the performance delta might have only been a few horsepower between the big and small teams, those few extra horsepower had a big impact on how competitive you were. And engine development is astronomically expensive on the far side of the returns curve, so additionally even the big teams were outspending themselves trying to keep up with each other before they implemented rules changes to limit engine development.
They were able to lead with AMD64 because of their incredibly price/performance at the turn of the centry. Late 90s the K6x chips were breathing new life into Socket 7 motherboards and existing systems, and a couple years later the Athlon was saving peple a hundred or more dollars to get a system that outperformed the Pentium 4 and produced significantly less heat. This helped them grow their marketshare significantly, which meant when we needed 64bit computing, we had two viable companies to pick from, rather than one giant and one minor also-ran.
Intel still acted like they were the market dictator (which they weren't at that time) and said "IA64 is the way forward, dump x86!" This was astounding from Intel as for decades they had been the key drummer on the backwards-compatible drum, making sure each new x86 CPU could run the old existing code. Now suddenly they're saying dump decades of installed base. AMD took advantage of their increased marketshare and said, "Hey, we have a 64bit solution for x86 that keeps your old code, and lets you create 64bit code for the future without relearning a new, complicated architecture." IA64 was EPIC, meaning Extremely Parallel Instruction Computing. AMD64 was x86 with a whole new set of 64bit extensions but with x86 compatibility and familiarity, which is exactly what Intel did when they extended x86 into the 32bit world with the i386. Those two factors combined are why AMD64 became the defacto standard. Neither would have helped without the other.
EPIC - Explicitly Parallel Instruction Computing. See https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
That means that the compiler works out the parallelism rather than the CPU, which is meant to reduce the amount of silicon wasted on instruction decode/parallelism.
Yes, Transmeta was bought by Intel. x86, despite its quirks, does not seem to be holding back the hardware too much. The silicon for decode/ILP does a fantastic job.
Intel just liscenced their patents the same way that NVidia did. NVidia later hired much of the team and their Project Denver core is essentially the Efficeon 2.0.
Transmeta is more a traditional VLIW processor which is a bit different in some ways that EPIC. On an Itanium you're indicating to the chips that these N instructions can take place on the same clock cycle (even if they're spread out across multiple cycles in theory) and there are some nifty tricks with trying to reduce memory latency variability.
Transmeta had what's known as an exposed pipeline VLIW design. If you tell the multiplier to do it's thing and put the result in Register 6 then you can still read the previous value from register 6 until the multiplication is done. So you always need to recompile for each version of the hardware.
however, while yes the compiler does a lot of work, it's an entirely different method of programming than most coders are used to, which make it painful to change to.
The funny thing is, the number of people I've worked with (that should know better), who think Intel came up with x86-64, instead of Intel copying from AMD. And there was no way I could convince them otherwise.
"Anybody could put anything they want on the web -- doesn't make it true". Seriously, that is the response I got. Glad I'm not at that particular company any more.
Payments to a customer to not buy a competitor's product is a form of price fixing. Other Intel customers would then not know what the real market price was. They were therefore undermining AMD's opportunity without the market being able to take advantage of the price war between them.
Intel seems over-ripe for anti-trust action at this point. I think the government is codling them in all likelihood. This is not a technical issue, I suspect it is far more of Intel taking advantage of its strong political clout.
I remember the days of the Athlon X2 versus the Pentium 4...AMD was truly the king back then. Combined with nVidia producing an awesome AMD chipset (nForce), they were glorious days. Then AMD went weird and starting focusing on these dual-socket platforms instead of just improving their stand-alone CPUs...the Intel Core came out...and the rest is history. Sad really.
Later (~2006) I remember because the Athlon X2 was produced in limited numbers, and the eBay price went through the roof as people were trying to upgrade from single-core without replacing every other component in their system to jump to Phenom.
Not to mention first Duron processors, originally clocked at 600 MHz, that by shorting some bridges could run at 900 or even 1GHz, at this time there wasn't CPU that fast (customer grade) and that affordable. Other thing was bear dye that could be crushed while mounting heat sink. Later on I've got even more hands shaking while mounting heat sink on next generation Barton which could be overclocked from 2500+ to 3200+, ah old days.
The first heatsink I mounted was on a Athlon XP 2500+. To this day, I've never fried a CPU or let the magic smoke out, but it concerns me every time I mount a heatsink.
That CPU ran at 3200+ speeds for a few years, until I noticed the capacitors getting nasty.
I have a Core2 Quad 2.4GHz that I use as a small-ish home server. About half a year ago, the power supply died, and when I replaced it, I left the chassis open and noticed the CPU fan was no longer rotating.
At first, I was really scared, but the machine is running well to this day. On a hot day, the system log will show many messages about the CPU reducing its clock speed to prevent overheating, but that seems to work well enough. (The system, to be fair, mainly runs as a file and DNS server, so it is not exactly super-busy, but still. It might also help that the fan sits on top of a huge heatsink.)
> Other thing was bear dye that could be crushed while mounting heat sink.
A friend of mine did that once. Broke off the tiniest bit from the corner of the die while trying to mount the heatsink, but that killed the CPU. He had been saving money for that CPU for months and was understandably unhappy.
This article is a recounting of public story. The real truth is much more nuanced with enough internal reasons (AMD veteran here).
AMD made a lot of profits with the x86-64 (Opteron family) around 2004-2005. However, that got to managements head and there were a series of missteps:
* Inorganic growth: The company went from small teams with startup culture to larger teams with many projects. AMD went and acquired large teams from HP in Fort Collins and Sun in Boston (Millenium chip team) in one fell swoop. This slowed projects a lot while assimilating and learning to work together with very different cultures and methodologies.
* Mid-management from IBM: Since the company was growing larger, a bunch of VPs from IBM were hired. They tried to bring IBM style processes which will not work when you do not have a captive market like IBM and your competitor is Intel :)
* Too many projects: The people and management growth resulted in everyone wanting their own chip project instead of working on derivatives of existing projects. There were too many projects conceived, spent cycles on and then cancelled.
* Paid too much for ATI: Bought them for 5.4 billion in 2006 when they could have waited till 2008 and bought them for 1 billion :) They had to write off most of the ATI value off their books and took charge for it.
> Paid too much for ATI: Bought them for 5.4 billion in 2006 when they could have waited till 2008 and bought them for 1 billion :) They had to write off most of the ATI value off their books and took charge for it.
But was it really that predictable back in 2006?
2008 sounds like the year when Intel killed 3rd party chipset market. Which, afaik, wasn't expected by anyone.
Ah, that was the year that happened? I still remember the dark ages of having to pick between one of several chipset manufacturers, each with their own sets of strange problems.
Really, I think moving to chipsets made by the CPU manufacturer was an overall improvement.
They stopped licensing the interfaces used to connect to the different parts together (north bridge <-> south bridge and north bridge <-> CPU) starting with Nehalem (first generation of Core i[N] processors).
This effectively meant that if you wanted to build a mainboard for Intel CPU's, you had to buy the chipsets from Intel as well.
Before that, you could buy mainboards with ATI (Xpress), nVidia (nForce), or VIA chipsets. All of these could integrate different SATA contollers, audio chips, USB busses, etc.
By not licensing their interfaces, Intel basically took over almost all of that market by locking others out of it. I believe they could only do this because they had no real competition from AMD anymore in the CPU market.
Yeah, I skimmed it and it looks mostly wrong, and you explain the outside observables:
AMD created an utterly dominating lead in server space in 2004-5, continuing the P6 microarchitecture approach while the Intel NetBurst (Pentium 4) microarchitecture failed when it coincided with the end of Dennard scaling (https://en.wikipedia.org/wiki/Dennard_scaling it might have worked if they'd been able to make the 5-10 GHz parts on the roadmap).
Plus the per chip on chip local memory controllers and Hypertransport ccNUMA approach scaled much, much better than Intel's one front side bus (all CPUs hitting the same northbridge memory controller).
Then, from the outside, AMD just sat on its laurels, giving Intel enough time to get their act together from all their self-inflicted wounds and take advantage of their process lead. The K10 microarchitecture was late, and shipments had to be paused due to a nasty TLB bug which didn't help their credibility. Intel's QPI copy of the Hypertransport ccNUMA concept shipping a year, year and half later was probably the final nail in the coffin.
I think it took until Bulldozer before they finally give up though, and part of the reason for that was FB-DIMM problems and DDR3 at first being more expensive. (Side note: it is unfortunate they didn't bother with 2Gbit DDR3 back in 2007 when Samsung and Elpida at least had prototypes of 2Gbit DDR2 back in 2006)
While I don't think the ICC situation was fair, I am not convinced that it played a big role in the story of AMD. Was ICC ever really used outside of niche markets, like HPC.
I would bet that most of the mediap layers at the time would have been using hand written assembler for the bits that really needed SSE.
There were notable instances of benchmarking suites being compiled with ICC. So even if most applications didn't exhibit the issue, reviews for AMD processors did. And it was a prominent enough issue that a tool was written to search your PC for software compiled with ICC and patch it to work correctly.
I wonder how western mentality can bend morality rules to always favor the underdog.
The "immoral" practices author accuses the Intel are developing favoring compiler and offering low prices and better deals to OEMs. Let me tell you something: when you give someone one billion dollars, you don't hold them on "ransom"; they're upholding an end of the deal that they voluntarily agreed to. And to lose money, to offer better prices, to get bigger market share is not something even remotely immoral.
Now, about compilers: Intel have never pretended that Intel compiler is supposed to work just as good with Intel as with other compiler manufacturers. It says so even in the marketing benchmark picture provided with the post. It was individual developer's decision: whether he wanted to get equal performance on different platforms, or whether he preferred to sacrifice performance on AMD in order to get more on Intel. Microsoft, Borland, gcc, LLVM and other compilers exist; if a developer choses Intel compiler instead, it's his decision to make his software to run slower on AMD. How is offering such an option immoral?
However, author completely glosses over the fact that AMD reverse-engineered Intel's product and released it's clone. To me, this actually seems like something not only immoral, but quite possibly, illegal, and definitely something worse than Intel's deeds. But of course, since AMD is smaller, it doesn't have to adhere to the same moral standard.
> And to lose money, to offer better prices, to get bigger market share is not something even remotely immoral.
I won't go into morality, but it can be illegal if it's considered predatory pricing.
If a company has an inferior product but uses its power and dominance of the market to prevent another company with a better product from being able to compete, then laws preventing this from happening are not about favouring the underdog but encouraging innovation.
As regards selling at a loss: if you do this with the aim of destroying or damaging your competition, so that in the future you may enjoy greater profits e.g. due to having a monopoly, then it is bad for society - the word immoral is not unreasonable. There exist laws that try to prevent this type of behaviour, because of the public harm it causes.
Not an expert, but if Intel were intentially crippling the performance of its compiler for AMD CPUs, i'd say that'd be inmoral. That's unfair competition.
If it's just that they didn't spend any time testing and optimizing for the competition's compiler, then... I'm not sure what to think of it, but I doubt i'd come out on the inmoral side of the argument.
They could do something even worse. They could just release a compiler which would actually NOT WORK on AMD processors, at all.
Compare it to modern mobile development. To develop to iOS, I MUST use xcode — no one has to use Intel compiler to run on Intel's x86. And said xcode doesn't compile to similar ARM chips for Android at all!
It wasn't just AMD, Intel was crippling performance on any non-Intel CPU. All x86 CPUs have an instruction, CPUID, that allows you to check for the presence of various features and instruction sets (MMX, x86-64, SSE, etc.). The standard way to generate backwards-compatible code which uses newer instructions is to check the flag, and run the version with the new feature if the flag is there, otherwise use older instructions.
Intel, though, would not only check if the CPU supported a feature, but also if the CPU was made by Intel. Essentially, Intel's compiler would generate code like "if Intel, run fast, if not Intel, run slowly."
> The "immoral" practices author accuses the Intel are developing favoring compiler and offering low prices and better deals to OEMs.
The immoral practices are literally bribing OEMs with money, active sabotage in code generation, and selling products below cost.
This isn't merely a "favoring compiler" and "low prices".
> Now, about compilers: Intel have never pretended that Intel compiler is supposed to work just as good with Intel as with other compiler manufacturers. It says so even in the marketing benchmark picture provided with the post.
Of course it's not guaranteed to work super well on AMD chips. But Intel deliberately wrote their compiler to produce code that would behave awfully on AMD processors. The code the Intel compiler generated would usually work fine on AMD (try it!), but it specifically included a check for Intel processors to ensure it didn't.
Also, Intel didn't warn their customers of this. There's a disclaimer that it's not optimised for other vendors' chips, sure, but that's not the same. Of course their compiler wouldn't be quite as efficient for AMD chips (it might not include AMD-only instructions), but they didn't warn customers that the compiler would deliberately only work on Intel chips. Customers who didn't inspect the output of the compiler would have no idea that Intel was sabotaging their application's performance.
> However, author completely glosses over the fact that AMD reverse-engineered Intel's product and released it's clone.
Originally, yes. So did several other companies. So? Clean-room reverse engineering is fine, in fact it's necessary for competition. Companies should not have complete monopolies on a good idea.
The compilers sppecifically chose the slowest code paths for non-Intel chips, even when you chose to compile with those features for AMD when using Intel hardware. You can still download those versions to check the results.
Also, price fixing was just one tactic used. Intel created exclusive contracts by threatening smaller chip makers with supporting their competitors if they shared technology with AMD, then later removed their products from their chipsets. Intel wasn't just trying to hurt AMD, they were systemmatically grooming a weakened marketplace that they could more easily dominate.
Intel brings such conflicting emotion for me. On the one hand, this sort of behaviour is appalling. But on the other hand, their quality control, validation, longetivity at the front is awe-inspiring.
> However, author completely glosses over the fact that AMD reverse-engineered Intel's product and released it's clone.
AMD was chosen by Intel and IBM as second source for 8088 processors, and entered a decade-long patent sharing agreement. How shockingly immoral, indeed.
> quite possibly, illegal
Intel tried to sue them when the agreement ran out. The courts deemed it otherwise – clean room reimplementations are neither illegal nor particularly immoral.
I am, naively thinking, may be we have hit the wall of single threaded performance, Skylake wasn't that much difference, even though i believe with some compiler optimisation and recompiling some software may get another 10% benefits.
We could run at higher clock frequency, but CPU will heat up.
And when most of the world don't need high performance PC any more, may be AMD do stand a chance this time around. As long as ZEN is within 10 - 15% of Intel's performance. They have lots of head room to work in the Server CPU sector. And their APU in the lower end.
The problem with AMD is they have never been good with execution, so while even on paper Zen is good, AMD will likely mis position their product, fail to market it, or likely fxxked up by GF production issues.
> And when most of the world don't need high performance PC any more
Well, that is because we do have very high performance PCs these days. Somewhere on Wikipedia, there is a quote by somebody (I forget who...), that a supercomputer is a device for turning a CPU-bound problem into an IO-bound problem. By that definition, even modest PCs these days are supercomputers for the majority of programs ordinary people run on them.
a supercomputer is a device for turning a CPU-bound problem into an IO-bound problem
Heh. I remember a tale from the days of the early generation Crays, where they were showing one off to an IBM guy, who said, yeah, impressive, but what about I/O? So a Cray guy ran something and got all the tapes to moving. The IBM guy was unimpressed until they pointed out they were writing data to all of them.
At least in those days the problem was understood, don't know about current supercomputers, but as I understand it one of the things that makes them expensive is their board to board interconnects, so I doubt they neglect I/O at the same time.
This seems to be missing some of the technical merits of Intel's failure and rebirth:
Downturn: The heat- and power-intensive single-core Pentium 4s, and the stillborn & binary-incompatible IA64/Itanium lineups that prevented them from competing on both the multicore and 64-bit AMD marketing bullet points
Rebound: Dedicated, efficient "premium" laptop chips in the Centrino lineup, to which AMD had no competitors, and which subsequently reunified with the P4's Hyperthreading, plus multicore, in the "Core" lineup/microarchitecture that debuted in the newly-Intel, no-longer-PowerPC Macbooks.
(I seem to remember hearing that Core-era Xeons were good, serverside: Nehalem definitely was, just afterwards)
67 comments
[ 3.0 ms ] story [ 127 ms ] thread[0] http://www.agner.org/optimize/blog/read.php?i=49#49
All high-perf code simply has to be meticulously performance tested; there's no other way to know on modern processors what is fastest.
Devinder Kumar, AMD CFO : Zen was a clean sheet design that started a few years ago. We are in the final stage of executing and you know the milestone that you want to hear us talk about is Zen taping out, which should be over the next several months, and then putting samples in the hands of our customers and then starting first full year of revenue in 2017. And by the way, because we have this reuse approach for cores, you will see us with Zen cores in the high-end desktops first and then the servers from our overall products standpoint.
Read more: http://wccftech.com/amd-confirms-zen-coming-highend-desktops...
IMO AMD could compete because the manufacturing and design processes were still accessible enough that they could still produce chips with competitive performance without the massive amount of capital Intel invests in new designs today due simply to diminishing returns in processor performance. Nowadays the difficulty of new processes means that very very few foundries are capable of using the latest fabrication processes and Intel has a stranglehold on them. It's harder for AMD to play catch-up, because there is less slack for them to work with using the next-best-thing. Nowadays, all the money AMD could spend on innovating with genuinely new technology is instead spent trying to keep up just keep up, whereas before they had more breathing room.
There's a comparison to draw with the engine wars in Formula 1 in the 90s. The sport was in major trouble financially, because teams were spending gigantic sums of money chasing small gains in engine performance on the extreme tail end of diminishing returns. The small teams were imploding trying to keep up because while the performance delta might have only been a few horsepower between the big and small teams, those few extra horsepower had a big impact on how competitive you were. And engine development is astronomically expensive on the far side of the returns curve, so additionally even the big teams were outspending themselves trying to keep up with each other before they implemented rules changes to limit engine development.
Intel still acted like they were the market dictator (which they weren't at that time) and said "IA64 is the way forward, dump x86!" This was astounding from Intel as for decades they had been the key drummer on the backwards-compatible drum, making sure each new x86 CPU could run the old existing code. Now suddenly they're saying dump decades of installed base. AMD took advantage of their increased marketshare and said, "Hey, we have a 64bit solution for x86 that keeps your old code, and lets you create 64bit code for the future without relearning a new, complicated architecture." IA64 was EPIC, meaning Extremely Parallel Instruction Computing. AMD64 was x86 with a whole new set of 64bit extensions but with x86 compatibility and familiarity, which is exactly what Intel did when they extended x86 into the 32bit world with the i386. Those two factors combined are why AMD64 became the defacto standard. Neither would have helped without the other.
Anyone remember Transmeta?
Transmeta had what's known as an exposed pipeline VLIW design. If you tell the multiplier to do it's thing and put the result in Register 6 then you can still read the previous value from register 6 until the multiplication is done. So you always need to recompile for each version of the hardware.
however, while yes the compiler does a lot of work, it's an entirely different method of programming than most coders are used to, which make it painful to change to.
Intel seems over-ripe for anti-trust action at this point. I think the government is codling them in all likelihood. This is not a technical issue, I suspect it is far more of Intel taking advantage of its strong political clout.
Later (~2006) I remember because the Athlon X2 was produced in limited numbers, and the eBay price went through the roof as people were trying to upgrade from single-core without replacing every other component in their system to jump to Phenom.
That CPU ran at 3200+ speeds for a few years, until I noticed the capacitors getting nasty.
At first, I was really scared, but the machine is running well to this day. On a hot day, the system log will show many messages about the CPU reducing its clock speed to prevent overheating, but that seems to work well enough. (The system, to be fair, mainly runs as a file and DNS server, so it is not exactly super-busy, but still. It might also help that the fan sits on top of a huge heatsink.)
A friend of mine did that once. Broke off the tiniest bit from the corner of the die while trying to mount the heatsink, but that killed the CPU. He had been saving money for that CPU for months and was understandably unhappy.
AMD made a lot of profits with the x86-64 (Opteron family) around 2004-2005. However, that got to managements head and there were a series of missteps:
* Inorganic growth: The company went from small teams with startup culture to larger teams with many projects. AMD went and acquired large teams from HP in Fort Collins and Sun in Boston (Millenium chip team) in one fell swoop. This slowed projects a lot while assimilating and learning to work together with very different cultures and methodologies.
* Mid-management from IBM: Since the company was growing larger, a bunch of VPs from IBM were hired. They tried to bring IBM style processes which will not work when you do not have a captive market like IBM and your competitor is Intel :)
* Too many projects: The people and management growth resulted in everyone wanting their own chip project instead of working on derivatives of existing projects. There were too many projects conceived, spent cycles on and then cancelled.
* Paid too much for ATI: Bought them for 5.4 billion in 2006 when they could have waited till 2008 and bought them for 1 billion :) They had to write off most of the ATI value off their books and took charge for it.
But was it really that predictable back in 2006?
2008 sounds like the year when Intel killed 3rd party chipset market. Which, afaik, wasn't expected by anyone.
Really, I think moving to chipsets made by the CPU manufacturer was an overall improvement.
Can you explain on this? By producing chipsets itself/any specific product?
This effectively meant that if you wanted to build a mainboard for Intel CPU's, you had to buy the chipsets from Intel as well.
Before that, you could buy mainboards with ATI (Xpress), nVidia (nForce), or VIA chipsets. All of these could integrate different SATA contollers, audio chips, USB busses, etc.
By not licensing their interfaces, Intel basically took over almost all of that market by locking others out of it. I believe they could only do this because they had no real competition from AMD anymore in the CPU market.
AMD created an utterly dominating lead in server space in 2004-5, continuing the P6 microarchitecture approach while the Intel NetBurst (Pentium 4) microarchitecture failed when it coincided with the end of Dennard scaling (https://en.wikipedia.org/wiki/Dennard_scaling it might have worked if they'd been able to make the 5-10 GHz parts on the roadmap).
Plus the per chip on chip local memory controllers and Hypertransport ccNUMA approach scaled much, much better than Intel's one front side bus (all CPUs hitting the same northbridge memory controller).
Then, from the outside, AMD just sat on its laurels, giving Intel enough time to get their act together from all their self-inflicted wounds and take advantage of their process lead. The K10 microarchitecture was late, and shipments had to be paused due to a nasty TLB bug which didn't help their credibility. Intel's QPI copy of the Hypertransport ccNUMA concept shipping a year, year and half later was probably the final nail in the coffin.
I would bet that most of the mediap layers at the time would have been using hand written assembler for the bits that really needed SSE.
The "immoral" practices author accuses the Intel are developing favoring compiler and offering low prices and better deals to OEMs. Let me tell you something: when you give someone one billion dollars, you don't hold them on "ransom"; they're upholding an end of the deal that they voluntarily agreed to. And to lose money, to offer better prices, to get bigger market share is not something even remotely immoral.
Now, about compilers: Intel have never pretended that Intel compiler is supposed to work just as good with Intel as with other compiler manufacturers. It says so even in the marketing benchmark picture provided with the post. It was individual developer's decision: whether he wanted to get equal performance on different platforms, or whether he preferred to sacrifice performance on AMD in order to get more on Intel. Microsoft, Borland, gcc, LLVM and other compilers exist; if a developer choses Intel compiler instead, it's his decision to make his software to run slower on AMD. How is offering such an option immoral?
However, author completely glosses over the fact that AMD reverse-engineered Intel's product and released it's clone. To me, this actually seems like something not only immoral, but quite possibly, illegal, and definitely something worse than Intel's deeds. But of course, since AMD is smaller, it doesn't have to adhere to the same moral standard.
I won't go into morality, but it can be illegal if it's considered predatory pricing.
If a company has an inferior product but uses its power and dominance of the market to prevent another company with a better product from being able to compete, then laws preventing this from happening are not about favouring the underdog but encouraging innovation.
Not an expert, but if Intel were intentially crippling the performance of its compiler for AMD CPUs, i'd say that'd be inmoral. That's unfair competition.
If it's just that they didn't spend any time testing and optimizing for the competition's compiler, then... I'm not sure what to think of it, but I doubt i'd come out on the inmoral side of the argument.
EDIT: s/disloyal competition/unfair competition/g.
They could do something even worse. They could just release a compiler which would actually NOT WORK on AMD processors, at all.
Compare it to modern mobile development. To develop to iOS, I MUST use xcode — no one has to use Intel compiler to run on Intel's x86. And said xcode doesn't compile to similar ARM chips for Android at all!
Intel, though, would not only check if the CPU supported a feature, but also if the CPU was made by Intel. Essentially, Intel's compiler would generate code like "if Intel, run fast, if not Intel, run slowly."
The immoral practices are literally bribing OEMs with money, active sabotage in code generation, and selling products below cost.
This isn't merely a "favoring compiler" and "low prices".
> Now, about compilers: Intel have never pretended that Intel compiler is supposed to work just as good with Intel as with other compiler manufacturers. It says so even in the marketing benchmark picture provided with the post.
Of course it's not guaranteed to work super well on AMD chips. But Intel deliberately wrote their compiler to produce code that would behave awfully on AMD processors. The code the Intel compiler generated would usually work fine on AMD (try it!), but it specifically included a check for Intel processors to ensure it didn't.
Also, Intel didn't warn their customers of this. There's a disclaimer that it's not optimised for other vendors' chips, sure, but that's not the same. Of course their compiler wouldn't be quite as efficient for AMD chips (it might not include AMD-only instructions), but they didn't warn customers that the compiler would deliberately only work on Intel chips. Customers who didn't inspect the output of the compiler would have no idea that Intel was sabotaging their application's performance.
> However, author completely glosses over the fact that AMD reverse-engineered Intel's product and released it's clone.
Originally, yes. So did several other companies. So? Clean-room reverse engineering is fine, in fact it's necessary for competition. Companies should not have complete monopolies on a good idea.
AMD's later designs were original, anyway.
Also, price fixing was just one tactic used. Intel created exclusive contracts by threatening smaller chip makers with supporting their competitors if they shared technology with AMD, then later removed their products from their chipsets. Intel wasn't just trying to hurt AMD, they were systemmatically grooming a weakened marketplace that they could more easily dominate.
This isn't true. Intel sold AMD a license and shared technical details. From wikipedia:
"In February 1982, AMD signed a contract with Intel, becoming a licensed second-source manufacturer of 8086 and 8088 processors."
https://en.wikipedia.org/wiki/AMD#IBM_PC_and_the_x86_archite...
AMD was chosen by Intel and IBM as second source for 8088 processors, and entered a decade-long patent sharing agreement. How shockingly immoral, indeed.
> quite possibly, illegal
Intel tried to sue them when the agreement ran out. The courts deemed it otherwise – clean room reimplementations are neither illegal nor particularly immoral.
Why shouldn't morality favor the underdog? The winner already has a natural advantage. Do we really want to make that permanent?
We could run at higher clock frequency, but CPU will heat up.
And when most of the world don't need high performance PC any more, may be AMD do stand a chance this time around. As long as ZEN is within 10 - 15% of Intel's performance. They have lots of head room to work in the Server CPU sector. And their APU in the lower end.
The problem with AMD is they have never been good with execution, so while even on paper Zen is good, AMD will likely mis position their product, fail to market it, or likely fxxked up by GF production issues.
Well, that is because we do have very high performance PCs these days. Somewhere on Wikipedia, there is a quote by somebody (I forget who...), that a supercomputer is a device for turning a CPU-bound problem into an IO-bound problem. By that definition, even modest PCs these days are supercomputers for the majority of programs ordinary people run on them.
[1] https://en.wikipedia.org/wiki/Ken_Batcher
Heh. I remember a tale from the days of the early generation Crays, where they were showing one off to an IBM guy, who said, yeah, impressive, but what about I/O? So a Cray guy ran something and got all the tapes to moving. The IBM guy was unimpressed until they pointed out they were writing data to all of them.
At least in those days the problem was understood, don't know about current supercomputers, but as I understand it one of the things that makes them expensive is their board to board interconnects, so I doubt they neglect I/O at the same time.
Downturn: The heat- and power-intensive single-core Pentium 4s, and the stillborn & binary-incompatible IA64/Itanium lineups that prevented them from competing on both the multicore and 64-bit AMD marketing bullet points
Rebound: Dedicated, efficient "premium" laptop chips in the Centrino lineup, to which AMD had no competitors, and which subsequently reunified with the P4's Hyperthreading, plus multicore, in the "Core" lineup/microarchitecture that debuted in the newly-Intel, no-longer-PowerPC Macbooks.
(I seem to remember hearing that Core-era Xeons were good, serverside: Nehalem definitely was, just afterwards)