AMD Piledriver rumours ... and expert conjecture

Page 6 - 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 ...
 
Why are mods so intent on leaving any Fusion or Trinity reference out of thread titles? Especially since Trinity is the direct competitor to ivy bridge. Because of a fear of it gaining traction, or?
 
Why are mods so intent on leaving any Fusion or Trinity reference out of thread titles? Especially since Trinity is the direct competitor to ivy bridge. Because of a fear of it gaining traction, or?
Uhh, no it isn't. Trinity is the next line of APUs and isn't directed toward Ivy Bridge. This thread is about Piledriver, not Fusion or Trinity.
 
Uhh, no it isn't. Trinity is the next line of APUs and isn't directed toward Ivy Bridge. This thread is about Piledriver, not Fusion or Trinity.


Trinity is still pretty important as its coming before Piledriver(without graphics).

Trinity will give us a big clue on how Piledriver will perform. - the L3 cache.
 
Technically, Vista was the first OS by MS with *proper* HTT support. And HTT, like CMT, is just a form of SMT. If BD is telling the OS that it has 8 cores, but 4 of those cores are really only 80% efficent, you shouldn't be upset when the OS incorrectly uses those cores. Thats EXACTLY why we have the CPU ID field, but AMD, for whatever reason, refuses to call its processors a 4+4 approach...

AMD could fix the scheuling problem TODAY with a simple BIOS update that would assign the second core of a BD module as a logical core.


You are under the incorrect assumption that if they pretend that BD works exactly the same as HTT then everything will work fine. But that is only part of the problem. So your simple bios update would never completely fix the issue.

Also Windows 7 was the first version of Windows that correctly supported hyperthreading. Vista had some functionality but there was still about a 10% performance hit.
 
"Adam Kozak is a product marketing manager at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites, and references to third party trademarks, are provided for convenience and illustrative purposes only. Unless explicitly stated, AMD is not responsible for the contents of such links, and no third party endorsement of AMD or any of its products is implied."

harharhar

It's just that disclaimers on blogs amuse me..


So in general, they made bulldozer for best use with really NEW apps that use multiple threads (not just 2 or 1?)

Bulldozer has 8 cores right? Does that mean any apps made for 8 threads won't work on anything but bulldozer?

is that there evil plan..?
 
Aren't MB manufacturers responsible for BIOS updates? Is there any reason one of them could not change the way cores are reported?

yes but fixes will still come from Intel or AMD if needed. Its up to the mobo maker to apply these fixes.

You are under the incorrect assumption that if they pretend that BD works exactly the same as HTT then everything will work fine. But that is only part of the problem. So your simple bios update would never completely fix the issue.

Also Windows 7 was the first version of Windows that correctly supported hyperthreading. Vista had some functionality but there was still about a 10% performance hit.

Actually he did post a article a guy did with changing it the exact way he stated and BD improved 10-20% in some areas.
 
Guys Trinity discussion is fine since it is supposed to use the PD core.

Frankly we have no concerns about discussing improvements PD is likely to have over the present BD core either ... just keep it civil.

I can start a Future mobile CPU sticky thread for AMD and Intel if you want too?

Things are really moving ahead in the mobile area ...

Just PM me what you want and I will put it up so people can discuss the appropriate topic in the best thread.

Otherwise stickies like this will become a toilet and fill up with posts about lost GF's, PSU's and boothbabes ...

We are trying to keep stuff in one spot so the enthusiast like most of you here will keep adding to the sticky, and it becomes a bit of a resource rather than a breeding ground for the mythical war between red and blue.
 
You are under the incorrect assumption that if they pretend that BD works exactly the same as HTT then everything will work fine. But that is only part of the problem. So your simple bios update would never completely fix the issue.

Also Windows 7 was the first version of Windows that correctly supported hyperthreading. Vista had some functionality but there was still about a 10% performance hit.

As far as scheduling goes, both CMT and HTT are SMT approaches, where a group of cores carries a performance hit due to shared resources. The only real difference is to what degree.

Calling the second core of a BD module a logical core [which it IS] would tell the OS to avoid using said core whenever possible, which would avoid that ~20% performance hit. Granted, SOME extra optimization could be done for workloads that do not carry as large a performance penalty, but that simple fix would fix the majority of the problems on the scheduling side.
 
As far as scheduling goes, both CMT and HTT are SMT approaches, where a group of cores carries a performance hit due to shared resources. The only real difference is to what degree.

Calling the second core of a BD module a logical core [which it IS] would tell the OS to avoid using said core whenever possible, which would avoid that ~20% performance hit. Granted, SOME extra optimization could be done for workloads that do not carry as large a performance penalty, but that simple fix would fix the majority of the problems on the scheduling side.


SMT and CMP are both methods used to implement CMT. (HTT is just what Intel calls SMT.) The BD design is much closer to CMP than it is SMT. CMT does not always carry the baggage that you describe.

QUESTION: If merely telling the BD chip to act like SMT would fix most scheduling problems; does anybody believe that AMD would not have done so? The only logical explanation to explain why they have not done so would be that this simple kludge would not be completely acceptable. (Probably because it addresses only affinity issues.)

There is a delicate balance between chip hardware, microcode, bios, operating system, and applications. It is unknown exactly where any issues might be at this time; but by the time PD is released they should have tweaked that "balance". It is also extremely probable that the simple fix you mention might provide instant gratification while at the same time crippling performance for when the other elements are properly balanced.



 
http://lenzfire.com/2011/10/amd-bulldozer-is-tested-for-its-performance-in-an-effective-way-80084/

Any truth to this?

Yes, though it is a rehash of an article that was already posted either here or in the BD fail thread.

Forcing Win7 to run apps on non-consecutive threads can result in improved performance.

Hopefully we will see Win 8 and/or 7 correctly supporting the module arch by the time PD is released, although I doubt it is likely unless PD is delayed.

Edit: added op.
 
QUESTION: If merely telling the BD chip to act like SMT would fix most scheduling problems; does anybody believe that AMD would not have done so? The only logical explanation to explain why they have not done so would be that this simple kludge would not be completely acceptable. (Probably because it addresses only affinity issues.)

"The worlds first consumer 8 core processor"

And tests have shown that simply changing a programs affinity does have ~15-20% impact, which is what you would expect.

http://lenzfire.com/2011/10/amd-bu [...] way-80084/

Any truth to this?

Wouldn't be shocked; no different then say how hyperthreading reduces performance in BF3. Using cores that do not scale to 100%, for various reasons, may actually hurt performance. And in this case, in some workloads, even AMD's CMT approach is worse then simply not using the cores at all.

Hence, why fewer, more powerful cores is the way to go, which is what I've been arguing since BD was first announced.
 
And tests have shown that simply changing a programs affinity does have ~15-20% impact, which is what you would expect.

If it can be shown that using a kludge like you advocate has absolutely no negative impact on future performance in a variety of situations then it should be implemented. If that can not be shown beyond a shadow of a doubt then that solution should not be implemented and we just have to wait until a kernel patch is ready.

Since AMD is taking the latter action then we can surmise that what you are advocating is not an acceptable solution. Or it is possible that they haven't fully regression tested your proposed solution to the point that it can be implemented GA. (Which is doubtful. If it was that easy they would have done it already.)

It is possible that PD might have additional tweaks and might require more OS patches than BD. On the other hand it is possible that PD might have tweaks that would allow your solution to be implemented at that time while they can't do it with BD. Or they might be working on a combination of everything so that they don't have to go through this situation again in the future. (I.e., it is often a very poor idea to take a shortcut when you can spend some extra time and do things correctly.)

Keep in mind that the technical personnel at AMD were suggesting a longer delay before release; it was management that decided it was time. So it is probable they were working on things that might have made this all a moot issue if they had time to finish. (That would explain why a Windows kernel patch was not available... they didn't expect to need it.)
 
Not a promising start:

In the history of the microprocessor architecture, AMD Bulldozer is the only processor with lot of rumors and delays before its launch.

Um... huh?!?

What I found interesting was this:

Why AMD prefers TSMC to manufacture Bulldozer?
It’s a known fact that Bulldozer has been delayed lot of times and one of the main reason behind this delay is Global Foundries, which has been having some issues in 32nm manufacturing process. Also there is shortage of supply of AMD A series Llano APUs, in this case too Global Foundries stands as the reason.

AMD’s C-series and E-series APUs have been manufactured by TSMC. Also the upcoming low power APUs too will be manufactured by TSMC. Also AMD doesn’t have any APUs manufactured currently in Bulldozer architecture, whereas Trinity will be the APU which will be manufactured with Piledriver modules.

Does TSMC even have an SOI 32nm process?

Also, saw THIS today:

AMD (NYSE: AMD +4.95%, news) today announced a restructuring plan and implementation of operational efficiency initiatives designed to strengthen the company's competitive positioning. AMD expects that these combined actions will create a more competitive cost structure and rebalance the company's global workforce skillsets, helping AMD to continue delivering industry-leading products while improving productivity, reducing time-to-market and better aligning with key industry trends that are expected to drive growth.

AMD expects that the restructuring plan will result in operational savings, primarily in operating expenses, of approximately $10 million in the fourth quarter of 2011 and $118 million in 2012, primarily through a reduction of its global workforce by approximately 10% and the termination of existing contractual commitments. The workforce reduction will occur across all functions globally and is expected to be substantially completed by the end of the first quarter of 2012. Based on anticipated savings from the restructuring plan, AMD expects fourth quarter 2011 operating expenses will be approximately $610 million.

Wonder how many of that 10% are the BD/PD engineers?
 
Also, saw THIS today:

AMD (NYSE: AMD +4.95%, news) today announced a restructuring plan and implementation of operational efficiency initiatives designed to strengthen the company's competitive positioning. AMD expects that these combined actions will create a more competitive cost structure and rebalance the company's global workforce skillsets, helping AMD to continue delivering industry-leading products while improving productivity, reducing time-to-market and better aligning with key industry trends that are expected to drive growth.

AMD expects that the restructuring plan will result in operational savings, primarily in operating expenses, of approximately $10 million in the fourth quarter of 2011 and $118 million in 2012, primarily through a reduction of its global workforce by approximately 10% and the termination of existing contractual commitments. The workforce reduction will occur across all functions globally and is expected to be substantially completed by the end of the first quarter of 2012. Based on anticipated savings from the restructuring plan, AMD expects fourth quarter 2011 operating expenses will be approximately $610 million.

Wonder how many of that 10% are the BD/PD engineers?

Ouch. I am seriously sorry to see that. Layoffs are never a good thing, but in this economy it's especially nasty.
 
QUESTION: If merely telling the BD chip to act like SMT would fix most scheduling problems; does anybody believe that AMD would not have done so?

Um, yes if it was a marketing decision "let's be the first to claim 8-core desktop CPUs!". If it was presented as a 4-core CPU with advanced SMT, wouldn't be nearly as newsworthy and drive sales.

There is a delicate balance between chip hardware, microcode, bios, operating system, and applications. It is unknown exactly where any issues might be at this time; but by the time PD is released they should have tweaked that "balance". It is also extremely probable that the simple fix you mention might provide instant gratification while at the same time crippling performance for when the other elements are properly balanced.

OTOH if a simple BIOS setting is all it takes to improve performance by 20%, then once the 'balance' you allude to is achieved, just turn off the BIOS setting. Another pretty simple fix, no??
 
OTOH if a simple BIOS setting is all it takes to improve performance by 20%, then once the 'balance' you allude to is achieved, just turn off the BIOS setting. Another pretty simple fix, no??


Which solution produces a higher amount of bad press:

A true fix that takes time to implement.
OR
A kludge that can be immediately implemented but only addresses part of the problem. And it could actually cause issues in the future if it is not disabled.

Plus you have to remember that even this "simple" fix will be required to undergo the full battery of regression testing before they will release it. An in truth they have to perform all that regression testing twice: With and without the "simple" fix. Then twice again after the true fix is released since they can't count on people disabling the "simple" fix in the bios. That makes for a total of four full sets of regression tests. I'm sure all the managers are lining up to sign off on that. (You do realize that this testing is actually where most of the labor of releasing a new chip goes?)

 
Which solution produces a higher amount of bad press:

A true fix that takes time to implement.
OR
A kludge that can be immediately implemented but only addresses part of the problem. And it could actually cause issues in the future if it is not disabled.

Hmm, well a partial kludge is better than nothing at all. Plus you should remember AMD already went down that route with the Barcelona TLB bug patch that killed 10% performance in the interest of preventing some rare data loss occurrence.

Besides, it is entirely possible AMD did not know of this simple fix. If the GF yields were such that they had to keep doing respins to get the clocks up, perhaps they concentrated on that instead.

But if the truth were known, I'd bet on the marketing team making the decision. BD took something like 5 years to develop, and the finance people probably said 'let's sell this sucker and get some of that R&D $$ back' and the marketing team said "OK, it's 8 cores or nothing".

Plus you have to remember that even this "simple" fix will be required to undergo the full battery of regression testing before they will release it. An in truth they have to perform all that regression testing twice: With and without the "simple" fix. Then twice again after the true fix is released since they can't count on people disabling the "simple" fix in the bios. That makes for a total of four full sets of regression tests. I'm sure all the managers are lining up to sign off on that. (You do realize that this testing is actually where most of the labor of releasing a new chip goes?)

Yes I and possibly 50 other posters here are aware that validation testing is so complex nowadays that it takes up lots of time and $$ 😛. But I doubt that such a fix and/or disablement of same would require nearly as much testing as the original validation test - probably could get done in a week or two. How long did it take AMD to come up with the TLB patch?

Anyway, the mobo vendors or system OEMs could also email everybody who bothered to register their products that a new BIOS version was available and disable the fix through an update. Heck, mail them a bootable CD or cheap flash drive - no need to have some unskilled Joe Sixpack mucking around with BIOS settings.
 
Status
Not open for further replies.