AMD CPU speculation... and expert conjecture

[8350rocks]

^ you got some benchmarks to show Open64 is better than ICC/GCC ?

If ICC is so much faster...then why does AMD run ubuntu linux and it's affiliated software about 1.25-1.5x faster than intel?

Source ?


My source of Open64 VS GCC comparison is from several Phoronix articles in 2011/2010 . In those benchies, Open64 pretty much performed poorly on both AMD and Intel hardware , compared to GCC. IIRC, the tests were done on the Bulldozer hardware. Which means, GCC produced faster code than the Open64 compiler.

After that interest in Open64 pretty much vanished, as far as major news is concerned. If it has progressed, it hasnt made any news or major announcement.

BTW, i am not overly concerned with the beginnings of Open64. I am mostly concerned with how much it is in use, and how much better code does it generate.

You must have missed the part that I quoted above...

AMD supports Open64 as a complementary compiler to GCC

AMD open64 cannot be slower than GCC unless you don't set it up optimally, open64 has thousands of options to optimize your code generation for anything from very generic to very specific tasks. It is an architecturally adjusted, AMD optimized compiler...but that does not mean that you don't have to tell it what to do. AMD open64 can be a faster compiler than ICC if you "tune" it properly.

You must understand as well, that AMD has a list of optimizations to GCC to generate optimal code as well. GCC is an open source compiler, as well, so you could theoretically use whichever you want, and AMD recommends either one. They have a list of optimizations for GCC, and an entire compiler suite for AMD open64.

http://devgurus.amd.com/thread/113910

There's a thread from the AMD developer's website that offers a few pages with links from AMD that actually goes more in depth and shows some benchmarks running optimized open64 beating a GCC compiled program as well.

As far as how much it is in use...I would say anyone developing for AMD or using AMD hardware dev kits is likely compiling on either GCC or AMD open64, depending on preference. Those with an eye toward more control would likely use AMD open64, but GCC may very likely be the more common entity between the 2. You can use AMD open64 to compile for nearly any OS that is based on x86-64, much like GCC...I could not speculate as to what the penetration is...though I can say that AMD open64 is finding it's way into more and more dev kits since the AMD dev kits shipped for the upcoming consoles.

 

[8350rocks]

^ you got some benchmarks to show Open64 is better than ICC/GCC ?

If ICC is so much faster...then why does AMD run ubuntu linux and it's affiliated software about 1.25-1.5x faster than intel?

Source ?


My source of Open64 VS GCC comparison is from several Phoronix articles in 2011/2010 . In those benchies, Open64 pretty much performed poorly on both AMD and Intel hardware , compared to GCC. IIRC, the tests were done on the Bulldozer hardware. Which means, GCC produced faster code than the Open64 compiler.

After that interest in Open64 pretty much vanished, as far as major news is concerned. If it has progressed, it hasnt made any news or major announcement.

BTW, i am not overly concerned with the beginnings of Open64. I am mostly concerned with how much it is in use, and how much better code does it generate.

Quote:
Nvidia is also using an Open64 fork to optimize code in its CUDA toolchain.

Which explains why they work better with AMD compared to intel.

That quote is from a 2010 link.

Go to the present : https://developer.nvidia.com/cuda-llvm-compiler and http://www.anandtech.com/show/5238/nvidia-releases-cuda-41-cuda-goes-llvm-and-open-source-kind-of

NVIDIA's CUDA Compiler (NVCC) is based on the widely used LLVM open source compiler infrastructure.

(it would help if you researched beyond wikipedia.)

There is a LLVM fork of the open64 compiler...where was wikipedia wrong? They were accurate.

So far as I know, the most popular LLVM open source compiler is open64...especially considering Nvidia contributes to, and helps support, that particular version of the compiler...I would imagine they use it.

 

[mayankleoboy1]

AMD open64 cannot be slower than GCC unless you don't set it up optimally, open64 has thousands of options to optimize your code generation for anything from very generic to very specific tasks. It is an architecturally adjusted, AMD optimized compiler...but that does not mean that you don't have to tell it what to do. AMD open64 can be a faster compiler than ICC if you "tune" it properly.

Of course it can be. Because the open64 is forked/based on GCC 4.5/GCC4.6 version.
The latest GCC 4.7.3 is miles ahead of these old versions. In fact, GCC4.5 is EOL.
The basic problem with forking/basing is that you have to rebase and rebase your code continously to incluyse the latest branch from the mainline. Since GCC has (as a rough estimate) 100 times more contributors than Open64, GCC very very quickly marches ahead of Open64. So when it began, it was the same as GCC. Now, it is horribly old.

You must understand as well, that AMD has a list of optimizations to GCC to generate optimal code as well. GCC is an open source compiler, as well, so you could theoretically use whichever you want, and AMD recommends either one. They have a list of optimizations for GCC, and an entire compiler suite for AMD open64.

AMD has a list of options for AMD. They are called as bdver1, bdver2 and bdver3, nocona, barcelona(IIRC).
My point is that you set the max possible optimisation in GCC, and set the max possible optimisation in open64.
The GCC code will be faster in majority of applications.

http://devgurus.amd.com/thread/113910
There's a thread from the AMD developer's website that offers a few pages with links from AMD that actually goes more in depth and shows some benchmarks running optimized open64 beating a GCC compiled program as well.
As far as how much it is in use...I would say anyone developing for AMD or using AMD hardware dev kits is likely compiling on either GCC or AMD open64, depending on preference. Those with an eye toward more control would likely use AMD open64, but GCC may very likely be the more common entity between the 2. You can use AMD open64 to compile for nearly any OS that is based on x86-64, much like GCC...I could not speculate as to what the penetration is...though I can say that AMD open64 is finding it's way into more and more dev kits since the AMD dev kits shipped for the upcoming consoles.

open64 could be in PS4 and Xbawx720 SDK. But AMD hasnt yet made any announcement yet. And i hoghly doubt it. These days, the fastest compiler is LLVM and GCC.
Since LLVM is much more portable to be used as a backend, i think that the new console SDK's will be using a LLVM backend.

 

[mayankleoboy1]

So far as I know, the most popular LLVM open source compiler is open64..

The most popular LLVM open source compiler is LLVM itself.

especially considering Nvidia contributes to, and helps support, that particular version of the compiler...I would imagine they use it.

Yes, but they dont contribute to the mainline Open64 code tree. Which means, that Nvidia has a copy of the open64 code, and they keep on improving/customization it to suit their specific needs. BUT, they dont submit that code to the main O64 code tree.
Which means anybody who is not NV is using the stock, old code.

 

[8350rocks]

So far as I know, the most popular LLVM open source compiler is open64..

The most popular LLVM open source compiler is LLVM itself.

especially considering Nvidia contributes to, and helps support, that particular version of the compiler...I would imagine they use it.

Yes, but they dont contribute to the mainline Open64 code tree. Which means, that Nvidia has a copy of the open64 code, and they keep on improving/customization it to suit their specific needs. BUT, they dont submit that code to the main O64 code tree.
Which means anybody who is not NV is using the stock, old code.

That doesn't negate the fact that Nvidia is using source code from the open64 compiler to compile their CUDA drivers and software.

 

[JAYDEEJOHN]

http://support.amd.com/us/Processor_TechDocs/52128_16h_Software_Opt_Guide.zip

 

[juanrga]

AMD supports the open64 compiler with yearly updates for optimization (opensource). They do this so that not only windows, but also Sun, Linux, and other companies developing software, have a universal x86-64 compiler to use. So, while in the windows world it doesn't have a high penetration...this explains why ubuntu and sun operating systems run so much more efficiently on AMD...it's the equivalent of Intel's ICC advantage.

All of Ubuntu, from the kernel to Xorg to Unity to Firefox, all of it is compiled with GCC compiler, not with AMD Open64 compiler.

AMD open64 is an optimized version of GCC...it is a "complimentary optimized update" So, while AMD open64 = GCC, GCC does not necessarily = AMD open64

I tend to see open64 as a fork of GCC. I don't know what you mean by optimized version, but the GCC produces fastest code for AMD chips in many occasions. Check

http://openbenchmarking.org/result/1110214-AR-FXCOMPILE51

 

[mayankleoboy1]

Lets move on from Open64 performance. Most of the data we have is old .
When a new and uptodate dataset appears, lets begin this discussion again.

 

[8350rocks]

AMD supports the open64 compiler with yearly updates for optimization (opensource). They do this so that not only windows, but also Sun, Linux, and other companies developing software, have a universal x86-64 compiler to use. So, while in the windows world it doesn't have a high penetration...this explains why ubuntu and sun operating systems run so much more efficiently on AMD...it's the equivalent of Intel's ICC advantage.

All of Ubuntu, from the kernel to Xorg to Unity to Firefox, all of it is compiled with GCC compiler, not with AMD Open64 compiler.

AMD open64 is an optimized version of GCC...it is a "complimentary optimized update" So, while AMD open64 = GCC, GCC does not necessarily = AMD open64

I tend to see open64 as a fork of GCC. I don't know what you mean by optimized version, but the GCC produces fastest code for AMD chips in many occasions. Check

http://openbenchmarking.org/result/1110214-AR-FXCOMPILE51

Straight out of the box, sure, but AMD helps to tweak the source code for AMD open64 to allow the user to compile in the manner they prefer with the options to generate the fastest code being able to be adjusted based on your task at hand.

@mayan: I agree, the discussion has been had at this point, the next update to the compiler will arrive with steamroller. Though, I think with Raja Kudori returning to AMD, it wouldn't surprise me to see that the next compiler update is quite a bit better right out of the box. I expect Crossfire will be what he turns his attention to first though.

AMD is assembling some seriously good talent. Keller, Gustafson, Kudori....these are great engineering minds in their respective fields of expertise.

 

[mayankleoboy1]

@mayan: I agree, the discussion has been had at this point, the next update to the compiler will arrive with steamroller. Though, I think with Raja Kudori returning to AMD, it wouldn't surprise me to see that the next compiler update is quite a bit better right out of the box. I expect Crossfire will be what he turns his attention to first though.

uhh.. i meant something near, like when Phoronix publishes a new benchmarking article But lets leave it here.

 

[mayankleoboy1]

AMD is assembling some seriously good talent. Keller, Gustafson, Kudori....these are great engineering minds in their respective fields of expertise.

The hardware fruits of their labour will appear atleast after 2-2.5 years. The challenge for AMD is to remain competitive and profitable till then.

Software improvements could come sooner. Maybe 3-4 months even.

 

[8350rocks]

AMD is assembling some seriously good talent. Keller, Gustafson, Kudori....these are great engineering minds in their respective fields of expertise.

The hardware fruits of their labour will appear atleast after 2-2.5 years. The challenge for AMD is to remain competitive and profitable till then.

Software improvements could come sooner. Maybe 3-4 months even.

When steamroller releases in Q1 2014 for desktops, Keller will have been there 18-21 months. I am willing to bet he has already put his hands on this project, and since he was one of the fore most minds behind the K7/K8 architecture, AMD would be fools not to let him have free reign. We all know what kind of prosperity they enjoyed in the market place with that chip architecture.

I am betting that will be more than enough to remain competitive, and I would wager excavator is going to be something really special since he will basically be guiding that project from womb to tomb.

 

[JAYDEEJOHN]

Going by some rumors 20nm will be useless, this may be why
http://www.digitimes.com/news/a20130418VL200.html

 

[anxiousinfusion]

AMD is assembling some seriously good talent. Keller, Gustafson, Kudori....these are great engineering minds in their respective fields of expertise.

The hardware fruits of their labour will appear atleast after 2-2.5 years. The challenge for AMD is to remain competitive and profitable till then.

Software improvements could come sooner. Maybe 3-4 months even.

When steamroller releases in Q1 2014 for desktops, Keller will have been there 18-21 months. I am willing to bet he has already put his hands on this project, and since he was one of the fore most minds behind the K7/K8 architecture, AMD would be fools not to let him have free reign. We all know what kind of prosperity they enjoyed in the market place with that chip architecture.

I am betting that will be more than enough to remain competitive, and I would wager excavator is going to be something really special since he will basically be guiding that project from womb to tomb.

An Intel engineer cited that new hires would spend about four months with the company before they felt as though they were contributing anything. I'm pretty sure these guys don't get hired just to sit around and "adjust" for two years.

 

[mayankleoboy1]

Going by some rumors 20nm will be useless, this may be why
http://www.digitimes.com/news/a20130418VL200.html

Couldnt follow your reasoning.

 

[mayankleoboy1]

When steamroller releases in Q1 2014 for desktops, Keller will have been there 18-21 months. I am willing to bet he has already put his hands on this project, and since he was one of the fore most minds behind the K7/K8 architecture, AMD would be fools not to let him have free reign. We all know what kind of prosperity they enjoyed in the market place with that chip architecture.

I am betting that will be more than enough to remain competitive, and I would wager excavator is going to be something really special since he will basically be guiding that project from womb to tomb.

AFAIK, Excavator was designed before AMD hired Jim Keller. Now, i cant say if AMD had already designed excavator in every detail, or had they only decided that certain "check-box features will be present in excavator" , and left the actual, super low level details for later.
In any case, i am not sure how much Jim Keller's influence will be there.

An Intel engineer cited that new hires would spend about four months with the company before they felt as though they were contributing anything. I'm pretty sure these guys don't get hired just to sit around and "adjust" for two years.

That would be true for a low/mid engineer. For people like Jim, he would be contributing from the Day 1.

 

[JAYDEEJOHN]

The cost/benefit of 20nm , as theres been some complaints here and there, and with the onrush towards 16nm finfet within a year of 20nm...

 

[de5_Roy]

Going by some rumors 20nm will be useless, this may be why
http://www.digitimes.com/news/a20130418VL200.html

Couldnt follow your reasoning.

this is old news. going by my limited knowledge, i assume non-intel fabs are facing more problems fitting finfet into their roadmaps. they're also facing problems building 'real' full node shrinks (that's why the 14nm-'xm' stuff). i dunno if nodes for low power are easier to build or not... . since 28nm is roughly 2 years late, next nodes won't be any earlier (if current trend follows).

as for amd's new hires - software is obviously the easiest and earliest field to impact, more so than hardware which takes years to design. i think anandtech's assumption is more or less right. i'd also assume excavator has already been cancelled once and the new guys will likey put a new 'spin' on it. lame pun intended.

 

[mayankleoboy1]

this is old news. going by my limited knowledge, i assume non-intel fabs are facing more problems fitting finfet into their roadmaps. they're also facing problems building 'real' full node shrinks (that's why the 14nm-'xm' stuff). i dunno if nodes for low power are easier to build or not... . since 28nm is roughly 2 years late, next nodes won't be any earlier (if current trend follows)..

Say one thing for Intel, say they have the most advanced fabrication.
BTW, i read some time back that some fab (sammy or glofo or TSMC) are looking to skip a node, because its more technically advantageous to do so.

as for amd's new hires - software is obviously the easiest and earliest field to impact, more so than hardware which takes years to design. i think anandtech's assumption is more or less right

Where do you think i got my estimate from ?

 

[de5_Roy]

on the more positive note, we might see some really innovative hardware designs in upcoming years, to compensate for fabrication disadvantage. chances are amd, nvidia finally take power efficiency seriously and make some exciting new hardware instead of amd's bd/pd or nvidia's bifurcated kepler (sacrificed balance for perf/watt for each sector)...

edit: i don't think non-intel fabs have recovered from the setbacks they faced during transitioning from 45nm to 32nm yet (tsmc cancelled it's, glofo delayed and so on). i dunno exactly what happened but that's how it seems to me.

 

[JAYDEEJOHN]

Im taking it as, 20nm is just a showing, while everyone anticipates the 16nm finfet, which could mean 20nm may not have great designs, as theyll be compromised for 14nm finfet.
This is only IF the 14nm comes out on the heels of 20nm of course.
You can design for one node and switch it for another as weve seen lately, if the smaller nodes doesnt show up, not so sure about going to finfet tho from non finfet

 

[mayankleoboy1]

from what i have read on this forum and otherwise, design meant for one node take ~6months to be translated to a smaller node. In the world of semiconductoes, isnt that too much ?

 

[JAYDEEJOHN]

No, but the characteristics are beyond the norm going from planar to finfet.
If it were usual node to node shrink, it would be fine, but wringing out every bit of perf/power on any new design sets this in a whole new territory, as the fabs themselves will be in a larger learning curve, which makes collaboration more a guessing game than usual

 

[juanrga]

Steamroller would offer the best gaming cpu.

Why? Because eurogammer has done a poll among game developers and all them selected the FX-8350 as better for future gaming. This seems related to the chip being better at multi-threaded games and the close relation with next console hardware. They offer a crysis 3 benchmark where the FX wins over the intel i5-3750k and the i7-3770k.

http://www.eurogamer.net/articles/digitalfoundry-future-proofing-your-pc-for-next-gen

We know that Haswell i7-4770k will be only 10% faster than the i7-3770k. Steamroller only would be only 10% faster than Piledriver to be again selected as better gaming cpu. And we wait about 30% improvement with Steamroller, no?

 

[mayankleoboy1]

We know that Haswell i7-4770k will be only 10% faster than the i7-3770k

more like 7-8% .

And i think SR should be 15% stock to stock better than PD.