Finally....done....phew. I hope I don't have to do this again for quite some time.
Like AON3 said PC games are generally GPU bound. But I would like to expound on that a little more if I may.
The gpu side of a modern game engine is under pretty consistent high load. However the cpu side often produces highly erratic behavior. Most of the time it's doing very little work. But every once and awhile an event handler is triggered which causes the computational requirements to explode. Maybe you blew up a building and it needed to do physical simulation of the debris. Maybe a series of nearby explosions caused the audio renderer load to suddenly increase. Whatever the cause the result is a short but dramatic drop in framerate. The result of that is a sometimes perceivable microstutter. With a good cpu these stutters will be less severe (less drop in framerate), less often, and shorter in duration. But since these stutters happen only occasionally and for a brief moment they have very little effect on average framerate. A tremendous increase in cpu side microstuttering will only drop the average framerate by a few fps. And that's what we see with bulldozer/piledriver.
But how do we measure this? Simple. Frame times. Recently it's become more popular to include these as a benchmark in additional to framerates due to a wider availability of the software and hardware tools required to measure it as well as a greater exposure to the problem by the general public (people have begun to realize that especially with SLI/Crossfire microstuttering can cause a high framerate to still appear "jittery"). When measuring a cpus impact on a video game it is absolutely crucial to measure frame times. So how well does AMD currently stack up against the competition in this area? Well see for yourself: http://techreport.com/review/23246/inside-the-second-gaming-performance-with-today-cpus
Not good.....
As far as framerates are concerned you'll usually only see a big difference if you have a 120Hz monitor. When trying to reach framerates above 75-90 fps sandy/ivy bridge cpus take a significant lead in framerate.
In the few cpu bound game engines that exist FX series cpus get utterly destroyed. Take a look at SC2 and FC2 benchmarks for example.
In addition to this both the dolphin and pcsx2 communities have run benchmarks on bulldozer and piledriver for their respective emulators and proven repeatedly that they are terrible for emulation as well. So don't use them for emulated games either.
There are so many game benchmarks for piledriver/bulldozer from so many different sources all showing a small to substantial loss in framerate compared to sandy/ivy bridge in almost every game that I for one cannot understand why someone would attempt to recommend one of these things as a gaming cpu.
I wouldn't say demolishing. It won in some of the tests and it lost in some of the tests. In terms of the number of tests won/lost they look about equal.
AON3 also mentioned that they were all heavily multi-threaded. Which is not a good representation of the variety of real world applications that a user is likely to run. This is true but I would like to add to that. Nearly all of the benchmarks they used were either workstation/server applications, scientific applications, or synthetic applications. In other words the type of applications that this particular microarchitecture does well with. And it still lost in half of them. A good review will contain a wide range of different types of workloads/software that your average user is expected to use to see how well the architecture performs under the many different types of work that a typical user will be giving it. But we don't see that here. We just see the best case scenario. Honestly what are you more likely to do with your PC, run protein folding simulations or run dolphin?
AON3 properly addressed this as well. Modern graphics engines use the same codepath for different GPUs because they all run the same type of code (HLSL for d3d and GLSL/CGSL for openGL). So yes we do "toss the same code" at them because it's impossible to do otherwise with the abstraction present in modern operating systems. You would know this if you had done any graphics programming at all. But instead you're just making assumptions. So please knock it off. It's a waste of everyone's time to have to correct you.
Please start quoting what you're responding to. I have no clue who "they" is or what "they" don't know.
I assure you we've tried every GCC flag available.
Even if we hadn't a microarchitecture that requires a specially optimized binary just to perform on par with a competing microarchitecture running an unoptimized binary is inherently a bad microarchitecture. Case in point: The Netburst and Itanium microarchitectures.
Sandy/ivy bridge cpus are so far ahead in dolphin that no level of compiler optimization will allow an FX series cpu to perform competitively. I doubt even hand optimizing all of the code in assembly for piledriver would allow it to achieve the same performance that sandy/ivy bridge cpus are getting now.
How do you know this? What optimizations could be made to allow the FX series cpus to outperform sandy/ivy bridge cpus? Please bless us with your great knowledge of low level optimizations. Unless....you're making another assumption. But you wouldn't do that right? RIGHT!?!
That was fixed ages ago in the linux kernel and NT kernel. All modern piledriver benchmarks do proper thread scheduling.
I have no idea what you're trying to say here. Dual/triple threading has nothing to do with the scheduling issues you were referring to earlier in your sentence.
If you're asking why dolphin is dual/triple threaded it is because like most applications it is literally impossible to gain any speedup from multithreading it any further. Dolphin has only 3 chips to emulate and the instructions for each chip must be emulated in sequential order or the result of the emulated function will be changed (thus breaking emulation). This makes parallel processing of the instructions incredibly stupid because of the resulting stall time from syncing/locking the threads. Despite this fact the developers tried it anyways and proved that it wouldn't work.
Once again we need some context or we can't figure out what it is you're trying to say. And talking like that is extremely unprofessional so please avoid doing it if you wish to be taken seriously.
See above.
This is beyond ridiculous. Peer reviewed benchmarks are literally the most accurate form of data collection for performance available on the planet. To claim that most hardware review sites are paid off by Intel is absurd. You have users getting the same results with the same software. An enormous number of sites, far more than Intel could even find let alone pay off. The lack of a guarantee that they will all accept your money. Most of these sites even go so far to make their employees sigh ethical clauses strictly forbidding it just to keep people like you happy. Then there is the fact that if even one site blows the lid on what you're doing it will utterly ruin your companies reputation. This means the only way you could be right is if Intel has personally tracked down and bribed every single website and user that has ever benchmarked their products and somehow ensured that none of them would ever admit to it. In other words it's a worldwide conspiracy by tens of thousands of people (at least, probably more) including random users. I am absolutely stunned that someone would make such a claim.
"Sometimes" is the key word there. And yes you're right they do keep up with the i7 3770K and 3820 in some applications. The problem is that the type of workload needed for them to perform this well is very rare in real world applications and even when these chips do perform competitively they require more power and generate more heat to do it. Which is why OEMs won't touch them with a 10 ft. pole.
That's not a scandal. They have openly admitted which compiler they use from day one. ICC is a compiler that is made for Intel and is therefore optimized for Intel cpus, everyone knows that. It's not Intels fault that AMD hasn't bothered to invest R&D money into making their own compiler.
This is true to some extent. However I must point out two things that nullify this argument being used to defend the FX series cpus:
1. Only a small fraction of the software typically used for benchmarking these cpus is compiled with ICC. You can't simply ignore all of the other results which are equally poor just because some tests use ICC. The results with software compiler on other compilers are generally just as bad.
2. If your favorite software runs faster on Intel cpus and part of the reason is ICC you shouldn't stop using Intel cpus just because it's "not fair". The goal of a cpu is to run the software that you use faster and with a lower power consumption. You shouldn't really care how it's achieved. Is it fair? No. Is it a valid reason for not buying Intel cpus? No.
Also the benefits of using Intel CPUIDs in ICC are grossly exaggerated by the AMD community. In nearly all tests done on the subject the performance difference has been shown to be small or nothing depending on the type of workload. In dolphin for example there is typically little to no difference comparing Intel vs. AMD on ICC and GCC. The only software the really gains any benefit at all are those that extensively use newer SSE instructions (which to fair cinebench probably does).
You can't just dismiss bulldozer/piledrivers architectural weaknesses just because some software uses ICC. AMDs microarchitectures are still missing a lot of features that are very important for many workloads. They still don't have micro-op fusion, macro-op fusion, a microcode cache, a 6 wide execution pipeline, and the list goes on and on. No level of software optimization will make up for the lack of these features. Certain algorithms are just going to run poorly no matter what without these features. A good cpu microarchitecture is one that can run a wide range of algorithms well, not just some. If piledriver was massively faster in optimal workloads then we could forgive all of the crappy results. But it's not. It ranges from "much slower" to "about the same or slightly faster" depending on the application. Combine this with a higher power consumption and lack of integrated graphics and it clearly becomes the lesser architecture.
To summarize:
-Stop blaming programmers for everything. Believe it or not there is such a thing as a genuine hardware weakness. Sometimes hardware can do a specific task in a more optimal way. Claiming that anytime something is slower than something else it must be the programmers fault is insane. A K7 cpu for example is just flat out inferior to todays cpus even when running the same code at the same clock rate. Its pipeline design is simply less optimal. Blaming programmers for this would not be logical.
-Vishera (piledriver FX series) cpus performance relative to ivy bridge i7s mostly range from "much worse" to "about the same" depending on the application. Overall their performance is poorer. These benchmarks have been done by both professional organizations and random users on the internet with comparable results so there is no reason to doubt them. If you want to have the fastest overall cpu regardless of price your only option is Intel at this point.
-FX series cpus generally do slightly worse in framerate tests and dramatically worse in frame time tests. In cpu bound games their framerates are much poorer. This makes them a bad choice for PC gaming.
-Both the dolphin and pcsx2 communities have conducted community benchmarks and found that FX series cpus to no ones surprise perform poorly in emulators.
-FX series cpus consume more power and produce more heat despite have suboptimal performance.
-While the FX series cpus can overclock higher overclocking them even a tiny bit causes their power consumption (and therefore heat) levels to shoot up to up to crazy high numbers. The same level of overclocking can be achieved on competing Intel cpus with dramatically lower power consumption and heat. Making them the better choice for most overclockers who don't have access to phase change cooling or any other exotic form of cooling (not to mention the risk of condensation and rapid electrical/chemical damage to the hardware associated with using that kind of cooling solution).
-AMD has realized that their chips are inferior. That is why they have had to price them so much lower in order to sell them. Their idea is to provide a chip that can produce comparable performance to i5 and i7 cpus in some applications (primarily those that are heavily multithreaded) at a lower cost. In exchange for this users will have to deal with higher power consumption, greater cooling requirements, lack of integrated graphics (which is important to bringing down total system cost for non-gamers), and poor performance in many applications that don't have a workload that is optimal for this type of architecture. But you do get similar performance in some applications at a lower cost. If that weren't the case they wouldn't be able to sell them at all. If you happen to use those applications extensively by all means buy one. But it sounds to me like the types of applications you plan on using are not well suited to this architecture. So you would be wise to avoid it.
This analogy is more confusing and inaccurate than it is helpful. This is why I generally avoid trying to compare electronics to other types of systems for the purposes of explanation.
I strongly disagree with this. Compiler and code optimizations can both be used to shift an algorithm from favoring one microarchitecture to another.
Cruzar Wrote:If Intel is so much faster than AMD why is it in any Game test (real world NOT synthetic) if the FX chips (including the 4100) are ever behind by a comparable Intel cheap, even an i5 the FPS difference is so negligible as to be like wow.....5fps? Whoopie fucking do.
Like AON3 said PC games are generally GPU bound. But I would like to expound on that a little more if I may.
The gpu side of a modern game engine is under pretty consistent high load. However the cpu side often produces highly erratic behavior. Most of the time it's doing very little work. But every once and awhile an event handler is triggered which causes the computational requirements to explode. Maybe you blew up a building and it needed to do physical simulation of the debris. Maybe a series of nearby explosions caused the audio renderer load to suddenly increase. Whatever the cause the result is a short but dramatic drop in framerate. The result of that is a sometimes perceivable microstutter. With a good cpu these stutters will be less severe (less drop in framerate), less often, and shorter in duration. But since these stutters happen only occasionally and for a brief moment they have very little effect on average framerate. A tremendous increase in cpu side microstuttering will only drop the average framerate by a few fps. And that's what we see with bulldozer/piledriver.
But how do we measure this? Simple. Frame times. Recently it's become more popular to include these as a benchmark in additional to framerates due to a wider availability of the software and hardware tools required to measure it as well as a greater exposure to the problem by the general public (people have begun to realize that especially with SLI/Crossfire microstuttering can cause a high framerate to still appear "jittery"). When measuring a cpus impact on a video game it is absolutely crucial to measure frame times. So how well does AMD currently stack up against the competition in this area? Well see for yourself: http://techreport.com/review/23246/inside-the-second-gaming-performance-with-today-cpus
Not good.....
As far as framerates are concerned you'll usually only see a big difference if you have a 120Hz monitor. When trying to reach framerates above 75-90 fps sandy/ivy bridge cpus take a significant lead in framerate.
In the few cpu bound game engines that exist FX series cpus get utterly destroyed. Take a look at SC2 and FC2 benchmarks for example.
In addition to this both the dolphin and pcsx2 communities have run benchmarks on bulldozer and piledriver for their respective emulators and proven repeatedly that they are terrible for emulation as well. So don't use them for emulated games either.
There are so many game benchmarks for piledriver/bulldozer from so many different sources all showing a small to substantial loss in framerate compared to sandy/ivy bridge in almost every game that I for one cannot understand why someone would attempt to recommend one of these things as a gaming cpu.
Cruzar Wrote:And according to some websites, say http://www.phoronix.com/scan.php?page=ar...ver2&num=1 show the FX chips demolishing Intel? HMMMM?
I wouldn't say demolishing. It won in some of the tests and it lost in some of the tests. In terms of the number of tests won/lost they look about equal.
AON3 also mentioned that they were all heavily multi-threaded. Which is not a good representation of the variety of real world applications that a user is likely to run. This is true but I would like to add to that. Nearly all of the benchmarks they used were either workstation/server applications, scientific applications, or synthetic applications. In other words the type of applications that this particular microarchitecture does well with. And it still lost in half of them. A good review will contain a wide range of different types of workloads/software that your average user is expected to use to see how well the architecture performs under the many different types of work that a typical user will be giving it. But we don't see that here. We just see the best case scenario. Honestly what are you more likely to do with your PC, run protein folding simulations or run dolphin?
Cruzar Wrote:And AMD's architecture is not the same as Intel, so no you cannot just toss the same coding at the AMD parts, that's like trying to throw the same code for a GTX 680 at a fucking HD 7970, or Geforce FX 5200, they're not the same they require different coding to work properly also the 5200 was shit and still is shit to this day so I just tossed it in for lulz.
AON3 properly addressed this as well. Modern graphics engines use the same codepath for different GPUs because they all run the same type of code (HLSL for d3d and GLSL/CGSL for openGL). So yes we do "toss the same code" at them because it's impossible to do otherwise with the abstraction present in modern operating systems. You would know this if you had done any graphics programming at all. But instead you're just making assumptions. So please knock it off. It's a waste of everyone's time to have to correct you.
Cruzar Wrote:And wow, doesn't mean they know diddly.
Please start quoting what you're responding to. I have no clue who "they" is or what "they" don't know.
Cruzar Wrote:Compiled with doesn't necessarily mean they left everything at defaults.
I assure you we've tried every GCC flag available.
Even if we hadn't a microarchitecture that requires a specially optimized binary just to perform on par with a competing microarchitecture running an unoptimized binary is inherently a bad microarchitecture. Case in point: The Netburst and Itanium microarchitectures.
Sandy/ivy bridge cpus are so far ahead in dolphin that no level of compiler optimization will allow an FX series cpu to perform competitively. I doubt even hand optimizing all of the code in assembly for piledriver would allow it to achieve the same performance that sandy/ivy bridge cpus are getting now.
Cruzar Wrote:If it were really optimized it would be faster, much faster.
How do you know this? What optimizations could be made to allow the FX series cpus to outperform sandy/ivy bridge cpus? Please bless us with your great knowledge of low level optimizations. Unless....you're making another assumption. But you wouldn't do that right? RIGHT!?!
Cruzar Wrote:Especially with better core/thread scheduling
That was fixed ages ago in the linux kernel and NT kernel. All modern piledriver benchmarks do proper thread scheduling.
Cruzar Wrote:rather than staying Dual/Triple
I have no idea what you're trying to say here. Dual/triple threading has nothing to do with the scheduling issues you were referring to earlier in your sentence.
If you're asking why dolphin is dual/triple threaded it is because like most applications it is literally impossible to gain any speedup from multithreading it any further. Dolphin has only 3 chips to emulate and the instructions for each chip must be emulated in sequential order or the result of the emulated function will be changed (thus breaking emulation). This makes parallel processing of the instructions incredibly stupid because of the resulting stall time from syncing/locking the threads. Despite this fact the developers tried it anyways and proved that it wouldn't work.
Cruzar Wrote:just because oh em gee Intel wont benfit ur stoped
Once again we need some context or we can't figure out what it is you're trying to say. And talking like that is extremely unprofessional so please avoid doing it if you wish to be taken seriously.
Cruzar Wrote:That's quite and Interesting claim. (Sarcasm)
See above.
Cruzar Wrote:not just them others too though hard to find what with most sites running benches/tests pretty much owned by Intel
This is beyond ridiculous. Peer reviewed benchmarks are literally the most accurate form of data collection for performance available on the planet. To claim that most hardware review sites are paid off by Intel is absurd. You have users getting the same results with the same software. An enormous number of sites, far more than Intel could even find let alone pay off. The lack of a guarantee that they will all accept your money. Most of these sites even go so far to make their employees sigh ethical clauses strictly forbidding it just to keep people like you happy. Then there is the fact that if even one site blows the lid on what you're doing it will utterly ruin your companies reputation. This means the only way you could be right is if Intel has personally tracked down and bribed every single website and user that has ever benchmarked their products and somehow ensured that none of them would ever admit to it. In other words it's a worldwide conspiracy by tens of thousands of people (at least, probably more) including random users. I am absolutely stunned that someone would make such a claim.
Cruzar Wrote:did tests of their own and the FX only occasionally looses to Intel in real world scenarios an 8350 can sometimes even keep up with a 3820.
"Sometimes" is the key word there. And yes you're right they do keep up with the i7 3770K and 3820 in some applications. The problem is that the type of workload needed for them to perform this well is very rare in real world applications and even when these chips do perform competitively they require more power and generate more heat to do it. Which is why OEMs won't touch them with a 10 ft. pole.
Cruzar Wrote:Also the cinebench scandal was a scandal involving cinebench and the Intel compiler they (and other synthetic benchmarks writers) used,
That's not a scandal. They have openly admitted which compiler they use from day one. ICC is a compiler that is made for Intel and is therefore optimized for Intel cpus, everyone knows that. It's not Intels fault that AMD hasn't bothered to invest R&D money into making their own compiler.
Cruzar Wrote:of which when detecting an Intel chip did it the most optimized way possible, but if it saw an AMD chip, it did it the worst way possible making sure even though your processor clearly can do and is doing much better than the test so claims, that you think your processor is slow as shit and worthless and that you must OMG buy Intel, buy Intel, when patched to make it think you're always on Intel, AMD chips had a massive performance jump.
This is true to some extent. However I must point out two things that nullify this argument being used to defend the FX series cpus:
1. Only a small fraction of the software typically used for benchmarking these cpus is compiled with ICC. You can't simply ignore all of the other results which are equally poor just because some tests use ICC. The results with software compiler on other compilers are generally just as bad.
2. If your favorite software runs faster on Intel cpus and part of the reason is ICC you shouldn't stop using Intel cpus just because it's "not fair". The goal of a cpu is to run the software that you use faster and with a lower power consumption. You shouldn't really care how it's achieved. Is it fair? No. Is it a valid reason for not buying Intel cpus? No.
Also the benefits of using Intel CPUIDs in ICC are grossly exaggerated by the AMD community. In nearly all tests done on the subject the performance difference has been shown to be small or nothing depending on the type of workload. In dolphin for example there is typically little to no difference comparing Intel vs. AMD on ICC and GCC. The only software the really gains any benefit at all are those that extensively use newer SSE instructions (which to fair cinebench probably does).
You can't just dismiss bulldozer/piledrivers architectural weaknesses just because some software uses ICC. AMDs microarchitectures are still missing a lot of features that are very important for many workloads. They still don't have micro-op fusion, macro-op fusion, a microcode cache, a 6 wide execution pipeline, and the list goes on and on. No level of software optimization will make up for the lack of these features. Certain algorithms are just going to run poorly no matter what without these features. A good cpu microarchitecture is one that can run a wide range of algorithms well, not just some. If piledriver was massively faster in optimal workloads then we could forgive all of the crappy results. But it's not. It ranges from "much slower" to "about the same or slightly faster" depending on the application. Combine this with a higher power consumption and lack of integrated graphics and it clearly becomes the lesser architecture.
To summarize:
-Stop blaming programmers for everything. Believe it or not there is such a thing as a genuine hardware weakness. Sometimes hardware can do a specific task in a more optimal way. Claiming that anytime something is slower than something else it must be the programmers fault is insane. A K7 cpu for example is just flat out inferior to todays cpus even when running the same code at the same clock rate. Its pipeline design is simply less optimal. Blaming programmers for this would not be logical.
-Vishera (piledriver FX series) cpus performance relative to ivy bridge i7s mostly range from "much worse" to "about the same" depending on the application. Overall their performance is poorer. These benchmarks have been done by both professional organizations and random users on the internet with comparable results so there is no reason to doubt them. If you want to have the fastest overall cpu regardless of price your only option is Intel at this point.
-FX series cpus generally do slightly worse in framerate tests and dramatically worse in frame time tests. In cpu bound games their framerates are much poorer. This makes them a bad choice for PC gaming.
-Both the dolphin and pcsx2 communities have conducted community benchmarks and found that FX series cpus to no ones surprise perform poorly in emulators.
-FX series cpus consume more power and produce more heat despite have suboptimal performance.
-While the FX series cpus can overclock higher overclocking them even a tiny bit causes their power consumption (and therefore heat) levels to shoot up to up to crazy high numbers. The same level of overclocking can be achieved on competing Intel cpus with dramatically lower power consumption and heat. Making them the better choice for most overclockers who don't have access to phase change cooling or any other exotic form of cooling (not to mention the risk of condensation and rapid electrical/chemical damage to the hardware associated with using that kind of cooling solution).
-AMD has realized that their chips are inferior. That is why they have had to price them so much lower in order to sell them. Their idea is to provide a chip that can produce comparable performance to i5 and i7 cpus in some applications (primarily those that are heavily multithreaded) at a lower cost. In exchange for this users will have to deal with higher power consumption, greater cooling requirements, lack of integrated graphics (which is important to bringing down total system cost for non-gamers), and poor performance in many applications that don't have a workload that is optimal for this type of architecture. But you do get similar performance in some applications at a lower cost. If that weren't the case they wouldn't be able to sell them at all. If you happen to use those applications extensively by all means buy one. But it sounds to me like the types of applications you plan on using are not well suited to this architecture. So you would be wise to avoid it.
AnyOldName3 Wrote:Picture a road with a narrow bit cars have to slow down to pass. This is the GPU. If you make another bit of the road wider, it means more cars can pass through that area, but it won't make a huge difference to how many cars get to the other end per unit time, because they all have to go through the narrow bit. In the real world, this model isn't perfect, but it's enough to give you an idea of how bottlenecking works. It also allows me to point out that the French for traffic jam is embouteillage, which literally translates as bottling or bottlenecking, which is one of the few things I can remember from being taught French.
This analogy is more confusing and inaccurate than it is helpful. This is why I generally avoid trying to compare electronics to other types of systems for the purposes of explanation.
AnyOldName3 Wrote:It is very, very difficult to make a program favour one microarchitecture over another if they are both supposedly the same speed.
I strongly disagree with this. Compiler and code optimizations can both be used to shift an algorithm from favoring one microarchitecture to another.
"Normally if given a choice between doing something and nothing, I’d choose to do nothing. But I would do something if it helps someone else do nothing. I’d work all night if it meant nothing got done."
-Ron Swanson
"I shall be a good politician, even if it kills me. Or if it kills anyone else for that matter. "
-Mark Antony
-Ron Swanson
"I shall be a good politician, even if it kills me. Or if it kills anyone else for that matter. "
-Mark Antony