Printable View
Some of you won't be pleased. The leaks were correct.
http://techreport.com/articles.x/21813
http://www.bit-tech.net/hardware/cpu...-8150-review/1
http://www.tomshardware.com/reviews/...90fx,3043.html
http://www.computerbase.de/artikel/p...amd-bulldozer/
http://ht4u.net/reviews/2011/amd_bul...x_prozessoren/
http://www.hardware.fr/articles/842-...arque-am3.html
http://www.anandtech.com/show/4955/t...-fx8150-tested
Indeed...
i am sure you are delighted to post these here, it is very clear that something is really hitting the single threaded performance and the reason to the rather low BD results....
Delighted? If I'm delighted is at interpreting correctly and making an accurate assesement of BD's performance over 1 year ago. I can't be delighted at AMD's misery or the sorrow experienced by its fans.Quote:
Originally Posted by duploxxx
What I'm pissed at are the numerous fanboys who constantly booed, insulted and mocked me and others and now have dissapeared without a trace.
And the results are "rather low" only for those who didn't follow the whole saga.
-the uarch was simplified, less execution INT units, FPU shared, longer instruction latencies , loosing 5% IPC for 20% more frequency ( this was the plan )
-the implementation sucked because if was done with synthetised tools ( 20% larger blocks and 20% slower than hand crafted )
-the process is borked, variability is high, yields abysimal and power is out of control ( frequency is lower than expected and parts are more power hungry )
This things were known for a year. Only one who did not want to see the truth could be surprised now at the performance.
They expected the a slight loss in IPC for existing code compensated by the increased frequency. The frequency gains were reduced in the implementation phase due to a high use of automated placing and routing tools, the end result being a part 20% larger and 20% slower than it could have been had it been carefully optimized. Yet, on top of that, the process failed to live to the expectations. It's a whole chain of events which killed BD.
Had everything worked right, taking a base Thuban of 3.3GHz, a 32nm BD should have lost 5% on IPC, gain 20% frewquency by uarch ( 4GHz ) and another 20% from process ( 45->32nm ). We would have had a 4.5-4.8GHz BD with slightly less IPC than a Thuban, in other words a part performing 30-100% ( in AVX/FMA cases ) better than Thuban. What we ended up with is a part that is +/- 10% of Thuban while being hotter.
this is netburst all over again, hopefully future revisions fix this because at current it isn't even worth its price compared to a 1100T, let alone 2500k which is still cheaper.
http://www.kitguru.net/components/cp...te-990fxa-ud7/
^ Gigabyte UD7 F5 bios. was a nice read at least for me :/
Just wait for C3
As an AMD consumer I'm pretty sad about these results, but lets face it, those that call themselves CPU experts (Hans de Vries & the rest of the fun factory) were the ones that made the most wrong predictions about BD performance.
If these are your points, then you got a seemingly right result by using some false input ;)Quote:
Originally Posted by savantu
I agree with you on the process thing.
But
1. The execution hasn't been hit as much as one might think. I've shown that here:
http://translate.google.com/translat...#content_start
Performance problems very likely a result of legacy code "enjoying" many pitfalls, which in turn cause bottlenecks, e.g. right in the decoding stage. But engineers didn't develop an revolutionary architecture to improve execution of K8/K10/NHLM/SB code. If they'd wanted to do that, they'd further improved 10h at less costs.
2. You mix the synthetized design of Bobcat with Bulldozer. And even in case of Bobcat they can still use hand crafted macros to mitigate that effect. Same for ARM.
I agree with you, that this is a "Pentium-4-Launch"-like situation. But that hasn't been fixed via hardware (Northwood after Willamette still was a Netburst design), but by software (more recent software has been optimized for this design).Quote:
Originally Posted by Shadowized
I'm not aware of Bulldozer performance predictions by Hans de Vries. Can you point me to such predictions?Quote:
Originally Posted by Brice MJ
Mine ? 2 of them are from ex-AMD senior architects and the 3rd, GF is a compilation of available data. Given the input, you are surprised of coming to the right result ? Shocking.Quote:
Originally Posted by Dresdenboy
Legacy code ? What exactly is legacy ? Everything not compiled with BD uarch in mind, XOP and FMA ? I'm not mentioning AVX since the implementation seems extremely fragile and causes performance degradation when used. ( see thread at RWT )Quote:
But
1. The execution hasn't been hit as much as one might think. I've shown that here:
http://translate.google.com/translat...#content_start
Performance problems very likely a result of legacy code "enjoying" many pitfalls, which in turn cause bottlenecks, e.g. right in the decoding stage. But engineers didn't develop an revolutionary architecture to improve execution of K8/K10/NHLM/SB code. If they'd wanted to do that, they'd further improved 10h at less costs.
In x86 you need to maintain performance and old, legacy ( that is SW from 5-10 years ago ), current one and the future ( AVX, FMA3 ). There is only one culprit to blame if BD does poorly on legacy and current SW. That's AMD management.
They will learn the hard way the Pentium 4 lesson : even Intel couldn't get code optimized fast enough ( and back then there weren't so many ISVs and standards, OpenCL,Java, uarch-independent source code, etc ). By the time SSEx SW and TLP started to catch on, Pentium 4 was on the chopping block and Core was on the horizon.
AMD launches BD now. By the time FMA code will be common, BD will be like P4 today, a distant, ugly memory. As for XOP and BD optimized code paths, given its lackluster reception, most developers will avoid investing too much time and resources.
Btw, BD reinforces the fact that optimizing for product famillies and not just checking for features ( like Intel's compiler does ) is the right way with BD. BD has AVX for example. But its implementation is suboptimal . It should be avoided. If the Intel compiler would check the feature flags, it will churn auto AVX 256bit code which will have a terrible performance for BD. Eric Bron mentioned this interesting twist.
http://wwww.realworldtech.com/beta/f...22980&roomid=2
You're basically arguing with an AMD senior architect,Cliff Meier, the ex-guy in charge of the design flow.Quote:
2. You mix the synthetized design of Bobcat with Bulldozer. And even in case of Bobcat they can still use hand crafted macros to mitigate that effect. Same for ARM.
His comments are directly related to BD.Quote:
I don't know. It happened before I left, and there was very little cross-engineering going on. What did happen is that management decided there SHOULD BE such cross-engineering ,which meant we had to stop hand-crafting our CPU designs and switch to an SoC design style. This results in giving up a lot of performance, chip area, and efficiency. The reason DEC Alphas were always much faster than anything else is they designed each transistor by hand. Intel and AMD had always done so at least for the critical parts of the chip. That changed before I left - they started to rely on synthesis tools, automatic place and route tools, etc. I had been in charge of our design flow in the years before I left, and I had tested these tools by asking the companies who sold them to design blocks (adders, multipliers, etc.) using their tools. I let them take as long as they wanted. They always came back to me with designs that were 20% bigger, and 20% slower than our hand-crafted designs, and which suffered from electromigration and other problems.
He was spot on 2 years ago.Quote:
On paper bulldozer is a lovely chip. Bulldozer was on the drawing board (people were even working on it) even back when I was there. All I can say is that by the time you see silicon for sale, it will be a lot less impressive, both in its own terms and when compared to what Intel will be offering. I don't really want to reveal what I know about Bulldozer from my time at AMD, nor do I want to go into details of what my friends are telling me.
many people don't rush to buy fx after read those review
OK. An article citing AMD's design methology for Bobcat (incl. the 20% remark):Quote:
Originally Posted by savantu
http://tech.icrontic.com/news/amd-sa...tests-ontario/
And cmaier citing how AMD management asked engineers to use new methods and how this costs 20%:
http://forums.macrumors.com/showpost...&postcount=559
But you also know how synthesized logic does look like? Bobcat clearly shows this. I can assure you it doesn't look as regular logic in a Bulldozer module. OTOH I know that there are tools to generate a multiplier etc. (still looking regular) - this has for example been used by one of AMD's FPU architects for his dissertation research.
http://wwww.realworldtech.com/beta/f...22980&roomid=2[/QUOTE]Quote:
Originally Posted by savantu
With "legacy software" I mean the existing code base. And even unless there is a lot of ASM code in it (as in x264 or Prime95) it shouldn't be too difficult to adapt it. It's a similar thing as AMD's Fusion approach: They heavily depend on software supporting it. And they told us so on slides since 2 or more years.
That 256b AVX might perform worse than 128b AVX is not new to me and you surely know that. SB needs AVX to access additional throughput. BD does not. Instead it just adds overhead and some complexity. This is why for GCC there was a patch to go AVX128 which gains some percent in performance. 128b AVX has the advantage of the 3 operand form.
I already discussed Dark_Shikari's findings at several places. And even AMD's compiler guide suggests to avoid the AVX flag when using the Intel compiler ;) Problem here very likely is that AVX for ICC means to use 256b if possible.
As I wrote on P3D some managed code environments might benefit early since they contain JIT compilers, which optimze byte or p code on the fly. Adapting the compilers is enough to improve performance of existing apps.
And regarding P4:
IIRC it didn't take that long for software updates. There are still the regular upgrade cycles of software and often with the next scheduled cycle there came the necessary update.
OTOH it seems that "Bulldozer" what we are currently looking at is just the first working incarnation. You know the roadmap and I also posted early enough about BDv2, Steamroller and other bits. Further there are things, which were mentioned in the patents but didn't show up so far, while 80% or so became real silicon.
Using my Pentium D 945 as an example, it works friggin great in Vista/7 64bit. We all know P4s were terrible with XP for the most part. It seems sofware caught up with the P4s design. Unfortunately software needs to catch up to Bulldozer as well, but AMD isn't Intel. Software engineers likely aren't as motivated to code for this radical new design.
As long as they don't use assembler most of the time, they just might have to update their compiler and check the correct flags. I see the problem in the instruction scheduling, sth that happens in the compiler back end invisible to the user.Quote:
Originally Posted by Mechromancer
Remember back when AMD used to release drivers for the CPU in Windows XP days? Why can't they do the same thing now with Windows Vista or Windows 7?? Wouldn't this help to resolve these processor single-threaded traffic issues??
anyone see this review? Thought it was pretty good.
http://www.kitguru.net/components/cp...te-990fxa-ud7/
Quote:
Originally Posted by demonkevy666
ME at least! LOL at me being ignored hereQuote:
Originally Posted by charged3800z24
It's kitguru...
Must have missed it, lol... sorry :p:Quote:
Originally Posted by demonkevy666
I didn't think kitguru was all that reliable.
http://www.hardwareheaven.com/review...roduction.html
I cant belive no one mention this..
Look really good in some games.
What I've noticed is that BD performs decently (not a world beater by any means, but in the 2500K class) as long as your not using an ASUS board. No surprise there.