FRONTPAGE Rumor: AMD FX-8350 -Piledriver- to Launch in Q3

[Bubba-Hotepp]

None of the Linux compilers have ever shown any bias due to the "vendor ID string". The differences you're seeing in those compilers is as ]-[itman pointed out compiler efficiency in general and that efficiency applies to ALL CPU's running the compiled software.

 

[mjw21a]

None of the Linux compilers have ever shown any bias due to the "vendor ID string". The differences you're seeing in those compilers is as ]-[itman pointed out compiler efficiency in general and that efficiency applies to ALL CPU's running the compiled software.

If you want to compare which architecture is better than another, then you're best of doing all benchies from Linux. If you want real world performance then unfortunately you're confined to testing in Windows as thats what most people use.

I would love to see comparisons in Linux, though I suspect that right now, Intel simply have the better architecture.

 

[Bubba-Hotepp]

If you want to compare which architecture is better than another, then you're best of doing all benchies from Linux. If you want real world performance then unfortunately you're confined to testing in Windows as thats what most people use.

I would love to see comparisons in Linux, though I suspect that right now, Intel simply have the better architecture.

The key is to know what to test in windows with the emphasis being on "real world" applications.

]-[itman already posted a link to the benchmarks run in linux comparing the 8150 to SB & Gulftown. It didn't "Crush" them but neither did they "Crush" the 8150. It's really a mixed bag of results. http://www.phoronix.com/scan.php?page=article&item=amd_fx8150_bulldozer&num=1

And you never know, things might change. MS has just pissed off two of the largest Game makers/distributers with Win 8. Valve all but outright admitted that's why they're pushing steam onto Linux. If MS pisses off enough customers and they find that they have a viable option for "gaming" that could very easily shift the balance of power.

 

[EarthDog]

]-[itman already posted a link to the benchmarks run in linux comparing the 8150 to SB & Gulftown. It didn't "Crush" them but neither did they "Crush" the 8150. It's really a mixed bag of results. http://www.phoronix.com/scan.php?pag...ulldozer&num=1

The story still remained the same essentially no? I mean how can one compare the differences between different benchmark applications and different OS's and come up with a conclusion while having a straight face? Like getting blood from a stone...

 

[mjw21a]

That wasn't my point. Benchies absolutely must be compared on the same OS to be in any way relevant. My point is more along the lines of Linux actually being more advanced and using more of the features of each architecture. If you want to compare architectures then thats a good place to start, however the results are still only really useful if you want to run Linux.

Windows on the other hand lags Linux on making use of new instructions, and Intel handles legacy code better than AMD, plain and simple. Then again, Windows has more relevance to most than Linux, certainly for me. I only use Linux for browsing the net and general use though I'm thinking of changing my main rig into a dual boot Linux/Windows box. Linux for work and Windows for games.

 

[Bubba-Hotepp]

That wasn't my point. Benchies absolutely must be compared on the same OS to be in any way relevant. My point is more along the lines of Linux actually being more advanced and using more of the features of each architecture. If you want to compare architectures then thats a good place to start, however the results are still only really useful if you want to run Linux.

Windows on the other hand lags Linux on making use of new instructions, and Intel handles legacy code better than AMD, plain and simple. Then again, Windows has more relevance to most than Linux, certainly for me. I only use Linux for browsing the net and general use though I'm thinking of changing my main rig into a dual boot Linux/Windows box. Linux for work and Windows for games.

Think about what you're saying for a minute and then consider this.
In windows you have benchmarks that show HUGE disparity in results that would lead some to believe that FX is VASTLY inferior to SB/IB, yet when running actual software you don't see such huge disparities.

The linux OS itself isn't going to change which instruction sets programs can utilize or not. That's done by the compiler/assembler used. That the OS can better utilize an architecture/instruction sets will not "favor" one CPU vendor or another, you'll see a "speed up" across the board. So when you see the performance of the FX series like you do when looking at the benchmarks in Linux that can only lead to one reasonable conclusion. Something is going on with the programs in windows and the compilers used which degrade the performance of AMD CPUs. And this is born out in the results that I'm seeing while using a VIA Nano to change the vendor string AND by the history of the past 9 years (2003 is where on or about Intel snuck the CPU dispatcher code into their compiler to degrade performance on non-intel CPUs).

 

[EarthDog]

In windows you have benchmarks that show HUGE disparity in results that would lead some to believe that FX is VASTLY inferior to SB/IB, yet when running actual software you don't see such huge disparities

We dont? Feel free to check out any reviews that use 'actual software'. Sure part of the issue may be in the compiler, but... not much one can do about that except to go to an OS that 99% of users wouldnt know how to use (linux) well to get around that. Its a terrible situation assuming the way you say it happened actually happened. But we really have our hands tied, ya know? This testing, when its completed..., can really shed some light on things though!

'Snuck' it in there? Did they (serious question as I thought that compiler was clearly public and used by mostly everyone)?

 

[Bubba-Hotepp]

We dont? Feel free to check out any reviews that use 'actual software'. Sure part of the issue may be in the compiler, but... not much one can do about that except to go to an OS that 99% of users wouldnt know how to use (linux) well to get around that. Its a terrible situation assuming the way you say it happened actually happened. But we really have our hands tied, ya know?

'Snuck' it in there? Did they (serious question as I thought that compiler was clearly public and used by mostly everyone)?

Here's the thing. There are very few programs that show the same large disparity in results (and NO I'm not talking about 5 FPS differences in games) as we see in some of those benchmarks. The beautiful thing about "real world" programs though is that for every 1 program that may be "tainted" and show bias as much as said benchmarks there are many other alternatives to use. But my point is still the same. The more this goes on coupled with the restrictive changes and directions MS is going with windows it only creates a situation for someone to come along and develope a very easy to use, simple and powerful version of Linux.

Yes, they "snuck" it in there. That's not my opinion that's the opinion of the FTC and other anti-trust angencies/commissions around the world.

FTC Filing - http://www.ftc.gov/os/adjpro/d9341/091216intelcmpt.pdf

Page 3:

Third, Intel used its position in complementary markets to help ward off competitive threats in the relevant CPU markets. For example, Intel redesigned its compiler and library software in or about 2003 to reduce the performance of competing CPUs. Many of Intel’s design changes to its software had no legitimate technical benefit and were made only to reduce the performance of competing CPUs relative to Intel’s CPUs.

Fifth, Intel engaged in deceptive acts and practices that misled consumers and the public. For example, Intel failed to disclose material information about the effects of its redesigned compiler on the performance of non-Intel CPUs. Intel expressly or by implication falsely misrepresented that industry benchmarks reflected the performance of its CPUs relative to its competitors’ products. Intel also pressured independent software vendors (“ISVs”) to label their products as compatible with Intel and not to similarly label with competitor’s products’ names or logos, even though these competitor microprocessor products were compatible.

Page 10:

58.
For example, in response to AMD introduction of its Opteron CPU for servers in 2003, Intel became concerned about the competitive threat posed by Opteron processors. Intel then designed its compiler and libraries in or about 2003 to generate software that runs slower on non-Intel x86 CPUs, such as Opteron. This decrease in the efficiency of Opteron and other non-Intel x86 CPUs harmed competition in the relevant CPU markets.
59.
To the public, OEMs, ISVs, and benchmarking organizations, the slower performance of non-Intel CPUs on Intel-compiled software applications appeared to be caused by the non-Intel CPUs rather than the Intel software. Intel failed to disclose the effects of the changes it made to its software in or about 2003 and later to its customers or the public. Intel also disseminated false or misleading documentation about its compiler and libraries. Intel represented to ISVs, OEMs, benchmarking organizations, and the public that programs inherently performed better on Intel CPUs than on competing CPUs. In truth and in fact, many differences were due largely or entirely to the Intel software. Intel’s misleading or false statements and omissions about the performance of its software were material to ISVs, OEMs, benchmarking organizations, and the public in their purchase or use of CPUs. Therefore, Intel’s representations that programs inherently performed better on Intel CPUs than on competing CPUs were, and are, false or misleading. Intel’s failure to disclose that the differences were due largely to the Intel software, in light of the representations made, was, and is, a deceptive practice. Moreover, those misrepresentations and omissions were likely to harm the reputation of other x86 CPUs companies, and harmed competition.

 

[EarthDog]

Excellent. Thanks for the compiler information.

As far as the performance goes. I mean, the review results speak for themselves. Im trying to see where you are coming from, but I fear only can with AMD tinted glasses (before you throw your hands up in the air...read the rest of the post).

Let me explain. It seems to me you appear to be coming up with a conclusion about it being 'closer' without an apples to apples comparison to back that up. Let me explain further and ask a question. Its one thing that PCMark7 shows a 30% difference in........ oh I dont know... compression, but then 7 zip shows say 10% (values are random). Do you know if those programs (and again they could be any application vs bench) use the same algorithms to do compression, rendering, encryption etc? If not how can anyone come to such a conclusion that its 'closer' when using real benchmarks? You are not comparing the same exact thing, right?

 

[Bubba-Hotepp]

Excellent. Thanks for the compiler information.

As far as the performance goes. I mean, the review results speak for themselves. Im trying to see where you are coming from, but I fear only can with AMD tinted glasses (before you throw your hands up in the air...read the rest of the post).

Let me explain. It seems to me you appear to be coming up with a conclusion about it being 'closer' without an apples to apples comparison to back that up. Let me explain further and ask a question. Its one thing that PCMark7 shows a 30% difference in........ oh I dont know... compression, but then 7 zip shows say 10% (values are random). Do you know if those programs (and again they could be any application vs bench) use the same algorithms to do compression, rendering, encryption etc? If not how can anyone come to such a conclusion that its 'closer' when using real benchmarks? You are not comparing the same exact thing, right?

But that's the thing. We don't have to know. The mere fact that on the same hardware with the same architecture the results change simply by changing the "Vendor ID string" (NOT the WHOLE CPUID but just the vendor identity itself) means that those results are not reliable and are therefore useless as a metric for comparing CPU performance.

My point about the results on Linux is that they appear to coincide with the differences (comparitively speaking) that you see in programs and benchmarks in windows that are NOT affected by changing the "Vendor ID string".

 

[Bobnova]

How so? If the "real world" apps change performance based on the string, they'll do it every time.
If, for instance, BD is so good at WinRAR because WinRAR was compiled with a compiler built for AMD that cripples Intel, it sucks for Intel but it is still a valid "real world" benchmark, because if you use WinRAR you're stuck with it.

Real world benchmark apps really need to be taken at face value if we're going to do an honest comparison. The question isn't which chip has the most FLOPS or the best integer performance. The question is which chip does better at these tasks. And if that task is compiled for Intel it's compiled for Intel. If you're going to run that task, you should buy an Intel chip.

It makes reviews more awkward, but if we're testing photoshop performance it really doesn't matter what it was compiled for, all that matters is the performance in photoshop.

 

[Bubba-Hotepp]

How so? If the "real world" apps change performance based on the string, they'll do it every time.
If, for instance, BD is so good at WinRAR because WinRAR was compiled with a compiler built for AMD that cripples Intel, it sucks for Intel but it is still a valid "real world" benchmark, because if you use WinRAR you're stuck with it.

Real world benchmark apps really need to be taken at face value if we're going to do an honest comparison. The question isn't which chip has the most FLOPS or the best integer performance. The question is which chip does better at these tasks. And if that task is compiled for Intel it's compiled for Intel. If you're going to run that task, you should buy an Intel chip.

It makes reviews more awkward, but if we're testing photoshop performance it really doesn't matter what it was compiled for, all that matters is the performance in photoshop.

That's the thing, I'd venture to say MOST real world apps DON'T change behavior depending on the identity of the vendor. In fact there are many benchmarks that don't as well. Novabench, Cinebench etc. (I'll have a larger list when I'm done testing). Now take your example of WinRAR. Let's say for example that it does change it is affected. You're not "stuck" with it as there are other alternatives such as 7zip, WinZip etc.

I agree with you that we should all be relying MORE on real world testing instead of "synthetic" benchmarks. We also need to be aware that there are programs that are "crippled" when using non-intel CPU's. I would wager a bet that it's far more problamatic in "synthetic" benchmarks than it is in real world applications but we'll see when I start testing those as well. The problem is that more often than not a "reviewer" relies heavily on "synthetic" benchmarks that can give a false impression of performance which affects readers buying decisions as well as give fodder to the non objective "AMD sucks at everything" crowd. I'm in no way saying that Intel doesn't make fantastic CPU's or that without the "bias" Bulldozer would "crush" the competition. What I'm saying is that we have a situation that has existed since 2003 that compounds the actual performance gap between BD and SB/IB making it seem much much worse than it actually is. But we're not asking the right questions. I'm willing to bet MANY programmers have learned their lesson after the compiler debacle and have either switched to using a different compiler or "patching" intel's compiler as Agner and others instruct because who wants to release a program knowing that it will be crippled on a significant amount of their user base. So the question is WHY do we still have programs like Aida64, and PCMark7 that show this kind of behavior when it was shown years ago in their predecessors (everest ultimate and PCMark05) that performance is crippled in non-intel CPUs? Is it programmer "laziness"? Is it "intentional"? Is it just plain "ignorance"? I have no idea why but I for one would sure like to know the answer to that.

 

[Bobnova]

On the other hand, take photoshop
Sure, there's Gimp, but not really.

 

[EarthDog]

But that's the thing. We don't have to know. The mere fact that on the same hardware with the same architecture the results change simply by changing the "Vendor ID string" (NOT the WHOLE CPUID but just the vendor identity itself) means that those results are not reliable and are therefore useless as a metric for comparing CPU performance.

My point about the results on Linux is that they appear to coincide with the differences (comparitively speaking) that you see in programs and benchmarks in windows that are NOT affected by changing the "Vendor ID string".

The vendor ID string is adding ANOTHER variable to the testing though (remember talking about post 327 not the testing being done here). So not only can there be differences in the way the real application(s) vs benchmark do the task, the vendor id string can show inaccurate results as well. So again, you have to compare it with the SAME program. There is nothing anyone can do right now about the compiler vendor ID stuff except to test it, expose the issue (again), and hope something comes of it.

Speaking specifically to what I mentioned earlier (post 327), one is unable (without vendor specific shades on) to come up with any kind of conclusion because of the potential differences. There isn't any getting around that as I see it now, but per usual am open to further discussion. Id just like to see more testing and less tilted conjecture is all.

 

[Bubba-Hotepp]

The vendor ID string is adding ANOTHER variable to the testing though (remember talking about post 329 not the testing being done here). So not only can there be differences in the way the real application(s) vs benchmark do the task, the vendor id string can show inaccurate results as well. So again, you have to compare it with the SAME program. There is nothing anyone can do right now about the compiler vendor ID stuff except to test it, expose the issue (again), and hope something comes of it.

Speaking specifically to what I mentioned earlier (post 329), one is unable (without vendor specific shades on) to come up with any kind of conclusion because of the potential differences. There isn't any getting around that as I see it now, but per usual am open to further discussion. Id just like to see more testing and less tilted conjecture is all.

Don't worry.....I'm doing PLENTY of testing. Almost getting sick of it

As for another variable, the whole point is that it SHOULD NOT be a variable at all. As Agner and many others have pointed out it is improper for ANY program to need to know who actually manufactured the CPU when determining which instruction sets to use or not use. There IS a function for that and it was even invented by Intel and that is by checking the "instruction set flags" that are embedded within the CPUID (NOT the vendor string portion of it). In the words of Agner:

Testing for "GenuineIntel" to see if the CPU has AES is wrong - it should only test the CPUID flag for AES.

 

[EarthDog]

You are not sticking to the scope of this specific discussion.. reread post 324/329 and what I am specifically addressing. Specifically the last paragraph in 329, but the context is setup in 324. You are coming up with conclusions that you shouldnt be is my point.

Here is the progression:

The story still remained the same essentially no? I mean how can one compare the differences between different benchmark applications and different OS's and come up with a conclusion while having a straight face? Like getting blood from a stone...

Mjw replied and you said:

Think about what you're saying for a minute and then consider this.
In windows you have benchmarks that show HUGE disparity in results that would lead some to believe that FX is VASTLY inferior to SB/IB, yet when running actual software you don't see such huge disparities.

Let me explain. It seems to me you appear to be coming up with a conclusion about it being 'closer' without an apples to apples comparison to back that up. Let me explain further and ask a question. Its one thing that PCMark7 shows a 30% difference in........ oh I dont know... compression, but then 7 zip shows say 10% (values are random). Do you know if those programs (and again they could be any application vs bench) use the same algorithms to do compression, rendering, encryption etc? If not how can anyone come to such a conclusion that its 'closer' when using real benchmarks? You are not comparing the same exact thing, right?

Just saying you cannot come up with the conclusion you did as you cannot compare the difference in a benchmark vs the difference in a real application since it may not be using the exact same method to complete that specific function. TO ME, that is a reach to make a conclusion like that.

 

[Bubba-Hotepp]

Huh? What I'm saying is that if a benchmark discriminates based on WHO manufactured the CPU that means the results of THAT benchmark are unreliable and useless. And it's not only MY opinion. It's the opinion of industry programmers like Agner, the opinion of the FTC, the opinion of AMD, the opinion of E.U. competition commission, the opinion of the South Korean government, the opinion of numerous industry experts that have written about the problem many times since 2005, the opinion of the impartial industry experts that were deposed and submitted reports during the FTC investigation, the E.U. investigation, the AMD lawsuit (which Intel settled and agreed to comply with removing that function from their compiler software and libraries but still haven't done so). Conclusion? If you say so. All I'm doing is testing to see if benchmarks and other programs are STILL affected to this day (which some clearly are).

 

[EarthDog]

Forget it...

To below... thanks BMW.. I thought we were in the compile thread (not that I was ever talking about that here ) for some reason. Im done on this tangent regardless.. Sorry!

 

[bmwbaxter]

This discussion doesn't have much to do with the rumoured release of Piledriver. IIRC there is a separate thread that is devoted to this issue and testing.

 

[Bubba-Hotepp]

This discussion doesn't have much to do with the rumoured release of Piledriver. IIRC there is a separate thread that is devoted to this issue and testing.

Good point. ED and I have beaten it to death here anyways