[Commenter]

Well, I've ditched my bulldozer now, thankfully. The performance per watt lag of AMD behind Intel is nothing short of horrible these days, and AMD should probably pull out of the CPU market, and concentrate on their graphics cards and APU's for laptops where they still retain an advantage in terms of performance. I know that will unfortunately kill innovation on Intel's part but I think AMD have released too many bad products to be a viable competitor anymore.

[Silent_Buddha]

Too many bad products? I believe that their Fusion APUs thus far have been a fair success. And those are targetted not only at the mobile but the desktop space as well.

Regards,
SB

[Commenter]

AMD should really have waited until Piledriver at least before releasing a inefficient unfinished architecture. Now their reputation has gone up in flames. Intel will deliver the killer blow soon enough. Sorry, if that's sounds fanboyish, but AMD have had their chances to turn themselves around.

[Rodéric]

I don't think Intel can afford to lose AMD competition.

[Commenter]

Explain that one to me. What company wouldn't want 100% market share?

[upnorthsox]

Originally Posted by Commenter

Explain that one to me. What company wouldn't want 100% market share?

Ones that don't want to face a monopoly suit?

[ToTTenTranz]

Originally Posted by upnorthsox

Ones that don't want to face a monopoly suit?

And ones that may not have the factory capacity to cover the whole world with x86 solutions, a flaw that would drive their customers to ARM solutions.


Compared to ARM (which means Qualcomm+Samsung+Apple+ST-Ericsson+TI+nVidia+Mediatek+AMLogic+Huawei+many others together), AMD is Intel's best friend nowadays.

[upnorthsox]

Originally Posted by ToTTenTranz

And ones that may not have the factory capacity to cover the whole world with x86 solutions, a flaw that would drive their customers to ARM solutions.


Compared to ARM (which means Qualcomm+Samsung+Apple+ST-Ericsson+TI+nVidia+Mediatek+AMLogic+Huawei+many others together), AMD is Intel's best friend nowadays.

Good point.

[swaaye]

Intel surely could build up their capacity if they saw the need.

[nutball]

Originally Posted by ToTTenTranz

And ones that may not have the factory capacity to cover the whole world with x86 solutions, a flaw that would drive their customers to ARM solutions.


Compared to ARM (which means Qualcomm+Samsung+Apple+ST-Ericsson+TI+nVidia+Mediatek+AMLogic+Huawei+many others together), AMD is Intel's best friend nowadays.

Somewhat tangential to the original question don't you think? Which was about desktop space...

[Mize]

Here is where I insert my standard rant about how mind-numbingly stupid you have to be to think that having a single player in any market segment is good. Competition breeds lower prices and better performance. Monopoly breeds high prices and stagnation.

[Richard]

Originally Posted by nutball

Somewhat tangential to the original question don't you think? Which was about desktop space...

Well, ARM (thus, all the others) has a break with Windows 8. All those nettop computers and, heck, mostly all corporate PCs could run on ARM except for one little, tiny, detail: lack of desktop application support. In spite of that, I think it will be good for ARM. Obviously, I don't believe they could make up for AMD leaving the desktop market though.

Originally Posted by swaaye

Intel surely could build up their capacity if they saw the need.

Could? Probably. Would they? Would they want to even? Probably no on both of these. Why invest millions to grab a share of the market they could end up losing again in a few years to ARM or whoever? Why not simply raise prices because of Supply & Demand: much more profitable.

Speaking of which, like Mize I'm a bit dumbstruck at the notion that someone could argue one company should say goodbye out of a market where only another company competes. No matter how incompetent AMD might have been/is/whatever, it still does a far better job than having no competition at all.

The first consequences would be a meaningful markup on Intel CPUs. Mid-term we'd have the same CPUs as now, just with bigger numbers on the box.

[Tahir2]

If Steamroller adds more performance per clock over Piledriver you will find that AMD are right back in the game. Piledriver per clock was found to be something like 15% better than Zambezi.

Our per-clock cycle testing suggests that the revised design, as it’s implemented on Trinity, is as much as 15% faster than Bulldozer.

http://www.tomshardware.com/reviews/...k,3224-21.html

This was achieved without improvements to the cache architecture which remains about the same.

IMHO - I may be upgrading to a Steamroller based CPU in the very near future!

[3dilettante]

AMD isn't sized to waltz out of the desktop market. It's too big and too unsuccessful with the market share it has now across all its segments.

At any rate, it already has effectively given up on the desktop market, since the chips it uses to service desktops are server or laptop chips that don't make the cut for their respective bins.
What else is AMD going to do with those?

[tongue_of_colicab]

And that matters why?

Reality is 99,99% of the market doesn't care or doesn't need a high end cpu. Even basic photo/video edeting can be done withouth a problem on the low end chips (hell, I had to design a whole website with just my amd e450 laptop, not the fastest thing in the world but it works fine if you don't try to do 10 things at the same time). Even for gaming you don't really need a fast chip. My q6600 still runs all games more than good and I believe that compares to something like a i3 these days.

AMD might not be competing with intel when it comes to the fastest cpu's but they have some great products. On the laptop/netbook side they are, imo, a better choice than intel because AMD actually delivers a gpu that works and on the desktop side you can build a really nice system for much less money than when you would buy the same at intel.

[Frank]

I just bought new innards for my main pc, with an AMD octo-core FX-8120. Ok, I know it's only roughly a 6-core and the upper Intel i5s and i7s are faster for applications that use ~2 cores, out of the box.

However, it is faster than any Intel less than 150% as expensive. And it suffers mostly from bad scheduling by the Windows task scheduler. Because it requires just about the opposite approach of an Intel. Let me explain.

If you run applications that use multiple cores, you'll see that the first, third, and (when available) fifth and seventh core are all pushed to the max, while the even cores are mostly idle. Because the Windows scheduler expects those cores to be virtual, hyperthreaded ones. And it makes more sense to use a "full" core than a "virtual" one, to balance the load.

Further, it tries to keep processes on that same core as much as possible, to prevent cache misses and rescheduling demands.

Then again, if you use an AMD CPU, the opposite makes more sense: try and schedule multiple threads of the same processes on the same core pair. That increases the overall speed and prevents stalling.

The octo-cores do have a full set of 8 integer pipelines, only the floating point and special units (which are faster than the Intel ones) are shared. That means, that if a thread is waiting on the result of another one, it will stall if it isn't running on the same core-pair while using the special units. Which you can easily see in the Windows task manager: while the Intel cores tend to have an average load that fluctuates mildly, the AMD load tends to consist of spikes.

Or, in other words: they stall all the time.

So, the problem isn't so much bad/slow AMD processors, as it is bad scheduling in Windows that greatly favors Intel CPU's.

And as soon as software can really make use of 8 cores or if you like virtualizing, those octo-cores will outperform the more than twice as expensive Intel ones.

[3dilettante]

Your usage case must be relatively uncommon, since Windows didn't do what you are describing until performance complaints prompted an AMD-specific change to move threads across modules in a manner resembling the optimum for Intel.

[Frank]

Originally Posted by 3dilettante

Your usage case must be relatively uncommon, since Windows didn't do what you are describing until performance complaints prompted an AMD-specific change to move threads across modules in a manner resembling the optimum for Intel.

You mean something like this? Seems different to what you describe.

[3dilettante]

That article points out that the scheduler defaults to moving threads to inactive modules first, then to inactive secondary cores, which is an improvment over what Windows did prior.

I wouldn't blame Windows for having worse scheduling prior to the change. I'd say the blame is more on a fragile architecture that requires more handholding than most.

[RudeCurve]

I have no regrets with my two new FX8120 and FX4100 builds. They were relatively cheap too. Didn't see a need to go with Intel.

[3dilettante]

They should be priced roughly where their performance lies. If a given chip is in your price range and your usage model isn't an extreme outlier, I don't think there's a reason to regret anything.

The nature of AMD's situation is harsher, but that's not the buyer's problem.

[eastmen]

Originally Posted by RudeCurve

I have no regrets with my two new FX8120 and FX4100 builds. They were relatively cheap too. Didn't see a need to go with Intel.

i have the fx8150 , i should have gone with sandy bridge . The bulldozer is fast sure , but its using a ton more power than whats really needed.


HOpefully amd gets its act together otherwise i'm going to hope over to intel

[Exophase]

Originally Posted by Frank

I just bought new innards for my main pc, with an AMD octo-core FX-8120. Ok, I know it's only roughly a 6-core and the upper Intel i5s and i7s are faster for applications that use ~2 cores, out of the box.

However, it is faster than any Intel less than 150% as expensive. And it suffers mostly from bad scheduling by the Windows task scheduler. Because it requires just about the opposite approach of an Intel. Let me explain.

If you run applications that use multiple cores, you'll see that the first, third, and (when available) fifth and seventh core are all pushed to the max, while the even cores are mostly idle. Because the Windows scheduler expects those cores to be virtual, hyperthreaded ones. And it makes more sense to use a "full" core than a "virtual" one, to balance the load.

Further, it tries to keep processes on that same core as much as possible, to prevent cache misses and rescheduling demands.

Then again, if you use an AMD CPU, the opposite makes more sense: try and schedule multiple threads of the same processes on the same core pair. That increases the overall speed and prevents stalling.

The octo-cores do have a full set of 8 integer pipelines, only the floating point and special units (which are faster than the Intel ones) are shared. That means, that if a thread is waiting on the result of another one, it will stall if it isn't running on the same core-pair while using the special units. Which you can easily see in the Windows task manager: while the Intel cores tend to have an average load that fluctuates mildly, the AMD load tends to consist of spikes.

Or, in other words: they stall all the time.

So, the problem isn't so much bad/slow AMD processors, as it is bad scheduling in Windows that greatly favors Intel CPU's.

And as soon as software can really make use of 8 cores or if you like virtualizing, those octo-cores will outperform the more than twice as expensive Intel ones.

That's not how things work...

The advantage you get from keeping inter-thread communication on two cores of the same module is small and I doubt there are a lot of applications with such tight communications requirements where you'd even start to measure such a benefit. Instead running two threads on the same module penalizes you because both cores share the same frontend (including L1 instruction cache, fetch, and decode) as well as L2 cache, not just the FPU. Several reviews demonstrated this property.

AMD did present some slides that suggested that running two threads on the same module instead of separate modules could improve performance, but not for the reasons you gave. The idea is that the single module uses less power if the other module is turned off. This raises the available TDP, which allows the remaining module to turbo to a higher clock speed. Unfortunately, the turbo headroom for Bulldozer isn't that high, so in practice this didn't really result in enough of an improvement to offset the sharing overhead, let alone overtake it. Hence why AMD's scheduling changes are doing the opposite of what you're saying.

One thing to keep in mind is that in situations where all cores are utilized, like those that benchmark the best for Bulldozer, the scheduling changes don't do anything. In reality, the impact from the scheduling changes are on average small and minor compared to the shortcomings of the uarch. Piledriver does some work to improve things, but I'm skeptical of the 15+% better IPC number given by THG, since so few tests were done. There really needs to be reviews, which I'm alarmed haven't surfaced given that you could buy OEM desktop Trinity systems for a while..

[sebbbi]

Originally Posted by Frank

Then again, if you use an AMD CPU, the opposite makes more sense: try and schedule multiple threads of the same processes on the same core pair. That increases the overall speed and prevents stalling.

It's easy to overestimate the advantages of sharing a data cache between two cores. First of all, data often gets flushed out of the caches very fast (less than a millisecond). So two cores must be using the same data (almost) exactly at the same time to gain the benefits. The first thing you get teached at school about multithreaded programming is: protect your data so that multiple threads do not access it simultaneously. This is of course only true for write & modify cases.

If one thread is modifing the data that the other reads, there's a lot of potential problems present. You have no control over the ordering (read might return old data), or data might be partially updated. So you need locks. Writing a multihreaded program that does lots of simultaneous updates & reads to same locked data objects is just really bad design. It kills the performance completely (lots of stalls). So this kind of data accesses are highly avoided by programmers. So this doesn't happen a lot in real software.

Atomic (read & modify) operations are good for some algorithms, and cost less than locks, but purposefully doing atomic operations to same cache lines from multiple threads is really asking for trouble. You will usually get huge penalties from this (coherency stalls), so any competent programmer is going to avoid this. This use scenario would actually be improved a lot by grouping two threads to same module, but as it practially never happens in real software, it doesn't matter much.

Cache sharing improves performance when both threads are only doing reads (no modify at all) to the exactly same data at almost the same time. The question here becomes: Why are two threads reading exactly the same data at the same time? If it is a random occurance of two objects referring a same object then it's fine, but in order for it to affect cache performance it must be a really common pattern. And a common pattern of multiple threads reading and processing the same data could likely be a sign of inefficient code (why you need to repeatedly read the data so many times?). Of course there are good cases where same data is read by multiple threads at same time, but it's not a really common case. Not likely something that affects cache performance a lot.

---

Intel's hyperthreading (and IBM's SMT) is better for hiding memory latency (cache misses) than AMDs module based architecture. With HT, when a thread hits a cache miss, the CPU immeditely starts executing instructions from the other thread instead. All the execution units are fully utilized by the other thread during the cache miss (cache miss can take up to 200 cycles). With AMDs architecture, a cache miss freezes the core until it gets the data to continue. There's nothing you can run on the core until the data is ready. Of course AMD has twice as many cores, but these cores are not as high performance as Intel's big fat cores. So if one of these two cores stalls for 200 cycles, only the other keeps running. On Intel's architecture the big fat core is crunching numbers all the time (unless of course both threads hit at stall at the same time). And it can crunch much more per cycle than a simpler smaller AMD core.

So basically AMDs cores are stalling more because of memory latencies. Intel's core can get instructions from two threads and thus memory latency can be often hidden. AMD has higher peak performance (in multithreaded loads), but it drops down more because of cache misses (and other stall cases). AMDs relatively weak caches make this situation even worse. Intel has excellent low latency caches with high associativity.

[almighty]

Bulldozer is 20-25% slower then Phenom 2 per clock and Phenom 2 is a good 40%+ slower then Sandy Bridge.

AMD bumping up IPC by 10-15% with each revision is not enough, it'll take them 2 revisions before they can truly offer a chip that offers better performance then Phenom 2 in every way.

Meanwhile Intel is stream rolling there chips out, Ivy Bridge is a good 8-10% faster per clock the Snady Bridge.

I think people need to wake up and see how far behind AMD really are.