AMD CPU speculation... and expert conjecture

[juanrga]

Ok, this is like the old SOI vs bulk discussion. I will not insist more in the issue of APUs and the death of discrete cards. I will leave future to meet us.

 

[blackkstar]

IPC is a theoretical number derived through means outside of real world measurement. It varies by compiler. You seem to think you can extract IPC via real world measurement and that will indicate what the CPU is capable of.

You don't address my concerns about your claims. I still have yet to see you address my claim about compilers not generating the same instructions for different CPUs and you somehow thinking that it's absolutely acceptable to assume both CPUs are following the same code paths and same instructions. We all know this, seeing compilers like ICC go as far as blatantly checking if a CPU's vendor string matches Intel's as opposed to checking the CPU's capabilities.

You also don't address the fact that Intel CPU performance based on compilers basically goes ICC > MSVC > GCC and AMD is basically GCC > MSVC > ICC.

Please address my concerns by doing more than attacking the weakest parts of my arguments by repeating the same talking points you always have while ignoring the rest of my arguments. I want to understand why you believe compiler adjustments are indicative of a CPU architecture's IPC.

 

[con635]

About one year ago I predicted that AMD would abandon discrete GPUs and replace them with APUs. I showed, with numbers, that future APUs will be much more powerful than dGPUs and that dGPUs will be killed by about 2020. I wrote an article on APUsilicon explaining why the APU is faster and giving details of the architecture of the future HPC APU that AMD engineers are designing. Well, AMD has just confirmed my thoughts

somehow i must be going blind, since what you are saying and what the slides are showing are two different things

'smooth and efficient transition from dgpu to soc', second slide its the title.

 

[cemerian]

About one year ago I predicted that AMD would abandon discrete GPUs and replace them with APUs. I showed, with numbers, that future APUs will be much more powerful than dGPUs and that dGPUs will be killed by about 2020. I wrote an article on APUsilicon explaining why the APU is faster and giving details of the architecture of the future HPC APU that AMD engineers are designing. Well, AMD has just confirmed my thoughts

somehow i must be going blind, since what you are saying and what the slides are showing are two different things

'smooth and efficient transition from dgpu to soc', second slide its the title.

but the dgpu is still present

 

[Ranth]

Spoiler

About one year ago I predicted that AMD would abandon discrete GPUs and replace them with APUs. I showed, with numbers, that future APUs will be much more powerful than dGPUs and that dGPUs will be killed by about 2020. I wrote an article on APUsilicon explaining why the APU is faster and giving details of the architecture of the future HPC APU that AMD engineers are designing. Well, AMD has just confirmed my thoughts

somehow i must be going blind, since what you are saying and what the slides are showing are two different things

'smooth and efficient transition from dgpu to soc', second slide its the title.

but the dgpu is still present

Shhhhh that's just a minor detail, just ignore it.

 

[con635]

The dgpu still being present is what enables the 'smooth and efficient transition'

 

[jdwii]

Ok, this is like the old SOI vs bulk discussion. I will not insist more in the issue of APUs and the death of discrete cards. I will leave future to meet us.

Well it does seem like a crazy claim and even i doubted it. But now seeing that Amd and Intel are making their APU's have bigger and bigger GPU's while the CPU is starting to get to 35% of the die space and soon we will be at 14-16nm starting to think different. Not only that but if HBM comes out smoothly without heating or throttling issues again i will think better towards it.

It's important to remember juan isn't the only one claiming this again linus torvalds also agree's and most possibly Nvidia and Amd engineers. My main issue is i want Nvidia to stay around in the PC market i wish they could make X86 CPU's. Perhaps Vulkcan API and Arm can help make Steam OS a great platform i know valve is powerful enough to really push for it.

Edit i also noticed that Amd chart features both APU and GPU which is still pretty good. We just have to find more ways to use both at the same time and make is useful for gaming and real work.

 

[Cazalan]

Ok, this is like the old SOI vs bulk discussion. I will not insist more in the issue of APUs and the death of discrete cards. I will leave future to meet us.

It's simple chart reading. In the first slide you have the red trapezoid indicating dGPU and the white trapezoid indicating APU. The chart goes through 2020 with both red and white trapezoid. To agree with your point the red trapezoid needs to be gone in 2020. That did not occur.

On the second chart it ends on the right with:
(1) dGPU
(1b) HPC APU
(2) APU
(3) Server CPU

To agree with your point the (1) needs to have disappeared, but it is still there.

APUs will continue to get more powerful but your one-size-fits-all super APU just doesn't gel with the ever increasing diversity of the marketplace. With DX12 being able to support dGPUs from multiple vendors the lock in is even less than before. You could now have an NVidia dGPU for Phyx support and an AMD dGPU for TrueAudio.

 

[Ranth]

To me it just doesn't add up, AFAIK GPU's are limited by die size and heat output right? If we for arguments sake say that our max cooling capacity for a given cooler is 150w how can a APU at 150W outperform a GPU at 150W + CPU at 150W? Or are we getting to a point (2020) where making GPU larger doesn't increase performance? Is that what people are claiming?

If they are going for efficiency I could see and APU, cutting away the longer connection, to be more efficient, but that doesn't replace GPUs does it? Also are we certain that those slides really are saying that GPU are going away or just that APU's are a new segment between APU and firepro :

 

[Cazalan]

Well it does seem like a crazy claim and even i doubted it. But now seeing that Amd and Intel are making their APU's have bigger and bigger GPU's while the CPU is starting to get to 35% of the die space and soon we will be at 14-16nm starting to think different. Not only that but if HBM comes out smoothly without heating or throttling issues again i will think better towards it.

They are making bigger APUs but there are also signs of slowing down too. We now have 2 generations of AMD APUs with 512 shaders for mainstream consumers. Intel went from 40 to 48 EU from Haswell to Broadwell. That's not much of an increase. It's economical not technical limits being imposed.

 

[-Fran-]

@Yuka, what is the title of the second slide? Can you see the arrow after the last dGPU? dGPU --> HPC APU

It says "SoC". A system on chip can be 98% GPU, 1% other stuff and 1% CPU for all we know.

And even though it has an arrow to the HPC APU, you can still see the "next gen GPU" trapezoid RIGHT ON TOP OF IT. <mod edit>

Cheers!

 

[Cazalan]

To me it just doesn't add up, AFAIK GPU's are limited by die size and heat output right? If we for arguments sake say that our max cooling capacity for a given cooler is 150w how can a APU at 150W outperform a GPU at 150W + CPU at 150W? Or are we getting to a point (2020) where making GPU larger doesn't increase performance? Is that what people are claiming?

There are some that believe the interconnect is the limiting factor, but that doesn't appear to be the case when it comes to graphics cards with large local memory pools. For HPC it can be much more important. We are seeing a divergence now in products for HPC (DP, 64bit) and products for gaming (SP, 32bit). Games don't need to be as accurate as nuclear simulations. Even FP16 is being used more as a means to increase performance. Gaming is a larger industry than HPC so who do you think will dictate the market more?

 

[Cazalan]

@Yuka, what is the title of the second slide? Can you see the arrow after the last dGPU? dGPU --> HPC APU

It says "SoC". A system on chip can be 98% GPU, 1% other stuff and 1% CPU for all we know.

And even though it has an arrow to the HPC APU, you can still see the "next gen GPU" trapezoid RIGHT ON TOP OF IT. <mod edit>

Cheers!

We largely only see what we want to see.

 

[juanrga]

@con635, yes, during the smooth and efficient transition period dGPUs will coexist, for legacy reasons, to target old customers. The first HPC APU will appear at 2016 (14nm) and will coexist with dGPUs up to 2018 and beyond (10nm), then about 2020 (7nm) there are only APUs.

This is the same smooth and efficient transition that Intel is doing just now with the Phi. The discrete card version of the KNL Phi only targets old customers of Xeon CPUs. New HPC systems like CORI don't use discrete cards anymore.

@jdwii, I read in some part that the CPU on Carrizo occupies the 12% of the whole die. On future designs the CPU occupies so little like 5% of die. You mention Nvidia engineers. I am preparing an article about Nvidia APU for HPC. The article will include the next quote from Nvidia engineers:

In this time frame, GPUs will no longer be an external accelerator to a CPU; instead, CPUs and GPUs will be integrated on the same die with a unified memory architecture. Such a system eliminates some of accelerator architectures’ historical challenges, including requiring the programmer to manage multi-
ple memory spaces, suffering from bandwidth limitations from an interface such as PCI Express for transfers between CPUs and GPUs, and the system-level energy overheads for both chip crossings and replicated chip infrastructure.

About x86, they mention both x86 and ARM in the documents. I will have to ask details about this.

 

[jdwii]

To me it just doesn't add up, AFAIK GPU's are limited by die size and heat output right? If we for arguments sake say that our max cooling capacity for a given cooler is 150w how can a APU at 150W outperform a GPU at 150W + CPU at 150W? Or are we getting to a point (2020) where making GPU larger doesn't increase performance? Is that what people are claiming?

If they are going for efficiency I could see and APU, cutting away the longer connection, to be more efficient, but that doesn't replace GPUs does it? Also are we certain that those slides really are saying that GPU are going away or just that APU's are a new segment between APU and firepro :

By people you mean professionals not average joes like people here. Also if a CPU uses 10% of the die space and consumes roughly 30-50watts who would care to manufacturer a card that offers 10% more die space and 50 watts more TDP? Then through in the fact of HBM memory and low latency access. This could potentially mean less information being transferred at once(currently a GPU works by loading up the vram to what the game needs).

Thus you can create a HSA type platform with extremely low latency compared to GDDR5 while doubling bandwidth. See why leading people in the industry are basically saying its over i'd like to see more myself of this but so far it seems to make a lot of since. Is 10% extra die space and WHAT 50 watts really needed once 7-10nm hits? Just not sure.

NOW that doesn't mean dGPU's will be gone we could still do SLI-Crossfire with it using some smart API's and programming skills.

Amd(soon with the 390X if rumors are true) and nvidia proved high performance can be had under a 200 watt TDP a I7 only takes 88 watts a 390X i think will use 200 watts or less having it built on once piece of silicon should even lower that a bit more.

 

[blackkstar]

I'm a bit more concerned about how those slides don't even reference desktop market. You know, that one that is larger than all consoles combined. It appears to be slides referencing HPC needs which someone is conflating into thinking it applies to AMD's entire product stack across all markets.

I feel a bit like we've seen someone take marketing slides for a specific market and then broadly generalize them to include the entire market and then make bold claims like "x86 will be finished in a few years, ARM will win." I wonder what happened to those claims, they seem to be gone from that forums and so are the signatures.

I wonder if some of you will address the fact that you mis-interpreted the IPC graphs to think they represent maximum potential hardware IPC as opposed to compiler performance on a specific architecture. I am still waiting and so far I am highly disappointed.

Or you will ignore those valid criticisms and instead move goal posts to a new topic like GPUs? I wonder what will happen? I don't know! It's like this has never happened in this forum before!

 

[Cazalan]

I feel a bit like we've seen someone take marketing slides for a specific market and then broadly generalize them to include the entire market and then make bold claims like "x86 will be finished in a few years, ARM will win." I wonder what happened to those claims, they seem to be gone from that forums and so are the signatures.

Yes there is a heavy dose of that going on. HPC products being in the $3000-$5000 range and talking about dGPUs in the $999 range, in the same breath. They are worlds apart.

 

[de5_Roy]

AMD Athlon X4 840 renders FM2+ platform even cheaper
http://www.fudzilla.com/news/processors/37266-amd-athlon-x4-840-renders-fm2-platform-even-cheaper

 

[jdwii]

I'm a bit more concerned about how those slides don't even reference desktop market. You know, that one that is larger than all consoles combined. It appears to be slides referencing HPC needs which someone is conflating into thinking it applies to AMD's entire product stack across all markets.

I feel a bit like we've seen someone take marketing slides for a specific market and then broadly generalize them to include the entire market and then make bold claims like "x86 will be finished in a few years, ARM will win." I wonder what happened to those claims, they seem to be gone from that forums and so are the signatures.

I wonder if some of you will address the fact that you mis-interpreted the IPC graphs to think they represent maximum potential hardware IPC as opposed to compiler performance on a specific architecture. I am still waiting and so far I am highly disappointed.

Or you will ignore those valid criticisms and instead move goal posts to a new topic like GPUs? I wonder what will happen? I don't know! It's like this has never happened in this forum before!

NO the reason why this compiler BS crap needs to be dropped is over it not being 2005 anymore. Gamer has disproved this statement over 20 times since the bulldozer thread was created no need to continue talking about it every 30 pages or so.

AND even if true WHO CARES if Intel was still better over compiler issues why buy a CPU that performs worse in those applications(basically any benchmark i ran it through).

I ask this again why buy a CPU that offers inconsistent performance that as well was ignored and forgotten.

 

[gamerk316]

IPC is a theoretical number derived through means outside of real world measurement. It varies by compiler. You seem to think you can extract IPC via real world measurement and that will indicate what the CPU is capable of.

Not really. All different compilers are going to do is adjust what an how many instructions get executed; that in no way affects how many instructions a CPU is capable of executing over a set period of time.

You don't address my concerns about your claims. I still have yet to see you address my claim about compilers not generating the same instructions for different CPUs and you somehow thinking that it's absolutely acceptable to assume both CPUs are following the same code paths and same instructions. We all know this, seeing compilers like ICC go as far as blatantly checking if a CPU's vendor string matches Intel's as opposed to checking the CPU's capabilities.

Compilers are very fine tuned to specific CPU architectures now, but at the end of the day, meaningful (>5%) gains more or less disappear after SSE2. So while different CPUs are going to execute different code, the difference in the performance result is negligible.

You also don't address the fact that Intel CPU performance based on compilers basically goes ICC > MSVC > GCC and AMD is basically GCC > MSVC > ICC.

False. I proved this the last time I showed compiler benchmarks. ICC for AMD was about 25% faster then MSVC, which was about 10% faster then GCC. Same spread as for Intel.

Granted, this was back in 2009, so the results may have swapped; I'd suspect GCC leapfrogged MSVC for both, but I don't have any recent benchmarks for easy comparison. But as of the BD launch, AMD saw its fastest performance using ICC. I'll dig up the link again if you don't believe me, but odds are, its buried in this thread somewhere.

Please address my concerns by doing more than attacking the weakest parts of my arguments by repeating the same talking points you always have while ignoring the rest of my arguments. I want to understand why you believe compiler adjustments are indicative of a CPU architecture's IPC.

Done and done.

To me it just doesn't add up, AFAIK GPU's are limited by die size and heat output right? If we for arguments sake say that our max cooling capacity for a given cooler is 150w how can a APU at 150W outperform a GPU at 150W + CPU at 150W? Or are we getting to a point (2020) where making GPU larger doesn't increase performance? Is that what people are claiming?

If they are going for efficiency I could see and APU, cutting away the longer connection, to be more efficient, but that doesn't replace GPUs does it? Also are we certain that those slides really are saying that GPU are going away or just that APU's are a new segment between APU and firepro :

You're all reading the slid title, and reaching a pre-conceived conclusion. All the title says is AMD is going to stop making dGPUs. It says NOTHING about APUs outperforming dGPUs.

Get it now? They're giving up against NVIDIA, and going to focus on low-end SOCs. This is farther evidence AMD is basically throwing in the towel.

 

[logainofhades]

AMD Athlon X4 840 renders FM2+ platform even cheaper
http://www.fudzilla.com/news/processors/37266-amd-athlon-x4-840-renders-fm2-platform-even-cheaper

It needs to drop a good deal more, if they hope to sell any. The 860k is between £56-£64, now.

http://uk.pcpartpicker.com/part/amd-cpu-ad860kxbjabox

 

[8350rocks]

Also, his IPC graph comes from a user at dragonflyBSD: http://leaf.dragonflybsd.org/~beket/geant4/dtrace.html

It includes such gems as modifying code and compiler to increase or decrease cache misses or hits and to increase IPC that way. Basically, that graph is about compiler optimizations and extracting more IPC from a CPU with compiler as opposed to measuring the hardware.

So, I don't really think this is about a chip's IPC, and it's more about extracting better IPC via software. which sort of fits into what the critics of IPC, CPI, etc have been saying in this thread. It's a useless metric that's mostly dependent on the software instead of the hardware.

Your link shows how "we can measure the cycles per instruction (CPI)" in section "2.1. Cycles per Instruction (CPI)" and uses as reference for that section a blog article that just agree with everything what I have been saying:

The cycles per instruction metric (sometimes measured as IPC – instructions per cycle) is a useful ratio and (depending on CPU type) fairly easy to measure. If the measured CPI ratio is low, more instructions can be dispatched in a given time, which usually means higher performance.

This is the maximum to be expected from the AMD64 architecture, which attempts to run three instructions per clock cycle.

Yeah, and the rest of the article is talking about making compiler adjustments in an OS that has significantly less market share than Linux. The three instructions per clock tick is the optimal goal that they are trying to achieve via compiler changes. It's theoretical.

The whole thing is basically "our version of amd64 is theoretically capable of 3 instructions per clock tick, how do we get our compiler to actually achieve that"

I suggest everyone else actually read the content I posted where Juan cites his thoughts on his graph and come to your own conclusions.

IPC, CPI, etc are all measurements that have a theoretical limit of the architecture and then their real world values depend on the compiler.

To make matters worse, the software they're using to measure is not a benchmark at all, it's a scientific simulation software used as a benchmark.

It's like I said previously yet you refuse to address. That graph is measuring how close the compiler can get to theoretically perfect IPC of an architecture. IPC is far more dependent on the compiler than the hardware.

Example is if a compiler poorly optimizes for caches of a certain CPU architecture and it constantly has cache misses, the IPC will be bad. It's not the CPU's fault, it's the compiler's.

I'm trying to help you understand the data you presented and you seem to not want to have anything to do with it. I hope that the others appreciate it.

IPC and all related measurements are simply a benchmark of the compiler and how well the compiler uses an architecture.

We have a real world example of this, compare CLANG/LLVM to GCC benchmarks (Phoronix does this quite often)

http://www.phoronix.com/scan.php?page=article&item=gcc49_compiler_llvm35&num=2

Same software, same hardware, different performance. Thus, by your argument, different IPC. The only variables changing here are the compiler. Look at GraphicsMagick, GCC 4.8.2 is almost twice as fast as CLANG in the same OS, same hardware.

It doesn't matter the software, hardware, or OS. All that matters is the compiler's quality and how well it can optimize for a certain architecture. CLANG is clearly not coming close to theoretical IPC limit of the 4770k in GM, and that benchmark has nothing to do with 4770k's instructions per clock, CPI, etc.

This is exactly the thing your IPC benchmarks are showing, yet you insist it has nothing to do with compiler at all and is all about the hardware.

IPC is strictly a compiler issue. If you want to talk IPC of a specific architecture, go create a perfect compiler that will extract the absolute best performance out of every relevant x86 CPU. I'll be waiting...

Also, you can safely ignore the time compilation benchmarks, they only benchmark how long it takes the compiler to generate code and are not relevant to this discussion.

The "performance" term in the basic CPU equation that I have given before applies to any piece of software. It doesn't have to be a "benchmark". The same applies to IPC. Moreover IPC is not a "measurement", as you claim, IPC is a computer science concept, and like any other concept it can either computed theoretically using a mathematical model of the CPU or measured on a piece of hardware. Engineers work with different analytical models and cycle simulators to predict the IPC of a given architecture before building it. Engineers don't work by trial and error approach.

It is untrue that "IPC is strictly a compiler issue". IPC also applies to non-compiled software measurements. Moreover IPC is a well-known aspect of hardware.

http://en.wikipedia.org/wiki/Instructions_per_cycle

As I have explained before >>here<<

One thing is the maximum IPC allowed by the architecture, another is the practical IPC obtained for a given workload, which depends of the programmer/compiler ability to extract all the potential from the architecture.

I illustrated the difference between maximum IPC allowed by a given AMD CPU and the average IPC obtained by a concrete piece of software running on the same AMD CPU >>here<<

Your example of cache illustrates the close relationship between hardware and software. One thing is the optimization that the compiler does of the cache resources of the CPU, but another thing is the specific hardware devoted to cache management. Compilers are not magic, they work pre-run and cannot predict the future; a compiler cannot predict with 100% accuracy what info will be on cache at a given time on a given branch of the code because has limited access to dynamic information. This is why modern CPUs devote hardware to cache management. An example are the hardware prefecthes, which try to identify data-patterns to load data on cache before the data is used. Those prefecthes work with regular and predictable data biut fail on irregular and impredictable loads. For this reason modern SS/OoO cores use the ROB and other related structures to hide the latency associated to impredictable cache misses.

I will add that most of Keller effort since his return is on cache management. He and his group have developed new hardware methods since 2012, including a novel stacked cache method. We will see how much of that is finally used in K12/Zen.

We don't need to create perfect compiler to talk about the IPC of a given architecture. We can say that Excavator provides 5% more IPC than Steamroller, that Haswell provides about 60% more IPC (integer) than Piledriver, and that the new A72 core has higher IPC than the core used in AMD Seattle.

You are asking me stuff I already addressed before. Moreover this is going off-topic and I will stop here, if you have some question that I have not addressed before send me a PM.

Juan, you are glossing over the fact that the compiler optimizations can make a massive difference in terms of the performance of the architecture. In fact, you are hand waving it away as irrelevant, when the crux of your entire argument is founded on the principle that IPC/CPI is some hardwired eventuality per software. However, a given compiler, if compiled for a generic x86 CPU will not necessarily give you the same benefits that compiling for a specific architecture would. Why would compilers like GCC even have architecture specific extensions if that was not the case?

You are a linux fanatic, and of all people, linux users should, typically, be well aware of the benefits of compiler optimizations. You can recompile programs in linux to take advantage of such optimizations and make your linux distro and software suite significantly faster, in some cases you are talking 50-100% improvements depending upon the software. So, I fail to see where that argument falls short of being justified.

As for the discussions about IPC with unlaunched architectures, your speculation is only that, speculation. There is no hard evidence, no ES benchmarks, no final silicon to give results. So, why not wait to see what actually happens?

Ok, this is like the old SOI vs bulk discussion. I will not insist more in the issue of APUs and the death of discrete cards. I will leave future to meet us.

I think you are reading too much into that for several reasons.

1.) That slide is talking about Firepro cards specifically. If you notice, the APU was positioned as a Professional SoC. I suppose that could make sense if they were going to basically try to go the apple route and lock people into a specific SoC for both CPU and GPU. I see this going poorly as, honestly, NVidia still holds the lion's share in professional realm because CUDA is so heavily entrenched in much of the industry there. The only way it is successful would require 2 things. The first thing is it must be cost effective to switch, and by cost effective I am talking software conversion, which AMD has little control over. The second would be performance, and it must be good. Performance would have to be so strong to have any impact that they would literally need to get a 390X sort of die on the SoC, and I do not see something that strong coming into play due to the physics and logistics alone.

2.) The consumer portion of that slide does not show anything being replaced. I am not sure what the current plans are for the professional GPUs, as I have not really been too tied up in that to be honest. I can however say that locking someone into an SoC is something you do if you own a large swath of the market share. If you do not own the majority, you want as much modularity with your product as possible. That way, even if they do not buy your CPUs, you can still get them to buy the GPUs. Which, in the professional space has been where they are most competitive, and that says a lot because they are still a relatively lesser percentage.

3.) For all out performance, these HPC APUs are not going to surpass a dGPU anytime soon.

 

[8350rocks]

You're all reading the slid title, and reaching a pre-conceived conclusion. All the title says is AMD is going to stop making dGPUs. It says NOTHING about APUs outperforming dGPUs.

Get it now? They're giving up against NVIDIA, and going to focus on low-end SOCs. This is farther evidence AMD is basically throwing in the towel.

I doubt that, the slide shows that they are looking at it for professional graphics solutions. The consumer area is not touched by this "HPC APU". Consumer dGPUs are going to be something they continue to focus on, AFAIK.

Now, what concerns me about this is the fact that this is almost a bigger sort of lock in than CUDA was, in and of itself. One of 2 things happens here: 1.) It takes off and pulls off a coup in the professional market, or 2.) It fails and dGPUs come back to salvage market share in the professional market.

They were making gains in workstation class market share recently, I am not sure why they would be going for a hard lock in. Especially knowing that software conversion is going to be the bigger hurdle than hardware.

 

[gamerk316]

Looking for compiler benchies; very few exist, but here's one from 2009:

http://keyj.emphy.de/compiler-benchmark/

ICC crushing it.

Only other one I could find that is meaningful:

http://www.g-truc.net/post-0372.html

GCC/LLVM/MSVC AMD v Intel. Breakdown is what you'd expect, or:

C2Q < PII X6 < Core i5
GCC < LLVM < MSVC

EDIT:

Give up; can't find anything run with an AMD CPU. Best one I could find, again for Intel:

http://willus.com/ccomp_benchmark2.shtml?p18+s14

Note the trend:

ICC 11 x64 > GCC 4.6.3 > ICC 11 x32 > MSVC 2010 x64 > MSVC 2010 x32 > GCC 4.6.3 x32.

EDIT2:

Found one. From 2006, but still:

http://www.principledtechnologies.com/Intel/CompComp.pdf

ICC 9.1 > GCC 4.1.1 for AMD.

 

[de5_Roy]

AMD Fiji is significantly faster than GTX 980
http://www.fudzilla.com/news/graphics/37275-amd-fiji-is-significantly-faster-than-gtx-980

Scythe Announces the Kodati Rev. B CPU Cooler with AM1 Support
http://www.techpowerup.com/210730/scythe-announces-the-kodati-rev-b-cpu-cooler-with-am1-support.html

edit: fixed ith the correct link. thanks, logain.