• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Breaking down BD

But would you say any of that for Trinity? Compared to Llano at the same 32nm, Trinity looks great. They actually managed to improve single-threaded performance and maintained multi-threaded performance and actually improved drastically the perf-per-watt. They improved upon an already excellent on-die GPU and were able to dedicate more die space to it, decreased the core space and yet overall improved upon the cores' performance. AMD actually made a Bulldozer module that beat Husky K10.5 in single-threaded performance on the same node. And all of this on top of better power consumption figures than Intel on the same node. Personally, I think it's a fantastic product that more than fits its intended purpose and market today.

Frankly, their modular approach saved them a lot of die space to dedicate to the GPU and on a laptop the CPU performance doesn't really matter much considering any CPU related task is almost certainly I/O bottlenecked (or TDP limited). I thought about this and couldn't think of a single thing most people do on a laptop that would benefit from an Intel core over and AMD core given they're both using their on-die GPU. Not one. That's crazy. It's no wonder Intel has done a complete 180 with respect to the GPU the last 2 years. And think about this: how many people use their laptops for heavy content creation that requires a beefier CPU rather than a good enough one? Even if they do AMD has already covered a good portion of that angle with openCL support on the full adobe line, arcsoft, etc.

I wouldn't even consider an AMD server-based CPU for my next build. I don't care how good it could possibly be, I already know with 100% certainty that it will lose to an 1155 Intel. But let's forget the desktop for a second and consider a laptop...

Would you say the same thing for a Trinity or Kaveri? I know that most people here would prefer that their on-die GPU was better on their laptops for more fluid and better gaming than a 30% advantage in single-threaded performance. So for all the mistakes they've made in server and the desktop, AMD has been gaining market share steadily on the mobile end and has come out with 3 great products in a row -- Brazos, Llano and Trinity (Brazos 2.0 should be out anytime now as well) and one of these is a Bulldozer-CMT derivative. They gained close to 3% total laptop market share in a single year. That's not a 3% increase in sales but a 3% increase in overall laptop market share. So you can fault them all you want for their desktop blunders because they definitely deserve it there, they're very very good on mobile.
 
I dont get the big deal over a uop cache for branch prediction. I mean, I know it helps, but isnt it being blown out of proportion? Nehalem did not have this uop cache and it is a damn good uarch, something BD still struggles against.
 
At the end of the day, the truth is Bulldozer isn't particularly good at anything in it's current form. With low IPC, tons of branch mispredictions, and low clock speeds, combined with high power consumption it misses the mark for either the consumer desktop or server markets.

The difference is, the architecture has potential with changes for the server market. For the desktop market, not so much.

I think the article actually said the branch prediction was really good. Do you mean instead heavy branch misprediction penalties?
 
...But again, Intel made mistakes, acknowledged them and learned not to repeat them. They could stand to lose out during that generation because they had enough cash and still turned a profit despite having the inferior technology. AMD simply can't do that. ...

Larrabee? Itanium? All the other bits of what you said were spot on, but Intel is not immune from making a prolonged ass of itself at times. I mean, the money they must have spunked developing Larrabee, geez...
 
Larrabee? Itanium? All the other bits of what you said were spot on, but Intel is not immune from making a prolonged ass of itself at times. I mean, the money they must have spunked developing Larrabee, geez...

Itanium and Larabee were different mistakes. I never said Intel doesn't continue to make mistakes. They certainly do, but they tend not to make the same exact mistake repeatedly. Itanium was hugely disappointing, but they never hinged their business on it.. Larabee, Tejas and some other CPUs never really saw the light of day. They simply scrapped them before release. Sometimes you have to clear the board and start over. I don't see a problem with that other than it costs them a lot of money when that has to happen.

And those architectures weren't at the expense of their bread and butter markets.
 
Last edited:
Itanium and Larabee were different mistakes. I never said Intel doesn't continue to make mistakes. They certainly do, but they tend not to make the same exact mistake repeatedly. Itanium was hugely disappointing, but they never hinged their business on it.. Larabee, Tejas and some other CPUs never really saw the light of day. They simply scrapped them before release. Sometimes you have to clear the board and start over. I don't see a problem with that other than it costs them a lot of money when that has to happen.

And those architectures weren't at the expense of their bread and butter markets.

Noted. Nice reply.
 
And those architectures weren't at the expense of their bread and butter markets.

I don't know where you think it was intended to go, but I'm pretty sure Itanium was meant for their bread and butter market. I'm convinced that whoever mentions Itanium within Chipzilla's HQ is beheaded :p

Also, MIC, or Many Integrated Cores, aka Knight's Corner aka Larrabee 2.0 is due out next yearish? I'm sure it'll be better than Larrabee as it's not intended to be a GPU but rather for GPGPU HPC. We'll see if the x86 requirement bites it in the ass again, though.
 
I don't know where you think it was intended to go, but I'm pretty sure Itanium was meant for their bread and butter market. I'm convinced that whoever mentions Itanium within Chipzilla's HQ is beheaded :p

Also, MIC, or Many Integrated Cores, aka Knight's Corner aka Larrabee 2.0 is due out next yearish? I'm sure it'll be better than Larrabee as it's not intended to be a GPU but rather for GPGPU HPC. We'll see if the x86 requirement bites it in the ass again, though.

Not initially, it wasn't. Itanium was intended for specialized server and workstation use and it started out as a kind of test run. It never really took off because of lacking software support and compatibility that was crucial for Enterprise-class customers.

Had it taken a hold in that segment, we may very well be using true 64bit CPU's everywhere.
 
I'd consider Intel's foray into 64-bit processing a "bread and butter" thing :p I guess it depends on how important you think Itanium was.

The software support/compatibility is also what hurt Larrabee and might hurt them again with 2.0. As far as HPC goes, they don't care about x86 (for the most part) because so much is x87/FP-based.
 
Isn't AMD kinda sending mixed signals here? On the one hand they are pushing more, but weaker cores for heavily threaded tasks. At the same time however they are pushing their GPU APP acceleration for heavily threaded tasks. It seems like fewer strong cores would fit better if they want to unload the real workhorse tasks onto the GPU anyways.

It must come back to BD being a server arch at heart. Trinity does look pretty great though, I think that chip will do really well.
 
I don't know where you think it was intended to go, but I'm pretty sure Itanium was meant for their bread and butter market. I'm convinced that whoever mentions Itanium within Chipzilla's HQ is beheaded :p

Also, MIC, or Many Integrated Cores, aka Knight's Corner aka Larrabee 2.0 is due out next yearish? I'm sure it'll be better than Larrabee as it's not intended to be a GPU but rather for GPGPU HPC. We'll see if the x86 requirement bites it in the ass again, though.

I think it was hoped that it would be able to some day replace the x86 offerings entirely. The problem is that this industry and it's consumers always required backwards compatibility and never forced the market in the direction it wanted to go in, letting legacy software dictate the directions they could move in. I think this has always held us back technologically speaking.

But Intel didn't stop improving and developing their existing IA32 offerings. They continued down both paths. This proved to be a wise move as Itanium obviously never caught on.
 
Isn't AMD kinda sending mixed signals here? On the one hand they are pushing more, but weaker cores for heavily threaded tasks. At the same time however they are pushing their GPU APP acceleration for heavily threaded tasks. It seems like fewer strong cores would fit better if they want to unload the real workhorse tasks onto the GPU anyways.

It must come back to BD being a server arch at heart. Trinity does look pretty great though, I think that chip will do really well.

It makes sense because the CMT approach addressed integer heavy workloads whereas HSA addresses FP heavy. It's actually pretty well thought out if you neglect the current desktop area :p With the rise of HPC and the sales of GPUs for GPGPU and chips for HPC then it makes even more sense.

The desktop is the odd man out at the moment, though GPGPU is coming there too.
 
Worth a read no question on that.
Still we can hope that piledriver delivers a good performance and a decent price.
Of we carry on waiting...
 
It makes sense because the CMT approach addressed integer heavy workloads whereas HSA addresses FP heavy. It's actually pretty well thought out if you neglect the current desktop area :p With the rise of HPC and the sales of GPUs for GPGPU and chips for HPC then it makes even more sense.

The desktop is the odd man out at the moment, though GPGPU is coming there too.

Well that does make more sense, The desktop market is probably the most mature market with the least amount of growth potential, so I could see why that's the lowest priority.
 
I dont get the big deal over a uop cache for branch prediction. I mean, I know it helps, but isnt it being blown out of proportion? Nehalem did not have this uop cache and it is a damn good uarch, something BD still struggles against.

Nehalem had a shorter pipeline than Sandy Bridge.
it's not being blown out of proportion, because AMD needed either less BP misses, or faster clockspeed to get performance out of BD.
 
Nehalem had a shorter pipeline than Sandy Bridge.
it's not being blown out of proportion, because AMD needed either less BP misses, or faster clockspeed to get performance out of BD.

Ah, okies, didnt realize SB had a longer pipeline. That makes a bit more sense now.
So, intel reintroduced the trace cache because of the slightly longer pipeline.
Guess it would make sense for AMD to implement such cache ~ although, they never have before in any of their uarchs, is it a fairly trivial thing to implement?
 
Ah, okies, didnt realize SB had a longer pipeline. That makes a bit more sense now.
So, intel reintroduced the trace cache because of the slightly longer pipeline.
Guess it would make sense for AMD to implement such cache ~ although, they never have before in any of their uarchs, is it a fairly trivial thing to implement?

Nothing is trivial when it comes to micro-architecture changes :p

I believe the minimum penalty for SB is 2 stages longer than Nehalem without the uop cache. but 2-3 lower when it misses something that is cached. so it does help, it would be an improvement, not sure by how much =p.
 
Not initially, it wasn't. Itanium was intended for specialized server and workstation use and it started out as a kind of test run. It never really took off because of lacking software support and compatibility that was crucial for Enterprise-class customers.

Had it taken a hold in that segment, we may very well be using true 64bit CPU's everywhere.

In the 1990s, Merced was Intel's only plan for 64-bit. There was no alternative. The first Merced cores were scheduled for 1998, and included a hardware x86 translation engine intended to make the platform port less painful. The transition to IA-64 was supposed to start at the top and trickle down.

The Pentium Pro was introduced in late 1995, only a couple years before Merced was supposed to be released. At the time they added PAE as a bandaid -- the PPro was not to be long-lived as a server chip, hence the transition to mainstream with he Pentium II. They waited quite a long time to release the Pentium II Xeon (late 1998), which was probably only started after Merced hit major delays (my assumption because it's just a PII with faster SRAM chips). At this point they couldn't commit to another 64-bit platform (would piss off Microsoft AND their committed OEMs), so they left the Xeon castrated with PAE while they went ahead with Merced.

We didn't hear another official peep out of Intel regarding x86-64 until AMD forced their hand with Windows XP x64.

Intel has a long history of betting on the wrong horse at the expense of their bread and butter, and dropping any new ideas at the first signs of trouble. They did it with:

iAPX 432 (the 8086/8088 was a side project).

i960 (the team that created the Pentium Pro was formed from the ashes of this team)

Both of these processors were given top priority, as was Merced (until the initial release). It seems that Intel has succeeded despite themselves, but in the last decade they've finally realized that x86 is what they do best.
 
Last edited:
Defaultuser, I know all that. I worked for HP during those years configuring the few IA64 servers and workstations that actually got sold. They were a PITA to set up and configure prior to getting to the customer, and a nightmare to set up and use once by the customer once deployed.

A lot of customers essentially wasted a lot or money on the false premise that there was going to be an easy transition to the architecture available from Intel, HP, Microsoft, and a lot of other software developers, soon after their hardware purchase, but that never came to fruition.
 
Defaultuser, I know all that. I worked for HP during those years configuring the few IA64 servers and workstations that actually got sold. They were a PITA to set up and configure prior to getting to the customer, and a nightmare to set up and use once by the customer once deployed.

A lot of customers essentially wasted a lot or money on the false premise that there was going to be an easy transition to the architecture available from Intel, HP, Microsoft, and a lot of other software developers, soon after their hardware purchase, but that never came to fruition.

HA! I'm sitting next to 2 HP ZX 6000s :p
 
Why is intel still improving their IA-64 processors then, if its a dead end road?
 
Did you ever make any for EMC :p?

You know, I did a few of those when helping out the build team which was assigned to that account. So, maybe those were mine. Slim chance, but just maybe.

Why is intel still improving their IA-64 processors then, if its a dead end road?

Because, pass or fail, they have the money for i. And, as past computing platforms have proven, true 64bit can bring things like faster performance, better security, way more platform expandability in regards to things like more physical processors and scaling, and cheaper overall total cost of ownership (once the harware is supported by software on a widespread basis). Besides, if Intel keeps pushing forward and delivering working products based on true 64bit and they end up succeeding with transitional support to end-users, then they will practically own that niche in the market and it will start growing.
 
Why is intel still improving their IA-64 processors then, if its a dead end road?
Because, pass or fail, they have the money for i. And, as past computing platforms have proven, true 64bit can bring things like faster performance, better security, way more platform expandability in regards to things like more physical processors and scaling, and cheaper overall total cost of ownership (once the harware is supported by software on a widespread basis). Besides, if Intel keeps pushing forward and delivering working products based on true 64bit and they end up succeeding with transitional support to end-users, then they will practically own that niche in the market and it will start growing.

This is actually completely incorrect.

http://allthingsd.com/20120516/oracle-drops-new-documents-in-itanium-trial-and-theyre-juicy/

The juicy tidbits from the article:

That HP relied heavily on profits earned from multiyear sales and support contracts with customers who bought its Integrity servers that run Intel’s exotic and expensive Itanium chip. In support of that, it paid Intel nearly a half-billion dollars to keep the chip alive, despite the fact that, outside of HP, there was no other single vendor using Itanium chips.

beginning in August 2007, and go through to April 2011. In the first, (Ex. 6) Fink writes to another HP exec and says, “Intel dropped a bomb on us last night” during a meeting that included talk of “canceling Poulsen,” a future version of the Itanium chip that was on internal road maps.

Around 2007 Intel decided they wanted out, and HP paid half a billion dollars to keep the chip on life support. HP has not paid for any additional updates, so after Poulsen the microarchitcture is basically dead.

This, not coincidentally is the same timeframe where Intel announced to the world that they finally turned a profit on Itanium (and now we know why)!

http://bits.blogs.nytimes.com/2009/11/17/a-decade-later-intels-itanium-chip-makes-a-profit/
 
Last edited:
This is actually completely incorrect.

http://allthingsd.com/20120516/oracle-drops-new-documents-in-itanium-trial-and-theyre-juicy/

The juicy tidbits from the article:





Around 2007 Intel decided they wanted out, and HP paid half a billion dollars to keep the chip on life support. HP has not paid for any additional updates, so after Poulsen the microarchitcture is basically dead.

This, not coincidentally is the same timeframe where Intel announced to the world that they finally turned a profit on Itanium (and now we know why)!

http://bits.blogs.nytimes.com/2009/11/17/a-decade-later-intels-itanium-chip-makes-a-profit/

you're referring to the original Itanium from the past and the partnership between Intel and HP that surrounded it. My response was in regards to CURRENT ongoing development of the IA64 architecture by Intel.
 
you're referring to the original Itanium from the past and the partnership between Intel and HP that surrounded it. My response was in regards to CURRENT ongoing development of the IA64 architecture by Intel.

And the fact that you posted this response proves that you didn't read a word of what I posted, nor the detailed article I linked. Just because my previous post referred to Merced and the Intel/HP chip development partnership doesn't means my last post was about that subject.

My post deals with the LATEST, soon to be released revision of IA-64, POULSON.

http://www.realworldtech.com/page.cfm?ArticleID=RWT051811113343

THAT IS THE CURRENT ONGOING DEVELOPMENT OF THE IA64 ARCHITECTURE BY INTEL.

The point of my post is this: internal HP documents being collected during discovery for their suit with Oracle state quite clearly that Intel was losing money on IA-64 as far back as 2007, and they wanted to cancel POULSON or have HP pay for the development. HP paid. Intel is supposed to deliver the chip this year. Intel has not announced any architectures beyond Kittson, and they probably won't do any more for free.

AGAIN, THIS IS NOT ABOUT MERCED AND THE HP/INTEL PARTNERSHIP TO BUILD IT. It just so happens that HP is now the only remaining builder of Itanium systems, so it was up to them to pay to save POULSON. Intel and HP are right back together where they started :D
 
Yes, HP paid... which means, pass or fail, intel has the money to mess around with ongoing IA64 development. ;)
 
Yes, HP paid... which means, pass or fail, intel has the money to mess around with ongoing IA64 development. ;)

True.

But once the money dries up, I can tell you exactly where IA64 is going :D

trashcan.jpg
 
Agreed. Without some kind of breakthrough wich allows Intel to push IA64 performance even further, and being able to emulate X86 / EM64T without a significant impact to performance and most importantly, in a cost effective manner, IA64 will continue to die a slow death.
 
Back
Top