AMD Piledriver rumours ... and expert conjecture

Page 114 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
We have had several requests for a sticky on AMD's yet to be released Piledriver architecture ... so here it is.

I want to make a few things clear though.

Post a question relevant to the topic, or information about the topic, or it will be deleted.

Post any negative personal comments about another user ... and they will be deleted.

Post flame baiting comments about the blue, red and green team and they will be deleted.

Enjoy ...
 
As for PD, I doubt we will get anything solid until at least a month before its realease.

Then half the people here will ignore it because it goes against what they THINK/WANT PD to perform like. Remember how we had BD's horrendous cache latencies months before it actually released, and how NONE OF US believed they could be that horrid?

We'll see. Again, I'm not expecting much; 10% at best.
 
As of right now this site sucks and i blame only 1 person for that, and that's me for not looking for PD info, I hate this Intel did this or that it's BS where on a Amd forum can we talk about Piledriver/Trinity please. Or at least Llano or BD. I thought this Intel did this or that was covered in the BD forum.
 
As of right now this site sucks and i blame only 1 person for that, and that's me for not looking for PD info, I hate this Intel did this or that it's BS where on a Amd forum can we talk about Piledriver/Trinity please. Or at least Llano or BD. I thought this Intel did this or that was covered in the BD forum.

The quality of this forum has been going downhill for years and it is a sad shame that it has gotten to where it is now compared to how good it was back in it's better days. It isn't just here but everywhere else in general except for a few small sites here or there that one sometimes stumbles upon by accident.
 
As of right now this site sucks and i blame only 1 person for that, and that's me for not looking for PD info, I hate this Intel did this or that it's BS where on a Amd forum can we talk about Piledriver/Trinity please. Or at least Llano or BD. I thought this Intel did this or that was covered in the BD forum.

Well I like this forum. Please, post some Piledriver info or news, we'll look at it.
 
The quality of this forum has been going downhill for years and it is a sad shame that it has gotten to where it is now compared to how good it was back in it's better days. It isn't just here but everywhere else in general except for a few small sites here or there that one sometimes stumbles upon by accident.


Not much you can do to get quality info on unannounced product. The people who are "In the Know" are under NDA and risk losing their career or a lawsuit if they spill more beans. The rest is wish lists and speculation.

With the high level management exodus happening at AMD you can bet people are being especially tight lipped about saying anything. The axe is falling.
 
Not much you can do to get quality info on unannounced product. The people who are "In the Know" are under NDA and risk losing their career or a lawsuit if they spill more beans. The rest is wish lists and speculation.

With the high level management exodus happening at AMD you can bet people are being especially tight lipped about saying anything. The axe is falling.

I wasn't talking about amd in that post. I was talking about this forum, I still remember when they made fantastic articles and reviews instead of mac crap and almost religious apple news. Back on topic I am pretty bored when it comes to gpus and cpus atm as there isn't much that is exciting and new. Just the same old run around and price gouging as usual. The only thing that has people talking is Haswell even though Intel may have already had it working for over a year if not two in their labs. I got to see a demo of haswell in action and it is pretty much as market ready as current on the market products today. As for amd well I feel as many do let down and doubt that they will have any thing truly decent for a long time that could be considered competitive that isn't an apu.
 
The place has not gone downhill or I would have noticed ... my phone has that leveling app on it.

We don't tolerate the same sort of flame wars or vicious diatribe now either.

Its a much more civilised place here now ... palladin and noob and even triny haven't lost an eye ... yet.

jimmy will tell you how rough things were a few years ago.
 
It is not Intels job to ensure the extensions to X86 that THEY created work as intended on non-Intel CPU's. If the Intel compiler spits out code that for whatever reason doesn't work on a AMD chip, who do you think is getting sued?

Coincidentally, there ARE some implementation differences between Intel's and AMD's SSE implementations...


FTC, the definitive source for determining ethical and fair business practices, disagrees with you.

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

Intel sought to undercut the performance advantage of non-Intel x86 CPUs relative to Intel x86 CPUs when it redesigned and distributed software products, such as compilers and libraries.
[...]
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.
[...]
Some ISVs requested information from Intel concerning the apparent variation in performance of identical software run on Intel and non-Intel CPUs. In response to such requests, on numerous occasions, Intel misrepresented, expressly or by implication, the source of the problem and whether it could be solved.
[...]
Intel’s software design changes slowed the performance of non-Intel x86 CPUs and had no sufficiently justifiable technological benefit. Intel’s deceptive conduct deprived consumers of an informed choice between Intel chips and rival chips, and between Intel software and rival software, and raised rivals’ costs of competing in the relevant CPU markets. The loss of performance caused by the Intel compiler and libraries also directly harmed consumers that used non-Intel x86 CPUs.

Intel admitted to it and settles with AMD over that issue

http://download.intel.com/pressroom/legal/AMD_settlement_agreement.pdf

Section 2.3 discus's it.

FTC's remedial action to Intel. This action is outside and in addition to what the settlement stipulated.

Requiring that, with respect to those Intel customers that purchased from Intel a software compiler that had or has the design or effect of impairing the actual or apparent performance of microprocessors not manufactured by Intel ("Defective Compiler"), as described in the Complaint:

Intel provide them, at no additional charge, a substitute compiler that is not a Defective Compiler;
Intel compensate them for the cost of recompiling the software they had compiled on the Defective Compiler and of substituting, and distributing to their own customers, the recompiled software for software compiled on a Defective Compiler; and
Intel give public notice and warning, in a manner likely to be communicated to persons that have purchased software compiled on Defective Compilers purchased from Intel, of the possible need to replace that software.

Your not arguing with me your arguing with the FTC.

After reading this information, all my authoritative official sources, if anyone still tries to support Intel's position then they are a "fanboy" and operating in a reality distortion field. That or they have an agenda their pushing.

AMD / Intel / Via, I don't care which one people prefer to use. What I do care about is people who try to go back and rewrite history and alter facts then argue that their revised history and facts are correct.

You guys wanted proof, I posted not only the legal settlement were Intel agreed to stop misdirecting customers but also the FTC findings against Intel and their remediation actions. I posted the findings on exactly what the Intel compiler was doing and how it was being marketing, the work around to fix the behavior, and the performance impact it was having. I've even supplied methods for independent verification of these results.

So please, continue defending their actions. Everyone is watching and everyone gets to see who you really are. Any words you use in your defense will sound hollow as the truth has already been proven and made easily available for anyone to find out.
 
As for PD, I doubt we will get anything solid until at least a month before its realease.

Then half the people here will ignore it because it goes against what they THINK/WANT PD to perform like. Remember how we had BD's horrendous cache latencies months before it actually released, and how NONE OF US believed they could be that horrid?

We'll see. Again, I'm not expecting much; 10% at best.

I am expecting the same but I still expect mostly clock speed performance enhancements, not IPC.

As of right now this site sucks and i blame only 1 person for that, and that's me for not looking for PD info, I hate this Intel did this or that it's BS where on a Amd forum can we talk about Piledriver/Trinity please. Or at least Llano or BD. I thought this Intel did this or that was covered in the BD forum.

If we were to actually get info, we would. But thats the problem. AMD has been holding their info in very tightly, look at BD. We didn't get an "official" info until release, if you don't count the "unofficial" benchmarks that were pretty spot on.

The place has not gone downhill or I would have noticed ... my phone has that leveling app on it.

We don't tolerate the same sort of flame wars or vicious diatribe now either.

Its a much more civilised place here now ... palladin and noob and even triny haven't lost an eye ... yet.

jimmy will tell you how rough things were a few years ago.

It was pretty bad. Flames raged on and on.

I do agree a lot of the guys seem pretty well held together although I think some of them tend to hide their insults, still better than before.

I let money talk ,I bought enough AMD shares that my trinity system will be on AMD.
free

If you invested in Intel, the dividends over a year could pay for a new system. Or MS. Or any company that pays decent dividends.

Plus you always get them. And MS is great for stock splits, which double your share amounts.
 
For anyone who's curious. Mental Gymnastics is the ability to argue and debate things while obscuring and altering the facts.

http://en.wiktionary.org/wiki/mental_gymnastics

Inventive, complex arguments used to justify unjustifiable decisions, or situations.

People often perform mental gymnastics in order to blame anyone but themselves.

Basically the ability to convince others that 2 + 2 = 5 by first convincing yourself.
 
For anyone who's curious. Mental Gymnastics is the ability to argue and debate things while obscuring and altering the facts.

http://en.wiktionary.org/wiki/mental_gymnastics

Inventive, complex arguments used to justify unjustifiable decisions, or situations.

People often perform mental gymnastics in order to blame anyone but themselves.

Basically the ability to convince others that 2 + 2 = 5 by first convincing yourself.

I appreciate the jest but I am not inventing anything. If anything, you are arguing one point, I am arguing another.

You say its not optimizing, but in reality it is since its optimizing to utilize features in a CPU or other piece of hardware. If a system is optimized to take advantage of CUDA cores, it will not just work on ATI Stream since it was never set to utilize it.

That is optimization.

If you don't like different points of view on subjects, then I suggest you try to stay away from forums as your views are not the only views of the world but instead those of yourself.

BTW, gamer is right. Just because they have a certain SSE or instruction set, it does not mean it is the same as what Intel is using and vice versa. Phenom IIs had SSE 4a, included 4 SSE4 sets with 4 of their own, while Yorkfield had SSE 4.1 which had 47 of the 54 SSE4 sets. Then Nehalem incoporated SSE4.2 which added the other 7 of the 54 sets.
 
I appreciate the jest but I am not inventing anything. If anything, you are arguing one point, I am arguing another.

You say its not optimizing, but in reality it is since its optimizing to utilize features in a CPU or other piece of hardware. If a system is optimized to take advantage of CUDA cores, it will not just work on ATI Stream since it was never set to utilize it.

That is optimization.

If you don't like different points of view on subjects, then I suggest you try to stay away from forums as your views are not the only views of the world but instead those of yourself.

FTC disagrees with you. As should any reasonable person.

Intel didn't enable anything, they disabled code on non-Intel CPUs, and didn't tell anyone about it. Then when their customers asked about the discrepancy Intel told them their CPU's were just that much better.

JS you've been doing mental gymnastics on this issue from the beginning. You try to justify Intel's deliberate handicapping and artificially impairing performance of AMD CPU's (FTC's own words). You then try to divert attention using straw man arguments and hasty generalizations. CUDA has nothing to do with it, don't make bad analogy's.

AMD has a legal license to the x86 instruction set and all extensions and enhancements to that ISA. This was granted in the 90's, well before the findings against Intel. This includes SSE instructions and all it's derivatives. Thus any x86 or extended instruction that would run on an Intel CPU would also run on an AMD CPU or any other x86 licensed CPU. Intel can only guarantee that it runs on it's own CPU's, this is understandable. This is not what Intel did, Intel went out of their way to disable and artificially impair the performance of their competitors products. THIS IS NOT UP FOR DEBATE This has already been investigated and proven by the FTC.

You've been convincing yourself that Intel did not participate in unethical and anti-competitive practices, this has been proven wrong and thus your lying to yourself.

Please post proof, investigations, findings, ~something~ that validates or proves your position. I've posted tons of information, from official sources, that support my position, and my position is that Intel participated in unethical and anti-competitive practices that inflicted economical damage to it's competitors.

Or are you agreeing that Intel did those things and that it's totally ok for them to have done such? Are you supporting a company participating in unethical and anti-competitive business practices, lying to it's customers, and lying to regulators?
 
I appreciate the jest but I am not inventing anything. If anything, you are arguing one point, I am arguing another.

You say its not optimizing, but in reality it is since its optimizing to utilize features in a CPU or other piece of hardware. If a system is optimized to take advantage of CUDA cores, it will not just work on ATI Stream since it was never set to utilize it.

That is optimization.

If you don't like different points of view on subjects, then I suggest you try to stay away from forums as your views are not the only views of the world but instead those of yourself.

BTW, gamer is right. Just because they have a certain SSE or instruction set, it does not mean it is the same as what Intel is using and vice versa. Phenom IIs had SSE 4a, included 4 SSE4 sets with 4 of their own, while Yorkfield had SSE 4.1 which had 47 of the 54 SSE4 sets. Then Nehalem incoporated SSE4.2 which added the other 7 of the 54 sets.

Well, if you take into account that to build a compiler you actually need (as a chip designer) to provide the full spec of your CPU including lock or/and hang sequences, it would be natural to include what your CPU design actually supports (instruction wise), since you're giving them the "what not to do". Remember we're talking about a compiler and libraries here, so Intel had that info. Same goes to whoever wants to create a compiler for a target arch/ISA IIRC. Intel just decided to go the easy route and not use what AMD provided at the time (maybe they didn't even ask them about their CPUs, dunno).

So, that argument is invalid IMO.

Anyway, like I said, I'm sure AMD would have done the same thing in Intel's shoes. It's all about the bottom line, baby.

Cheers!
 
Well, if you take into account that to build a compiler you actually need (as a chip designer) to provide the full spec of your CPU including lock or/and hang sequences, it would be natural to include what your CPU design actually supports (instruction wise), since you're giving them the "what not to do". Remember we're talking about a compiler and libraries here, so Intel had that info. Same goes to whoever wants to create a compiler for a target arch/ISA IIRC. Intel just decided to go the easy route and not use what AMD provided at the time (maybe they didn't even ask them about their CPUs, dunno).

So, that argument is invalid IMO.

Anyway, like I said, I'm sure AMD would have done the same thing in Intel's shoes. It's all about the bottom line, baby.

Cheers!

Actually much easier then that. Since we're talking superscaler uArch's here with an abstracted ISA, there is no need for technical documentation on each and every CPU. The x86 ISA itself and it's various extensions define exactly how each instruction will be handled and what the expected output from those instructions are. Period, end of story. Intel needed absolutely no documentation from AMD, they just make their compiler for the Intel x86 ISA with support for SSE version x and that's it. It's AMD's responsibility to ensure their CPU properly understands the Intel x86 ISA and SSE instruction sets and properly executed that code. The whole "we can't be responsible for processor X..." is completely BS, as the FTC proved that and then reprimanded them for it. There is no such thing as "Intel Optimizations" or "AMD Optimizations" with respect to x86 and SSE SIMD instructions. There is only the ISA. FTC found that guilty of creating "Artificial Performance Impairments" (their words exactly) for their competitors CPUs and forced them to correct it. They now support SSE2 on AMD CPU's, just not version 3, 4 or AVX (FMA is a screw ball situation) even though AMD implemented the Intel standard per their licensing agreement.

Or as Agner put it.

But a MUCH more basic question is why Intel's compiler designers should give a soaring adlunar coition what chip the compiler is running on. If the compiler runs well on a real Intel chip, the job's done. THERE IS NO NEED to detect non-intel chips for ANY legitimate reason. If the third-party chip is *really* Intel-c
 
FTC disagrees with you. As should any reasonable person.

Intel didn't enable anything, they disabled code on non-Intel CPUs, and didn't tell anyone about it. Then when their customers asked about the discrepancy Intel told them their CPU's were just that much better.

JS you've been doing mental gymnastics on this issue from the beginning. You try to justify Intel's deliberate handicapping and artificially impairing performance of AMD CPU's (FTC's own words). You then try to divert attention using straw man arguments and hasty generalizations. CUDA has nothing to do with it, don't make bad analogy's.

AMD has a legal license to the x86 instruction set and all extensions and enhancements to that ISA. This was granted in the 90's, well before the findings against Intel. This includes SSE instructions and all it's derivatives. Thus any x86 or extended instruction that would run on an Intel CPU would also run on an AMD CPU or any other x86 licensed CPU. Intel can only guarantee that it runs on it's own CPU's, this is understandable. This is not what Intel did, Intel went out of their way to disable and artificially impair the performance of their competitors products. THIS IS NOT UP FOR DEBATE This has already been investigated and proven by the FTC.

You've been convincing yourself that Intel did not participate in unethical and anti-competitive practices, this has been proven wrong and thus your lying to yourself.

Please post proof, investigations, findings, ~something~ that validates or proves your position. I've posted tons of information, from official sources, that support my position, and my position is that Intel participated in unethical and anti-competitive practices that inflicted economical damage to it's competitors.

Or are you agreeing that Intel did those things and that it's totally ok for them to have done such? Are you supporting a company participating in unethical and anti-competitive business practices, lying to it's customers, and lying to regulators?

Well you kinda pulled it down into this discussion. I said there is nothing wrong with Intel helping companies optimize games for their CPUs, you brought it back to a compiler, which as said many a time before, which is used by very little anywhere compared to the MS compiler.

Thats why I really couldn;t care what Intel did with it since it was not in the majority of software that we use daily, instead its the MS compiler which should not care but as Intel stated, no one can gurantee that it will work the same for all hardware, just like games wont perform the exact same on all hardware configs out there.

So lets end it. You state its wrong. I honestly don't care as it had nothing to do with the original discussion, which was that games optimized for Intel platforms is not wrong same as if it was optimized for AMDs platforms or nVidias GPUs etc.
 
Actually much easier then that. Since we're talking superscaler uArch's here with an abstracted ISA, there is no need for technical documentation on each and every CPU. The x86 ISA itself and it's various extensions define exactly how each instruction will be handled and what the expected output from those instructions are. Period, end of story. Intel needed absolutely no documentation from AMD, they just make their compiler for the Intel x86 ISA with support for SSE version x and that's it. It's AMD's responsibility to ensure their CPU properly understands the Intel x86 ISA and SSE instruction sets and properly executed that code. The whole "we can't be responsible for processor X..." is completely BS, as the FTC proved that and then reprimanded them for it. There is no such thing as "Intel Optimizations" or "AMD Optimizations" with respect to x86 and SSE SIMD instructions. There is only the ISA. FTC found that guilty of creating "Artificial Performance Impairments" (their words exactly) for their competitors CPUs and forced them to correct it. They now support SSE2 on AMD CPU's, just not version 3, 4 or AVX (FMA is a screw ball situation) even though AMD implemented the Intel standard per their licensing agreement.

Or as Agner put it.

But a MUCH more basic question is why Intel's compiler designers should give a soaring adlunar coition what chip the compiler is running on. If the compiler runs well on a real Intel chip, the job's done. THERE IS NO NEED to detect non-intel chips for ANY legitimate reason. If the third-party chip is *really* Intel-c

Then what's the purpose of the -march in GCC? xD

I'm sure you need a little more than the ISA to create a fully capable compiler.

Cheers!
 
Well you kinda pulled it down into this discussion. I said there is nothing wrong with Intel helping companies optimize games for their CPUs, you brought it back to a compiler, which as said many a time before, which is used by very little anywhere compared to the MS compiler.

Thats why I really couldn;t care what Intel did with it since it was not in the majority of software that we use daily, instead its the MS compiler which should not care but as Intel stated, no one can gurantee that it will work the same for all hardware, just like games wont perform the exact same on all hardware configs out there.

So lets end it. You state its wrong. I honestly don't care as it had nothing to do with the original discussion, which was that games optimized for Intel platforms is not wrong same as if it was optimized for AMDs platforms or nVidias GPUs etc.

Well, I'm sure it has a little tangent with games (a link to it, if you like).

Since Intel provides an SDK, that translates into a full set of libraries and most probably a compiler. I think it was mentioned in some of the sea of words we've been navigating, hahaha.

So, who knows if those libraries tell the executable to "overlook" some ways of making the code work "faster" or some obscure thing like that? There's already a precedent for that, so it's not fully excluded of the arguments we can make for AMD's "incompetence" in games. We'd need to use a VIA Nano to actually know if there's such a "cheat" in games. I wonder if there's a brave enough site to do that? Go against Intel... I'm sure there's none, hahaha.

Cheers!
 
Then what's the purpose of the -march in GCC? xD

I'm sure you need a little more than the ISA to create a fully capable compiler.

Cheers!

GCC and MSC compile a single binary. You must tell it which instruction level to use for that compilation. If you really want there are options to tell it SSE version, in which case you don't need to pass it specific CPU's. It was implemented that way for ease of use, HLL programers are not expected to know which operations each CPU family can do and which it can't. In any case, GCC and MSC will compile once set of code. If you specific to use SSE instructions then GCC and MSC will use those instructions and if the target CPU can't run them then it will just exit out with an exception.

Intel compiler use's something known as a dispatcher, they compile your code multiple times. Each function of your code may be compiled with one to four variants utilizing different sets of instructions. Intel then insert's it's dispatcher into your code and that determines which code sets to use during execution. You have i386 (x86 no SEE) then various enhancements on top of that (i586/i686 ect..) that represent different SEE and MMX levels.

And that's the crux of the entire argument, Intel's dispatcher, which was a piece of Intel code that was inserted into every binary compiled by the Intel compiler, would disable enhanced instruction sets on any CPU not identified as Intel. Intel didn't tell it's customers this and lied to them when they asked about it. The FTC identified this as anti-competitive behavior and forced Intel to change it's practices.

So to answer your question, the -uarch (-mcpu) flag for GCC just tells GCC to which level of the x86 ISA it should use. If you read up you can find out which instruction sets and feature flags are included in each of those flags. You can actually specify those feature flags separately if you wanted, but that gets messy.
 
Well you kinda pulled it down into this discussion. I said there is nothing wrong with Intel helping companies optimize games for their CPUs, you brought it back to a compiler, which as said many a time before, which is used by very little anywhere compared to the MS compiler.

Thats why I really couldn;t care what Intel did with it since it was not in the majority of software that we use daily, instead its the MS compiler which should not care but as Intel stated, no one can gurantee that it will work the same for all hardware, just like games wont perform the exact same on all hardware configs out there.

So lets end it. You state its wrong. I honestly don't care as it had nothing to do with the original discussion, which was that games optimized for Intel platforms is not wrong same as if it was optimized for AMDs platforms or nVidias GPUs etc.

Your pushing an agenda, you've been pushing an agenda for awhile now. I called you on it and you attempted to defend your agenda. I dug into the details and findings of the FTC to back why your agenda was wrong.

This is relevant to the thread because people are publishing game benchmarks, amongst others, as indications of this processor performances an ect. Someone brought up the size of the two companies involved and that anyone Intel is providing a SDK for would be using the Intel compiler and thus their benchmarks would by default be biased. This is where you inserted your agenda and attempted to convince others that it's perfectly find for Intel to participate in unethical and anti-competitive practices. All you had to do was say, ok Intel did bad stuff, and move on. But no you wanted to justify your agenda just like previous with your ridiculous ADP statements.

And as such, there is no such thing as "games optimized for X / Y / Z platform". GNU GCC will produce unbiased code, as will the MS Compiler. The only thing you must watch out for is if Intel libraries were used during the compilation, any code executed from those libraries will be biased. The issue your ignored, and I left out to demonstrate that you didn't do your homework, is that the Intel Compiler produces the fastest code for the x86 Windows platform. This is why most games and (contrary to your uninformed statement) use the Intel compiler or used the Intel libraries for various functions. The guys making the third party game engine want to sell their product as the fastest possible and thus purchase the Intel Compiler, and thus any game utilizing their game engine would be hamstrung (only SSE2, no SSE3/4/AVX) on and AMD CPU even if AMD implemented the instruction set perfectly.
 
And now for the why of it all. Why should you the consumer, us the enthusiast care if Intel is participating in unethical and anti-competitive behavior? Because it detracts from a fair market and impairs product development. Free markets operate under the concept of each competitor producing the best product and you the consumer choosing the one that fits your needs. The competitor that makes the best product thus gets the most business. This rewards making a superior product and offering it at low prices.

Now making these superior product's isn't cheap. Many businessmen lament the lower margins from having to actually develop those better products and selling them for cheap. It's far cheaper to tarnish your competitors reputation and convince consumers that their product is worse then yours through manipulation then actually producing a better product. If this is allowed to happen then the consumer is only provided misleading options, prices remain high and you get stagnant development.

SB is as good as it is because Intel ~had~ to create a better CPU, they were forced to compete in a fair an open market vs using exclusive OEM deals to cut their competition out of the market. They couldn't lie to independent (supposedly) reviewers about their products. SB (actually Core) was created as a result of the FTC findings and the Anti-Trust investigations against Intel. As long as there is pressure on Intel to be fair and open, then the customer will be presented with the best products possible.
 
Status
Not open for further replies.