AMD to Disclose Details About Bulldozer Micro-Architecture in August

Quote:

---

Originally Posted by JF-AMD

No, you are completely wrong here.


PLEASE DELETE THAT CHART.

I have explained several times:

1. The chart was drawn in powerpoint, the chart was not done in excel where you would have exact numbers

---

Edit: you mean the projected numbers? The historical numbers on the chart look VERY accurate.
For example:
2435 2-socket Spec_rate base performance is Int: 160, Fp: 128.

Now look at that chart: I'll be damned if the "integer performance" bar isn't at 16, and the the "floating point performance" bar looks just like... wait for it... 12.8 ! Pretty good accuracy, even in power point!

The values are very close to 2-socket int and fp spec-rate base data for the all historical data points after 2006. Like +/- 5% close.

Yet you claim I am "completely wrong here." Well, let's just say that 2-socket spec2006-rate divided by 10 is an EXCELLENT proxy for the historical performance data shown on that slide.

Besides, what else would make sense for "integer" and "floating point" throughput, that you would have handy for all those processors, other than spec rate benches?

Quote:

---

2. The chart uses a fade to purposely hide the actual performance estimates because we were not making actual estimates at the time.

---

The fade provides a range. Are you saying even the range is deliberately inaccurate? That is AMD's official position? That despite the slide saying, "Interlagos data based on AMD projections" it was NOT a good-faith estimate at the time? Given that it hasn't been officially corrected or withdrawn (that I know of), that seems unlikely.

Quote:

---

Anyone that obsesses about that chart would also notice that the Magny Cours performance increase over Istanbul was also underestimated.

---

Indeed, I pointed that out, that the chart showed MC performance under where it ended up. Which fits with your oft-repeated claim to have underpromised/overdelivered on MC.

Quote:

---

If you want to refer to any performance estimate for bulldozer, there is one official one: 50% greater total throughput than Magny Cours.

---

Let me make sure I completely understand this:

You are saying that AMD's official position is now that the slide shown at Analyst Day 2009 projecting Interlagos performance has been *withdrawn* as a claim, and that the only claim AMD is officially now making is "50% greater total throughput than Magny Cours".

When did AMD officially withdraw the A Day 2009 performance projections?

What does "50% greater total throughput" mean?

Is that Integer? FP?

An average of those two? Both of them, independently?

Quote:

---

We won't be saying anything else for the forseeable future.

Any other guess, no matter how complicated the math or methodology, will be wrong.

---

Well, this may be stating the obvious, but a correct guess would not be wrong.

And since you won't be saying anything else for the foreseeable future, you'll have to excuse us for speculating based on official AMD presentation materials. Unless you are saying AMD has OFFICIALLY withdrawn Bergman's slide? Is that what you are saying?

They still host that presentation slide on the amd website, you know...


--------------

Until AMD provides new official performance projections, or actual benchmarks, or something more than "total throughput 50% more than MC" (or defines that term), I'll stick with what I think that chart showed:

Interlagos top-bin 2-socket spec2006int_rate(base): 360-390 (projection)
Interlagos top-bin 2-socket spec2006fp_rate(base): 400-430 (projection)

Now, that just happens to be about 50% greater *FP* throughput than MC (int 309, fp 290) at the top end, so evidently that part isn't completely wrong!
It's the integer part that the chart suggests is at most 25% greater throughput than MC. I don't know what to say, are you saying that the chart is wrong *here*? That the integer throughput is also 50% greater, contra the chart?

What about you posting that you told Johan that specInt_rate was 60-80% higher? Was that a mistake, too? Are you withdrawing that? It applied to something else? Or sticking by it?

FYI, 50% higher int throughput would be: 463 (!) 60-80% higher int throughput would be 494-556 (!!). Those would be rather better than the chart showed, the last being almost unbelievably high at the top (80% improvement) end.

We are not withdrawing anything. That slide was an estimate and it was purposely drawn not to scale. It was directional. Trust me, everything goes past the lawyers, they are not going to be comfortable with an exact measurement being displayed if we do not have the parts to test.

Nobody would ever give a numerically accurate chart almost two years before the product hits the market.

The voiceover from the analyst meeting was about the comparison of Magny Cours to Istanbul. The Interlagos bars were added to show that there would be another large increase of performance in the same socket. That is specifically why they are fading; we were committing to AN increase, not a percentage.

At the time it was clear to everyone in the room that this was directional and designed to indicate an increase in performance and not exact. Sorry that everyone has spent so much time deconstructing that chart, it was never meant to be viewed from that perspective.

I have covered this slide on several occasions, each time telling people this was directional and not exact.

Quote:

---

Originally Posted by JF-AMD

We are not withdrawing anything. That slide was an estimate and it was purposely drawn not to scale. It was directional. Trust me, everything goes past the lawyers, they are not going to be comfortable with an exact measurement being displayed if we do not have the parts to test.

Nobody would ever give a numerically accurate chart almost two years before the product hits the market.

The voiceover from the analyst meeting was about the comparison of Magny Cours to Istanbul. The Interlagos bars were added to show that there would be another large increase of performance in the same socket. That is specifically why they are fading; we were committing to AN increase, not a percentage.

At the time it was clear to everyone in the room that this was directional and designed to indicate an increase in performance and not exact. Sorry that everyone has spent so much time deconstructing that chart, it was never meant to be viewed from that perspective.

I have covered this slide on several occasions, each time telling people this was directional and not exact.

---

I don't think he is really listening.

Quote:

---

Originally Posted by JF-AMD

We are not withdrawing anything. That slide was an estimate and it was purposely drawn not to scale. It was directional. Trust me, everything goes past the lawyers, they are not going to be comfortable with an exact measurement being displayed if we do not have the parts to test.

Nobody would ever give a numerically accurate chart almost two years before the product hits the market.

The voiceover from the analyst meeting was about the comparison of Magny Cours to Istanbul. The Interlagos bars were added to show that there would be another large increase of performance in the same socket. That is specifically why they are fading; we were committing to AN increase, not a percentage.

At the time it was clear to everyone in the room that this was directional and designed to indicate an increase in performance and not exact. Sorry that everyone has spent so much time deconstructing that chart, it was never meant to be viewed from that perspective.

I have covered this slide on several occasions, each time telling people this was directional and not exact.

---

I think you missed these:

What does "50% greater total throughput" mean? Int? FP? Both? Average? You say this is now the only official projection, I would just like to understand what it means.

Are you saying that the 60-80% greater specInt_rate was MC to Istanbul, rather than Interlagos to MC? (I didn't say anything about a voiceover...) I guess it must be, if you were not committing to any Interlagos percentages at that time. Shouldn't you let Johan @ Anandtech know to correct his article?

--------------------

EDIT:

Oh, I think I finally get it. The fading was intended to indicate not a range, but rather "unknown at this time" (other than "more than MC").

But could you please clarify the 2 things in the top section?

Quote:

---

Originally Posted by Sn0wm@n

your point is???

---

This is my point.

http://www.anandtech.com/show/846/7

5 years of development don't guarantee :banana::banana::banana::banana:.

Quote:

---

Originally Posted by gosh

Hexacores at 2 GHz ?
New games that need performance will take advantage of parallel execution.

---

Of course, but more cores will never be more important than more speed per core. A chip with 50% more cores will never perform as good as a chip with 50% more speed per core in games.

And that is why it's so important to have better performance per core in bulldozer.

Quote:

---

Originally Posted by JF-AMD

If you want to refer to any performance estimate for bulldozer, there is one official one: 50% greater total throughput than Magny Cours.

We won't be saying anything else for the forseeable future.

---

12% per core is really weak. That won't even compete with i7s from 2008. That isn't even as big as the difference between Phenom and Phenom II, or between Athlon 64 and Phenom. Or even Xp to Athlon 64. I don't think I've seen such a weak boost in a new architecture from AMD ever.

I really hope that there are bigger performance gains than that.

Quote:

---

Originally Posted by -Boris-

12% per core is really weak. That won't even compete with i7s from 2008. That isn't even as big as the difference between Phenom and Phenom II, or between Athlon 64 and Phenom. Or even Xp to Athlon 64. I don't think I've seen such a weak boost in a new architecture from AMD ever.

I really hope that there are bigger performance gains than that.

---

The engineer said, when the second integer core is actived, it will gain 80% performance increased. I write a simple formula below:

(100%+50%)*6*x = (100%+80%)*4*y

x stands for one core performance of K10
y stands for one integer core performance of bulldozer

The result is : 1.25x=y. So bulldozer will stronger than K10 about 25% in single core performance.

If I was wrong please correct me.:D

Quote:

---

Originally Posted by -Boris-

This is my point.

http://www.anandtech.com/show/846/7

5 years of development don't guarantee :banana::banana::banana::banana:.



Of course, but more cores will never be more important than more speed per core. A chip with 50% more cores will never perform as good as a chip with 50% more speed per core in games.

And that is why it's so important to have better performance per core in bulldozer.



12% per core is really weak. That won't even compete with i7s from 2008. That isn't even as big as the difference between Phenom and Phenom II, or between Athlon 64 and Phenom. Or even Xp to Athlon 64. I don't think I've seen such a weak boost in a new architecture from AMD ever.

I really hope that there are bigger performance gains than that.

---

while BD has 50% more cores (16 cores / 8 modules); 2 cores share some execution units and performance / core will drop once all cores are fully utilized (80% gain with a module / 2 cores compared to 100% with 2 completely seperated cores); i expect at least a 20% improvement with BD in single-threaded apps ;)

I still see many posters assuming that BD cores are somehow comparable to MC cores and just need some adjustment factors. But this might lead to high error margins. But a lot might change. Just have a look at a presentation held by Chuck Moore in 2003:
http://www.ece.rochester.edu/~albone...ides/moore.pdf

Besides the description of the TRIPS architecture, it contains some key arguments for designing a future CPU (including the last slide).

Also readers of my blog should already know, what topics people related to Bulldozer are involved in.

I think due to the changes in the architecture there is some significant headroom on the compiler side, more than for an evolved architecture. This might become a P4 like situation.

Quote:

---

Originally Posted by superrugal

The engineer said, when the second integer core is actived, it will gain 80% performance increased. I write a simple formula below:

(100%+50%)*6*x = (100%+80%)*4*y

x stands for one core performance of K10
y stands for one integer core performance of bulldozer

The result is : 1.25x=y. So bulldozer will stronger than K10 about 25% in single core performance.

If I was wrong please correct me.:D

---

You didn't factor any frequency gain. AMD is constantly comparing BD on energy efficiency and throughoutput with MC, doesn't say a word on IPC improvements.

A MC cpu has 12 integer cores and 12 floating point units; a BD cpu will have 16 integer cores ( a bit simpler than MC ) and 8 floating point units ( 2x de throughoutput of MC units when AVX is used - thus more complex FP)

If BD clocks 25% faster ( 2.7Ghz which isn't out of reach if 32nm works ) than you end up with no IPC improvement.

Quote:

---

Originally Posted by superrugal

The engineer said, when the second integer core is actived, it will gain 80% performance increased. I write a simple formula below:

(100%+50%)*6*x = (100%+80%)*4*y

x stands for one core performance of K10
y stands for one integer core performance of bulldozer

The result is : 1.25x=y. So bulldozer will stronger than K10 about 25% in single core performance.

If I was wrong please correct me.:D

---

I was just calculating on the numbers JF-AMD gave me. And stating that I hope for much greater performance increases.

Quote:

---

Originally Posted by generics_user

while BD has 50% more cores (16 cores / 8 modules); 2 cores share some execution units and performance / core will drop once all cores are fully utilized (80% gain with a module / 2 cores compared to 100% with 2 completely seperated cores); i expect at least a 20% improvement with BD in single-threaded apps ;)

---

What you are saying is that Bulldozer will loose relative performance in multithreaded applications. That's the opposite of what AMDs claims.

If AMD talks about multithreaded performance all the time, it's reasonable to believe that it's in this field that BD will be making the greatest improvements: And if JF-AMD is correct when he says 50% higher total throughput with 33% more cores, that means 12.5% higher performance than MC per core in the area that Bulldozer was supposed to shine.
My question is, if that is the case, how is the performance in the scenarios AMD don't talk about?

Quote:

---

Originally Posted by savantu

You didn't factor any frequency gain. AMD is constantly comparing BD on energy efficiency and throughoutput with MC, doesn't say a word on IPC improvements.

A MC cpu has 12 integer cores and 12 floating point units; a BD cpu will have 16 integer cores ( a bit simpler than MC ) and 8 floating point units ( 2x de throughoutput of MC units when AVX is used - thus more complex FP)

If BD clocks 25% faster ( 2.7Ghz which isn't out of reach if 32nm works ) than you end up with no IPC improvement.

---

Well......you forget the memory increased.
Bulldozer will support DDR3-1866, K10 only support DDR3-1333, so if you use DDR3-1333, and lower frequency model, the Bulldozer will be worse than K10 in single thread. Right???:(

Quote:

---

Originally Posted by superrugal

Well......you forget the memory increased.
Bulldozer will support DDR3-1866, K10 only support DDR3-1333, so if you use DDR3-1333, and lower frequency model, the Bulldozer will be worse than K10 in single thread. Right???:(

---

Yes, and if you use loose timings then the IPC will be lower again. And with hand-picked benchmarks, BD can go very low in terms of IPC and overall performance.

Looks very bad for AMD!

Oh wait.. :p:

Quote:

---

Originally Posted by superrugal

Well......you forget the memory increased.
Bulldozer will support DDR3-1866, K10 only support DDR3-1333, so if you use DDR3-1333, and lower frequency model, the Bulldozer will be worse than K10 in single thread. Right???:(

---

Aren't you mixing up server with desktop now? Even if Interlagos support DDR3 1866 ECC, I haven't seen any proof that it's was used for that [50 %] comparison. If ECC 1866 exists at all.

This is the kind of meaningless speculation I'm talking about, people make assumptions that suits their opinion. Wait until we see at least a couple of benchmarks.

Right now we have just as much information as when Randy Allen said Barcelona would be 40 % faster than Cloverton, and we all know how that ended.

Quote:

---

Originally Posted by -Boris-

If AMD talks about multithreaded performance all the time, it's reasonable to believe that it's in this field that BD will be making the greatest improvements: And if JF-AMD is correct when he says 50% higher total throughput with 33% more cores, that means 12.5% higher performance than MC per core in the area that Bulldozer was supposed to shine.
My question is, if that is the case, how is the performance in the scenarios AMD don't talk about?

---

AMD didn't talk about Zambezi, but about Interlagos. Interlagos is a server MPU and the targeted audience wanted to hear about server stuff. Some of them would even buy Atom based supercomputers (like the Transmeta Crusoe based one in the past). They're not that much interested in single core or desktop app performance.

It's a situation like with Thuban. No data.

Instead we can look, what ideas the people involved in developing BD or BC could have brought in, like adaptivity or high frequency (see Moore's 8 FO4 design - K10 is ~23 FO4). There is a thermal budget and CPU design's don't have to be static (and designed for the worst case).

Let's imagine a 16C Interlagos with ~100W TDP. This could mean ~2x15W for uncore, leaving ~70W for 16 cores or about 4W per core (8W per module). An 8C Zambezi with 100W would have 1x15W uncore and nearly 11W per core (21W per module). This could be used for frequency increases compared to Interlagos.

Quote:

---

Originally Posted by JF-AMD

We are not withdrawing anything. That slide was an estimate and it was purposely drawn not to scale. It was directional. Trust me, everything goes past the lawyers, they are not going to be comfortable with an exact measurement being displayed if we do not have the parts to test.

Nobody would ever give a numerically accurate chart almost two years before the product hits the market.

The voiceover from the analyst meeting was about the comparison of Magny Cours to Istanbul. The Interlagos bars were added to show that there would be another large increase of performance in the same socket. That is specifically why they are fading; we were committing to AN increase, not a percentage.

At the time it was clear to everyone in the room that this was directional and designed to indicate an increase in performance and not exact. Sorry that everyone has spent so much time deconstructing that chart, it was never meant to be viewed from that perspective.

I have covered this slide on several occasions, each time telling people this was directional and not exact.

---

I agree, it's to early to speak about charts and numbers. But i seriously hope, we're not going to wait 2 years ...

I don't want be grandfather before AMD get back the race.

We need more FX ships, and i hope AMD will deliver us a super high end dual opteron for us.

BD cores are wider ( 4 issues ), and we can be sure AMD improved IPC with newer prediction systems. And We all know the performance depands on frequency.

So Even if we know the ipc improvement, we can't know the performance of the ship without knowing frequency, that we can't know now.

So we waited 5 years, we can wait 6 months :up:

Dresden: off question, do u think, was to Thuban using low-K process?

logical is clear, high-end Bulldozer will better than top Thubans...And we will see now, how Thuban great are. And SB? To time i seen 2 comparsion-Intel promotion :down: and coolaler practice job. In mostly wiil not SB to much better than Nehalems. So...?

Quote:

---

Originally Posted by Dresdenboy

AMD didn't talk about Zambezi, but about Interlagos. Interlagos is a server MPU and the targeted audience wanted to hear about server stuff. Some of them would even buy Atom based supercomputers (like the Transmeta Crusoe based one in the past). They're not that much interested in single core or desktop app performance.

It's a situation like with Thuban. No data.

Instead we can look, what ideas the people involved in developing BD or BC could have brought in, like adaptivity or high frequency (see Moore's 8 FO4 design - K10 is ~23 FO4). There is a thermal budget and CPU design's don't have to be static (and designed for the worst case).

Let's imagine a 16C Interlagos with ~100W TDP. This could mean ~2x15W for uncore, leaving ~70W for 16 cores or about 4W per core (8W per module). An 8C Zambezi with 100W would have 1x15W uncore and nearly 11W per core (21W per module). This could be used for frequency increases compared to Interlagos.

---

Of course, but they compare to Magny Cours, which is to Thuban what an Interlagos is to Zambezi. I don't see any reason why the frequency and performance difference between Interlagos and Zambezi would be any different than that of Magny Cours and Thuban.

So if the 12.5% per core increase between Magny Cours and Interlagos is correct, It's reasonable to believe that the difference between Thuban and Zambezi will be something similar.


There is much news in Bulldozer, and it will be interesting to see how new the chip actually is. I hope it's brand new, but I don't trust AMD completely when they say so. Turion was supposed to be designed from the ground up for laptops according to their marketing people. :rolleyes:
But even if it's completely new with a hundred new three letter acronyms, it won't matter if we see such bleak performance advantage to Phenom II.
With a bit of luck even Liano will be in the same league as quadcore Zambezi.

Quote:

---

Originally Posted by madcho

I agree, it's to early to speak about charts and numbers. But i seriously hope, we're not going to wait 2 years ...
...
So we waited 5 years, we can wait 6 months :up:

---

He was talking about an old slide, not about today.

I dunno when they'll show up, but 6 months is optimistic, maybe 10-12 months. On the other hand, an AMD representative said in a BS-news interview that their 32 nm process is only 3 months behind Intel, although I find that hard to believe.

6 months for some customers think. real launch im expect at 1H 2011 (April-Juni 2011)

Quote:

---

Originally Posted by Mats

On the other hand, an AMD representative said in a BS-news interview that their 32 nm process is only 3 months behind Intel, although I find that hard to believe.

---

So AMD is shipping and selling 32nm chips since april? :shocked:

Quote:

---

Originally Posted by Mats

He was talking about an old slide, not about today.

I dunno when they'll show up, but 6 months is optimistic, maybe 10-12 months. On the other hand, an AMD representative said in a BS-news interview that their 32 nm process is only 3 months behind Intel, although I find that hard to believe.

---

;) Intel has been shipping millions of 32nm products since January. Add 3 months and you're in April. Maybe the representative said that on April 1 ?

Quote:

---

Originally Posted by savantu

You didn't factor any frequency gain. AMD is constantly comparing BD on energy efficiency and throughoutput with MC, doesn't say a word on IPC improvements.

A MC cpu has 12 integer cores and 12 floating point units; a BD cpu will have 16 integer cores ( a bit simpler than MC ) and 8 floating point units ( 2x de throughoutput of MC units when AVX is used - thus more complex FP)

If BD clocks 25% faster ( 2.7Ghz which isn't out of reach if 32nm works ) than you end up with no IPC improvement.

---

and theres a huge chance the clocks are higher, as magny cours runs at 1.9-2.3ghz

Well just because they CAN make 32 nm CPU's, it doesn't mean that they WILL do it right away..:p:

But then again I see no reason for waiting. :rofl:

Now that I had a look at it, it's over a year old.
http://www.brightsideofnews.com/news...-revealed.aspx

Quote:

---

AMD was late with 65nm and introduced 45nm with a nine month delay. With 32nm we are reducing this on just a single quarter or three months.

---

Quote:

---

Originally Posted by Klarko

Agreed, I hope Bulldozer is the same. One thing we can all agree on: the more competition the better it is for the consumer.

---

Hmm I'd rethink that statement. Smart people can all agree on: the more competition the better it is for the consumer. Some of the people posting in this thread want AMD out of business so that no one dares to compete with their precious Intel. I don't understand that logic, but here it is right in front of us.

Quote:

---

Originally Posted by Mats

Well just because they CAN make 32 nm CPU's, it doesn't mean that they WILL do it right away..:p:

But then again I see no reason for waiting. :rofl:

Now that I had a look at it, it's over a year old.
http://www.brightsideofnews.com/news...-revealed.aspx

---

AMD did good with the transition from 0.25µ to 0.18µ, but since then they have lagged behind. And since 0.13µ have they been saying that with the next transition they should be gaining on Intel. They haven't, so far.

Quote:

---

Originally Posted by Stukov

I don't think he is really listening.

---

Indeed. Its also equaly clear what his/her intent is as there's too much interest in bulldozer, and they can't lose the mindshare battle and performance battle. Imagine if that were to happen, it would be devistating! :D

Quote:

---

Originally Posted by -Sweeper_

and theres a huge chance the clocks are higher, as magny cours runs at 1.9-2.3ghz

---

It could be more complicated than that: Which clock will be higher? Integer Core clock? FPU clock? Front end clock? We don't know enough to include clock frequency into considerations. Same with IPC, since performance analysis based on it depends on clock frequency.

We even don't know the scaling behaviour and which power redistribution strategies a feature called APM Boost might use to get the most performance out of an app.

Quote:

---

Originally Posted by -Boris-

AMD did good with the transition from 0.25µ to 0.18µ, but since then they have lagged behind. And since 0.13µ have they been saying that with the next transition they should be gaining on Intel. They haven't, so far.

---

If AMD had the same resources (ie MONEY) as Intel, then they'd be giving Intel a run for it's money.

Anyhow, on topic. We will just have to wait for BD benchmarks. Personally I'm taking a conservative approach and believe BD will be roughly 20% faster clock for clock than a comparable Phenom II core. :up:

Quote:

---

Originally Posted by Mats

He was talking about an old slide, not about today.

I dunno when they'll show up, but 6 months is optimistic, maybe 10-12 months. On the other hand, an AMD representative said in a BS-news interview that their 32 nm process is only 3 months behind Intel, although I find that hard to believe.

---

Could very well be true, they just might not be talking about 1 or 2 percent of total volume like intel likes to do. And with the trouble intel seems to be having with they're attempt, it doesn't look like a very mature process.
AMD has always been quicker to a mature process and crossover point, so by the time intel gets their issues and volume sorted out, AMD won't be very far behind at all.
We've all heard the superior process propoganda from the blue camp, ad nauseum. 45nm without HKMG being impossible, is one that springs to mind. Yet here we are with AMD's advanced SOI process with ultra lowK dielectrics, proving that most of intels talking points are dust in the wind. :)

Quote:

---

Originally Posted by Dresdenboy

It could be more complicated than that: Which clock will be higher? Integer Core clock? FPU clock? Front end clock? We don't know enough to include clock frequency into considerations. Same with IPC, since performance analysis based on it depends on clock frequency.

---

Where did you find they will be different ? It's one thing to have different clock domains for the core and uncore parts, it is an order of magnitude more complicated to have inside the core, especially between front end and back end. While running the ALUs at double the core frequency was done in the past ( Netburst ), I remember this was dropped because the added complexity wasn't worth it. It would be nice if AMD would try its hand at this, the simpler integer cores from BD might be suitable for such an endeavor. regarding the FPU units; with the introduction of AVX and 256 bit datapaths, I really doubt anyone is thinking of mixing with frequency.

I would imagine its clock distribution wouldn't be extremely agressive, they are introducing too many innovations already, why raise the risk ?

The disaster with SUN Rock comes to mind, also 16 cores, 45nm, scout threads, it ended up using 250+ watts and had one spectacular merit : it was a complete dog.:p:

Quote:

---

We even don't know the scaling behaviour and which power redistribution strategies a feature called APM Boost might use to get the most performance out of an app.

---

What else can be different than what Intel does today ? Constantly check power usage and temperature and if you are within limits, up the frequency. This is the simplest ( from a theoretical POV, not implementation :) ) and most effective way.

Quote:

---

Originally Posted by flippin_waffles

Could very well be true, they just might not be talking about 1 or 2 percent of total volume like intel likes to do. And with the trouble intel seems to be having with they're attempt, it doesn't look like a very mature process.
AMD has always been quicker to a mature process and crossover point, so by the time intel gets their issues and volume sorted out, AMD won't be very far behind at all.

---

What trouble ? Please share with us your information. From everything that I've seen, Intel's 32nm is flawless with state of the art performance. Btw, from where do you get your 1 or 2% of total volume ? 32nm is far higher than that right now.

Quote:

---

We've all heard the superior process propoganda from the blue camp, ad nauseum. 45nm without HKMG being impossible, is one that springs to mind. Yet here we are with AMD's advanced SOI process with ultra lowK dielectrics, proving that most of intels talking points are dust in the wind. :)

---

Probably that why the Fishkill alliance is sweating continously to get hkmg into production; I know..they've swallowed the "propoganda".

Quote:

---

Originally Posted by freeloader

If AMD had the same resources (ie MONEY) as Intel, then they'd be giving Intel a run for it's money.

Anyhow, on topic. We will just have to wait for BD benchmarks. Personally I'm taking a conservative approach and believe BD will be roughly 20% faster clock for clock than a comparable Phenom II core. :up:

---

Yes I know, process transitions is all about money. It's expensive, but saves money in the end. The larger the production the more money saved. So it's easier for Intel to put more money in it to get it done earlier.

And I am hoping that Bulldozer will help AMD to dominate the performance market the next five years or so. But I doubt it more and more. Since Yonah, everything Intel have done is great, while AMD struggles.

Quote:

---

Originally Posted by terrace215

I think you missed these:

What does "50% greater total throughput" mean? Int? FP? Both? Average? You say this is now the only official projection, I would just like to understand what it means.

Are you saying that the 60-80% greater specInt_rate was MC to Istanbul, rather than Interlagos to MC? (I didn't say anything about a voiceover...) I guess it must be, if you were not committing to any Interlagos percentages at that time. Shouldn't you let Johan @ Anandtech know to correct his article?

--------------------

Ok, so you are claiming that despite the numerical scale, the part of the chart that contains future projections (MC and Interlagos) was only directional? And that this was obvious to everyone in the room.

And yet, the MC data on the chart was nearly bang-on with what was promised, even if you overdelivered a bit. And yet the chart has a disclaimer, specifically talking about the MC & interlagos data points, calling them projections. Wouldn't that say "directional only", instead? Wouldn't the scale stop at the 2435 level instead of continuing up linearly through the range of everything else? Color me skeptical, but ok.

But could you please clarify the 2 things in the top section?

---

He has no obligation to clarify. Stop asking. If that is all he is going to say you have no right to ask for more.

Also, is it that hard of an intellectual leap that data for real parts would be drawn somewhat accurately, while 'data' (read: projections) for in production parts be left as directional?

Quote:

---

Originally Posted by savantu

Where did you find they will be different ? It's one thing to have different clock domains for the core and uncore parts, it is an order of magnitude more complicated to have inside the core, especially between front end and back end. While running the ALUs at double the core frequency was done in the past ( Netburst ), I remember this was dropped because the added complexity wasn't worth it. It would be nice if AMD would try its hand at this, the simpler integer cores from BD might be suitable for such an endeavor. regarding the FPU units; with the introduction of AVX and 256 bit datapaths, I really doubt anyone is thinking of mixing with frequency.

I would imagine its clock distribution wouldn't be extremely agressive, they are introducing too many innovations already, why raise the risk ?

The disaster with SUN Rock comes to mind, also 16 cores, 45nm, scout threads, it ended up using 250+ watts and had one spectacular merit : it was a complete dog.:p:

---

There is a presentation by Chuck Moore, where he wrote up about the same statements he's presented later, while already at AMD:
http://www.ece.rochester.edu/~albone...ides/moore.pdf

One of the possible ways to evade to is to go to a cycletime, where instruction throughput (per unit time) peaks. Most of today's IPC is achieved by increasing complexity, thus increasing die area (and ever increasing static leakage) and limiting cycletime (or even decreasing without new processes), which means nearly stagnating clock frequencies. What if design gets simplified (lowering IPC), but allows for 20% or more area savings and increasing clock frequency (without having to increase voltage, since less complex circuitry does the job faster). Well, this is just one idea.

Having different clock domains in a module would allow to choose closer to optimal cycle times for different units, also driven by the type of work to do. E.g. decoding could have a longer pipeline if some trace caches and good branch prediction is present. A shared FPU would also be a candidate for a longer pipeline while integer cores could benefit from a short schedule execute loop and be clocked lower, but be 4-wide. There are so many possible techniques...

I didn't see any clear signs for such stuff except for some flexible clock generator modules or a FPU running at a different clock (and adapting it to the workload) than the integer execution units and maybe some others..

Quote:

---

Originally Posted by savantu

What else can be different than what Intel does today ? Constantly check power usage and temperature and if you are within limits, up the frequency. This is the simplest ( from a theoretical POV, not implementation :) ) and most effective way.

---

What can be different are the granularity and the units themselves.

Granularity: power down/up, clock differently the different subunits, as power budget permits and queue fill level requires

Units: scale them to what fits best and optimize power usage this way.. e.g. switch off some L2 cache ways or execution units
or activate them as needed (by tracking the upcoming instructions and powering up/clocking the appropriate subunits).

Quote:

---

Originally Posted by cegras

He has no obligation to clarify. Stop asking. If that is all he is going to say you have no right to ask for more.

Also, is it that hard of an intellectual leap that data for real parts would be drawn somewhat accurately, while 'data' (read: projections) for in production parts be left as directional?

---

2nd first: I finally see what he was trying to say regarding the fading.

---

Why should I stop asking? He's said, "the only performance projection we are making at this time is [X]." The trouble is, it is unclear to me (do YOU understand?) what the heck X means. If they are really making some projection at this time, why WOULDN'T he clarify what it means?

In addition, he posted here, back in November:
http://www.amdzone.com/phpbb3/viewto...?f=52&p=172169

Quote:

---

JF-AMD wrote:

Quote:

---

AussieFX wrote:
Exactly.
What I want to know is how does Anand know Interlagos is 60-80% faster than MC? He has NO fscking idea.

---

He knows that because I told him that.

Magny Cours = 50-60% faster than Istanbul

Interlagos = 60-80% faster than Magny Cours


Both of these are conservative estimates which I personally believe are too low, but I don't get to make the call on that.

---

JF posted that on Nov 25, 2009, regarding Johan saying Interlagos integer throughput was 60-80% higher than MC. Said it was conservative! That puts Interlagos SpecInt_rate(base) at... 556!

Given that this is MUCH DIFFERENT than "we have only ever said 50% greater 'total throughput'", and "we were not making specific projections then because we had no idea", I'd like to know if this was a mistake, true, or what.

He personally believes. Did you ever read his signature? His posts are personal opinions.

dont ofenzive at people please, but normal discussion to thema...

Quote:

---

Originally Posted by terrace215

Why should I stop asking?

---

Because he asked you to stop asking about slides which have fading bars, and quotes which were made around 2 years before the CPU release date. Those slides were NOT exact, and those quotes can certainly change given that a lot can change in 6 months time. Dont you agree?

A 16 "Core" (16Int, 8FP) Bulldozer will be 50% faster than a 12Core Magny Cours. Maybe the 60-80% changed into 50% because Magny Cours overdelivered? Maybe its being more conservative, or some reason entirely different. But thats the latest quote, maybe you should break that down and discuss instead of diving into old quotes and graphs with faded bars?

Quote:

---

Originally Posted by cegras

He personally believes. Did you ever read his signature? His posts are personal opinions.

---

Oh, BS. When he posts performance claims about Bulldozer in a forum, it's obviously not some "personal belief" completely detached from his inside information, regardless of any disclaimer. If it were, it would be akin to "making things up", and what use would that be?

At this point I'm trying to resolve 2 things from his own posting history:

(1) What does "total throughput" mean? If the only performance claim AMD is making at this time is "Interlagos has 50% greater total throughput than MC", wouldn't you like to know what that even means?

(2) He's said the fading performance projections slide (*apparently* showing 50% greater fp throughput, 26% grater int throughput) for Interlagos was merely meant to say, "we are not making any actual projection at this time, other than it will be greater than MC". Ok, fine, let's accept that. In addition he says that in fact, they would not even be able to project accurately at that time, as it was too early. Ok, accept that too. And yet... at the very same time, he posts that he told Anandtech that Interlagos would have 60-80% higher throughput (specifically specInt_rate) than MC, and that this was conservative!

See the contradiction here? He says, "X" to one person 6 months ago, tells another they couldn't possibly predict "Y" back then, and didn't mean to suggest "Y" at all, and says the only claim they are making is "Z", which isn't even very well defined! And "X" "Y" and "Z" contradict one another.

It's all over the place. And sometimes, when you ask about these issues, the answer is, "Oh *I* never disclose -blah-, only AMD can officially do that", even though he HAS been posting precisely about -blah- all over the forums.

Crazy.

If he simply said, "We never intended Y" (he has done this), "X was a mistake/is withdrawn/is no longer accurate" (he has not done this), and "Z means ...." (he has not done this), then everything would be quite clear.

Note that I am not asking him to disclose more than he/AMD already have. I'm asking him to resolve the inconsistencies between the various things he's said, and in one case (Z), define a term that he used.

Quote:

---

Originally Posted by LightSpeed

Maybe the 60-80% changed into 50% because Magny Cours overdelivered? Maybe its being more conservative, or some reason entirely different. But thats the latest quote, maybe you should break that down and discuss instead of diving into old quotes and graphs with faded bars?

---

Lucky for you, these are precisely the 2 things I am asking him about now!

I think JF is just being cautious here while he states the "50% better claim". AMD certainly knows by now where Interlagos will land performance wise,but JF can't say the exact number because,well there is no exact number since the launch is still in 2011.A lot can change and I believe it will change for the better,meaning Interlagos will overshoot the conservative estimate JF gave by a large margin. We will definetlly have more information in August ,with teh Official Bulldozer blog coming up and the Hot Chips and Analyst day events.Until then one can decipher the fading bars on an old chart all day long,only the thing is he will find zero relevant information...

this is why people need to not get emotional until benchmarks are out. theres too many new features that have to work together, and alot of unknowns just from the fab process, to really give off anything near accurate, unless A your able to predict the future, or B, insane.

many of us are happy to have someone on the inside of AMD to talk too about things. please dont scare him away because hes not a future teller.

Quote:

---

Originally Posted by terrace215

Oh, BS. When he posts performance claims about Bulldozer in a forum, it's obviously not some "personal belief" completely detached from his inside information, regardless of any disclaimer. If it were, it would be akin to "making things up", and what use would that be?

At this point I'm trying to resolve 2 things from his own posting history:

(1) What does "total throughput" mean? If the only performance claim AMD is making at this time is "Interlagos has 50% greater total throughput than MC", wouldn't you like to know what that even means?

(2) He's said the fading performance projections slide (*apparently* showing 50% greater fp throughput, 26% grater int throughput) for Interlagos was merely meant to say, "we are not making any actual projection at this time, other than it will be greater than MC". Ok, fine, let's accept that. In addition he says that in fact, they would not even be able to project accurately at that time, as it was too early. Ok, accept that too. And yet... at the very same time, he posts that he told Anandtech that Interlagos would have 60-80% higher throughput (specifically specInt_rate) than MC, and that this was conservative!

See the contradiction here? He says, "X" to one person 6 months ago, tells another they couldn't possibly predict "Y" back then, and didn't mean to suggest "Y" at all, and says the only claim they are making is "Z", which isn't even very well defined! And "X" "Y" and "Z" contradict one another.

It's all over the place. And sometimes, when you ask about these issues, the answer is, "Oh *I* never disclose -blah-, only AMD can officially do that", even though he HAS been posting precisely about -blah- all over the forums.

Crazy.

If he simply said, "We never intended Y" (he has done this), "X was a mistake/is withdrawn/is no longer accurate" (he has not done this), and "Z means ...." (he has not done this), then everything would be quite clear.

Note that I am not asking him to disclose more than he/AMD already have. I'm asking him to resolve the inconsistencies between the various things he's said, and in one case (Z), define a term that he used.

---

If that's the only claim they are making, you should connect two and two and come to the conclusion that that is the *only* claim they wish to make at this time. You won't get more, and you have no right to ask for more.

Quote:

---

Originally Posted by cegras

If that's the only claim they are making, you should connect two and two and come to the conclusion that that is the *only* claim they wish to make at this time. You won't get more, and you have no right to ask for more.

---

What you're saying is that I should assume he is (by implication) withdrawing the claim X (the Johan claim). I'm merely asking for confirmation.

As for "the only claim", I'm trying to understand what it means. Perhaps a specific example would help:

---
Suppose that NEW_CHIP has 25% better integer throughput, and 75% better FP throughput, than OLD_CHIP.

Would JF say that NEW_CHIP's "total throughput" was:

25% (the min)
50% (the average)
75% (the max)
100% (the "sum" of 25 and 75)

better than OLD_CHIP?
---

How is he defining "total throughput" in terms of int and fp throughput (for which folks commonly use the spec_rate benches)?

Without this being defined, the "only performance claim AMD is now making" is close to useless, as could imply a very large actual performance range. (Could mean int and fp each 25% greater, could mean fp 50%, int 100% greater-- that's a HUGE difference.) You see what I mean? It makes the "50%" fairly useless without a more precise definition. Might as well say, "greater throughput than MC", or, even, "we are making no performance claims at all at this time."

JF can choose to answer or not. I doubt he needs a fanbase to protect him from questions in the very forums he comments in, so what's with all these people saying, "stop asking him [to clarify] things [that he posted]!!!!!!111" ??

Frankly speaking, I don't entirely believe JF-AMD.:D:D

It's really not that hard too see: If he could tell us more then he would already have done it. Yes, JF haven't given a complete answer, but I'm not sure that you'll get one just because you ask five times.

Quote:

---

Originally Posted by Mats

It's really not that hard too see: If he could tell us more then he would already have done it. Yes, JF haven't given a complete answer, but I'm not sure that you'll get one just because you ask five times.

---

Your avatar is... why is that red-skinned person shoving a skyscraper up their backside? :)

@terrace - Ever considered the fact that he might even lose his job for relaying too much information about future products? AMD doesn't want to give Intel any clues at all about Bulldozer, not until they started selling the chips. AMD is in a tough position though, they're the underdog and have to please their investors. That's why AMD has to show that something better is coming in 2011, they just don't want Intel to have any idea how much better. A year is a long time and if Intel did know exactly how Bulldozer will perform then they can adjust their future plans to better compete with it.

It's really simple, AMD needs to please its investors without giving Intel any clues whatsoever and that's a bit of a problem.

Quote:

---

Originally Posted by terrace215

Lucky for you, these are precisely the 2 things I am asking him about now!

---

Man, give it a break. Maybe it will be great, maybe itl be so so. Wait till the launch, and ffs dont jump on faded graphs and old quotes

Quote:

---

Originally Posted by terrace215

Your avatar is... why is that red-skinned person shoving a skyscraper up their backside? :)

---

lol:rofl::rofl::rofl:
man you have a serious perception error
btw, I don't understand you simple predict from the presentation chart; that ain't precision/accurate chart, so stop speculating and extracting information out of such presentation chart.
stop doing such simple calculation here and assume BullDozer would scale in linear way. Most of the time, the scaling is non-linear(if you understand what i mean)

let me remind you, his avatar is a red sun and the yellow thingy was a building, asian style building.

Quote:

---

Originally Posted by LightSpeed

Man, give it a break. Maybe it will be great, maybe itl be so so. Wait till the launch, and ffs dont jump on faded graphs and old quotes

---

If my speculation & questions about JF's previously posted information on an upcoming product upset you, maybe ignore my posts, this thread, etc?

Quote:

---

Originally Posted by terrace215

Your avatar is... why is that red-skinned person shoving a skyscraper up their backside? :)

---

stop watching :banana::banana::banana::banana: :cord:

Quote:

---

Originally Posted by haylui

btw, I don't understand you simple predict from the presentation chart; that ain't precision/accurate chart, so stop speculating and extracting information out of such presentation chart.

---

read to the end of the thread... this has been resolved, and I'm no longer asking about the chart.

Quote:

---

let me remind you, his avatar is a red sun and the yellow thingy was a building, asian style building.

---

Some see a vase, some see two faces... :D

http://www.sapdesignguild.org/resour...ages/faces.gif

Quote:

---

Originally Posted by haylui

let me remind you, his avatar is a red sun and the yellow thingy was a building, asian style building.

---

You're right, that's (probably) the original idea. But I found the pic when I searched "best logo ever".
Nuff said..:D

Quote:

---

Originally Posted by terrace215

If my speculation & questions about JF's previously posted information on an upcoming product upset you, maybe ignore my posts, this thread, etc?

---

you know what makes most of the people feeling annoyed?
is that you don't even understand what is the presentation and chart do mean.
Don't waste time predicting what camera produce a photo by just looking at the photo.

Quote:

---

Originally Posted by terrace215

read to the end of the thread... this has been resolved, and I'm no longer asking about the chart.



Some see a vase, some see two faces... :D

http://www.sapdesignguild.org/resour...ages/faces.gif

---

but I guess you do not have the right to comment on other's avatar
do you?
and stop watching :banana::banana::banana::banana:s
lolz

Quote:

---

Originally Posted by haylui

you know what makes most of the people feeling annoyed?
is that you don't even understand what is the presentation and chart do mean.
Don't waste time predicting what camera produce a photo by just looking at the photo.

---

i enjoyed the initial conspiracy theorys that were coming out. i got bored with the nagging for details started

Quote:

---

Originally Posted by Manicdan

i enjoyed the initial conspiracy theorys that were coming out. i got bored with the nagging for details started

---

Exactly. Finding out minute details from sources not even close to being exact is what bothered me. nvm..

Quote:

---

Originally Posted by Dresdenboy

There is a presentation by Chuck Moore, where he wrote up about the same statements he's presented later, while already at AMD:
http://www.ece.rochester.edu/~albone...ides/moore.pdf

---

I don't think BD has any relation whatsoever with Trips. The people who designed BD did so in 2005-2007 and most have left AMD by now.

Quote:

---

One of the possible ways to evade to is to go to a cycletime, where instruction throughput (per unit time) peaks. Most of today's IPC is achieved by increasing complexity, thus increasing die area (and ever increasing static leakage) and limiting cycletime (or even decreasing without new processes), which means nearly stagnating clock frequencies. What if design gets simplified (lowering IPC), but allows for 20% or more area savings and increasing clock frequency (without having to increase voltage, since less complex circuitry does the job faster). Well, this is just one idea.

---

You're basically talking Netburst. Those were the premises on which Netburst was based. It is interesting to see that they are more valid today than in the past. It very well could be that we will see a Netburst revisited uarch for the upcoming process nodes. There's a limit to the Pentium Pro off springs anyway.
The lead uarch for Nehalem said that if they would have used Netburst as a starting point for Nehalem and not Core, the performance would have been higher, but with worse energy efficiency. Interesting remark anyway ( from a Stanford lecture on Nehalem ).

Quote:

---

Having different clock domains in a module would allow to choose closer to optimal cycle times for different units, also driven by the type of work to do. E.g. decoding could have a longer pipeline if some trace caches and good branch prediction is present. A shared FPU would also be a candidate for a longer pipeline while integer cores could benefit from a short schedule execute loop and be clocked lower, but be 4-wide. There are so many possible techniques...

---

True. However, the word no to forget is latency, whenever you need to cross clock domains or arbitrate streams you have latency.

Quote:

---

What can be different are the granularity and the units themselves.

Granularity: power down/up, clock differently the different subunits, as power budget permits and queue fill level requires

Units: scale them to what fits best and optimize power usage this way.. e.g. switch off some L2 cache ways or execution units
or activate them as needed (by tracking the upcoming instructions and powering up/clocking the appropriate subunits).

---

When you have so many cores, it becomes a bit useless to think as small as powering different units down, its way better to power cores down as done in Nehalem. I mean, from 8 modules, what's the benefit of shutting down 3 integer clusters ? Why not turn off 2 modules ?
Regarding caches, you always need to maintain coherency ( so L3 isn't a candidate ), so powering down the L2 , you can as well power down the cores attached to it.

I don't think BD has any relation whatsoever with Trips. The people who designed BD did so in 2005-2007 and most have left AMD by now.

lol, now?! Now is AMD in very good position behind last 2 years! Began it with HD4000 and Phenom II launch in january 2009 ( first maybe 2008 with first Phenoms B3 revision and good mainstream series HD3000). And now, HD5000 is dominate, Thuban are great (great performance, OC potencial, power consumption at 45nm 6 cores is beautiful)

Quote:

---

Originally Posted by FlanK3r

I don't think BD has any relation whatsoever with Trips. The people who designed BD did so in 2005-2007 and most have left AMD by now.

lol, now?! Now is AMD in very good position behind last 2 years! Began it with HD4000 and Phenom II launch in january 2009 ( first maybe 2008 with first Phenoms B3 revision and good mainstream series HD3000). And now, HD5000 is dominate, Thuban are great (great performance, OC potencial, power consumption at 45nm 6 cores is beautiful)

---

And your point is ? :confused:

Quote:

---

Originally Posted by savantu

And your point is ? :confused:

---

That AMD is in a good position contrary to your disbelief and fanboi outbreaks on the forums? :cool:

Quote:

---

Originally Posted by Shadov

That AMD is in a good position contrary to your disbelief and fanboi outbreaks on the forums? :cool:

---

Could we stop using the f word? (fanboy) Savantu is only trying to prove Dresdenboy wrong, that's something that should be normal in any proper discussion. I don't see anything fanboy about that, he's just trying to realistic in his own ways even though you might consider it to be pessimistic.

Quote:

---

Originally Posted by Helmore

Could we stop using the f word? (fanboy) Savantu is only trying to prove Dresdenboy wrong, that's something that should be normal in any proper discussion. I don't see anything fanboy about that, he's just trying to realistic in his own ways even though you might consider it to be pessimistic.

---

+1
You guys are talking about two different things. savantu talkks about that pdf, and FlanK3r about something else..

Quote:

---

Originally Posted by Helmore

Could we stop using the f word? (fanboy) Savantu is only trying to prove Dresdenboy wrong, that's something that should be normal in any proper discussion. I don't see anything fanboy about that, he's just trying to realistic in his own ways even though you might consider it to be pessimistic.

---

So the guy who used to a use sig that mocked AMD and has routinely attacked any thread about AMD products is "just trying to realistic in his own ways"? I don't believe that, history says otherwise.

Quote:

---

Originally Posted by MrMojoZ

So the guy who used to a use sig that mocked AMD and has routinely attacked any thread about AMD products is "just trying to realistic in his own ways"? I don't believe that, history says otherwise.

---

How come your ONLY contribution to this thread, and many others, I must say, is to always go after perceived anti-AMD contributors. There's some great info in this thread, you can focus on that or you can choose to focus on peoples sigs. Stay out if you have nothing better to contribute.

Quote:

---

Originally Posted by OhNoes!

How come your ONLY contribution to this thread, and many others, I must say, is to always go after perceived anti-AMD contributors. There's some great info in this thread, you can focus on that or you can choose to focus on peoples sigs. Stay out if you have nothing better to contribute.

---

same was said to you, thanks for coming back bringing this message

Quote:

---

Originally Posted by OhNoes!

How come your ONLY contribution to this thread, and many others, I must say, is to always go after perceived anti-AMD contributors. There's some great info in this thread, you can focus on that or you can choose to focus on peoples sigs. Stay out if you have nothing better to contribute.

---

And most of those people don't actually contribute anything either, they just want to drive the thread into worthlessness. And they do it over and over. Why aren't you asking them the same questions? I'm all up for debate and discussion, but that isn't what happens in these threads once certain people jump in. These threads get derailed long before I make any posts.

Quote:

---

Originally Posted by Manicdan

same was said to you, thanks for coming back bringing this message

---

*snicker*

Quote:

---

Originally Posted by haylui

lol:rofl::rofl::rofl:
man you have a serious perception error
btw, I don't understand you simple predict from the presentation chart; that ain't precision/accurate chart, so stop speculating and extracting information out of such presentation chart.
stop doing such simple calculation here and assume BullDozer would scale in linear way. Most of the time, the scaling is non-linear(if you understand what i mean)

let me remind you, his avatar is a red sun and the yellow thingy was a building, asian style building.

---

TOTAL OT:
The power of suggestion. I took a look at the picture and I see what he means there. Got me laughing :ROTF::rofl:

Quote:

---

Originally Posted by blindbox

TOTAL OT:
The power of suggestion. I took a look at the picture and I see what he means there. Got me laughing :ROTF::rofl:

---

I have also always wondered what Mats' avatar was supposed to be and I was thinking along the same line as savantu but I didn't dare to ask :p:.

Quote:

---

Originally Posted by FlanK3r

Anandtech is not middle of world ;). U read maybe 1-5 review, i read 40. TRy example encoding videos 6x in the same time and u will see diference.:) Now im in work, but later at home, can u send PM with reviews. Definetely, x6 1090T is in real multi thread aplication compared with i7 965 +-.PS: games are ok, but its not optimalized for more than quadcores (i mean not 10% load at others cores, its nothing). Watch in games at x4 965 and x6 1090T. 965 BE will better.

---

Yes and how many apps take advantage of more than 4 cores? Single threaded performance is still relevant today. Only thing AMD has it going is brute force with more cores and high clock speeds.

Quote:

---

Originally Posted by Clairvoyant129

Yes and how many apps take advantage of more than 4 cores? Single threaded performance is still relevant today. Only thing AMD has it going is brute force with more cores and high clock speeds.

---

The kernel and the whole operating system. Linux and any other *nix systems welcome more cores. Apps? Highly threaded video encoding : mencoder, transcode - databases, rendering for example.

Instead of ditching the cpu which has more cores, people should ditch the OS or apps which can't fully utilize the *expensive* cpu they just bought. What a waste!

HT is the perfect mask to fool the OS/app/*user that they're doing high level computing. Give real cores to the workload and see them crunch it!

Upgrade the computing instead of the computer. But wait! Ask Intel to upgrade the HT to x3 : 4 cores gives 12 threads. Now that's computing higher as ever.

On linux, try

Quote:

---

make all -j100

---

and split the workload into a 100 threads shared by 2 cores, but it won't make any headway with either speed or time taken to compile. Might be better off with just

Quote:

---

make all -j4

---

or

Quote:

---

make all -j2

---

Clairvoyant129: good question :). But future is not only for single operations. Who want PC for internet, movies etc, dont need Quadcores, he pay some dual core. Who wnat more, example gaming Arma, GTA, Battlefield, working in 3D, workling with graphic programs, making and editing videos, this people need more than dualcores (as minimal triple core or dual with HT). And enthusiast also.
But u are right, most aplliactions is optimalized for single or dual cores (http://www.tomshardware.com/reviews/...ling,2652.html , here we can see big diference from single up to dualcore), i see minimum dualcore as new build PC today. If today are still mostly single threaded operations, we have at modern CPUs turbo aplications. But...if we compared example E8400 with todays CPUs core to core, dont seen big diference (1 core E8400 is very simillary to x2 550 BE or some core i7 core without turbo).
Good point is more and more multithreaded operation for consumers and in CPU maybe project Fusion.

Quote:

---

Originally Posted by pokipoki

The kernel and the whole operating system. Linux and any other *nix systems welcome more cores. Apps? Highly threaded video encoding : mencoder, transcode - databases, rendering for example.

Instead of ditching the cpu which has more cores, people should ditch the OS or apps which can't fully utilize the *expensive* cpu they just bought. What a waste!

HT is the perfect mask to fool the OS/app/*user that they're doing high level computing. Give real cores to the workload and see them crunch it!

Upgrade the computing instead of the computer.

---

HT fools the user huh? And where is your assumption based on? Do you have a evidence that shows HT doesn't improve performance? From my understanding and in the reviews I have seen HT has a positive impact on performance. So if it does add performance why not use it? :shrug:

Quote:

---

Originally Posted by Clairvoyant129

HT fools the user huh? And where is your assumption based on? Do you have a evidence that shows HT doesn't improve performance? From my understanding and in the reviews I have seen HT has a positive impact on performance. So if it does add performance why not use it? :shrug:

---

id say the marketing of intel fools the user

the commercials talk about the turbo feature of the cpu as being better than the internet, wifi, and some other things.
http://www.youtube.com/watch?v=RSqMTWrlF-8

Quote:

---

Originally Posted by Clairvoyant129

HT fools the user huh? And where is your assumption based on? Do you have a evidence that shows HT doesn't improve performance? From my understanding and in the reviews I have seen HT has a positive impact on performance. So if it does add performance why not use it? :shrug:

---

yes it does because the dumbasses at best buy say they are real cores.

i know this from personal experience

HT is mostly positive (1-30%), but sometimes not. For some applications and games, it skips to another threads and the threads around, and then it has negative impact.

Quote:

---

Originally Posted by Clairvoyant129

HT fools the user huh? And where is your assumption based on? Do you have a evidence that shows HT doesn't improve performance? From my understanding and in the reviews I have seen HT has a positive impact on performance. So if it does add performance why not use it? :shrug:

---

HT does not make any sense when a workload demands a dedicated throughput from a true cpu core.

Check my previous post, edited to make my point on threading.

If HT is so good, why not increase it a hundred fold?

Quote:

---

Originally Posted by pokipoki

HT does not make any sense when a workload demands a dedicated throughput from a true cpu core.

Check my previous post, edited to make my point on threading.

If HT is so good, why not increase it a hundred fold?

---

Your points are irrelevant because HT does in fact improve performance the vast majority of the time, if only by a small amount. Therefore, it is good.

Quote:

---

Originally Posted by ElSel10

Your points are irrelevant because HT does in fact improve performance the vast majority of the time, if only by a small amount. Therefore, it is good.

---

Better than a real cpu core?

Quote:

---

Originally Posted by pokipoki

Better than a real cpu core?

---

No, but another real CPU core takes twice the space and twice the power while HT only requires a little more power and a little more space and that's why HT is a good compromise.

for the most part to me multi core is more about the future then now.

The vast majority of apps that I use are not multi threaded and are able to saturate a single core and be constrained by the cpu with idle cores. Intel must have realised the problem hence the turbo mode on the new processors. Apparently it is not easy to code multi threading so I expect it is not something we will see in mainstream apps anytime soon, it will be limited to very cpu heavy stuff such as encoding apps.

Quote:

---

Originally Posted by pokipoki

Better than a real cpu core?

---

I don't think thats the right question. Is a real core+HT thread better than just a real CPU core? In multi-threaded environments, often times yes. Anyone claiming it to be a magic bullet for every scenario is full of it though.

maybe now again back to Bulldozer thema?:)

Quote:

---

Originally Posted by FlanK3r

maybe now again back to Bulldozer thema?:)

---

There isn't any new BD info to discuss. And theorizing summons the wackjobs it seems. :(

Quote:

---

Yes and how many apps take advantage of more than 4 cores? Single threaded performance is still relevant today. Only thing AMD has it going is brute force with more cores and high clock speeds.

---

More cores will always be better than more threads, hyper or not. AMD is right to add more cores in BD. Those who think adding cores does not provide better performance are handicapped by their restricted computing experience.

Quote:

---

Originally Posted by Helmore

No, but another real CPU core takes twice the space and twice the power while HT only requires a little more power and a little more space and that's why HT is a good compromise.

---

Exactly, it all about the design trade-offs decided by the architect(s). An additional core would require a bare minimum of twice the area (note: core area only, some chip-level components will be shared) and would likely make bus arbitration/data coherency mildly more complex (+ latency due to physical layout constraints), however close to twice the potential throughput could be created. As for HT/SMT, the intent is to piggyback on most of the existing infrastructure (ie. share caches) and achieve the most efficiency possible with the execution units, that way the area consumption is no where near that of a new core.

Quote:

---

Originally Posted by pokipoki

HT does not make any sense when a workload demands a dedicated throughput from a true cpu core.

Check my previous post, edited to make my point on threading.

If HT is so good, why not increase it a hundred fold?

---

High-throughput does not imply low-latency, although the other way around tends to be true somewhat more often. Whether a uArch is physically distinct cores/threads or an assortment of SMT/HT threads, a true throughput workload should not care about such differences when taking efficiency and physical constraints into account. That is, unless there is an emphasis on latency and of what granularity, even then there's often no clear answer.

Afaik 2-4x SMT is the acceptable balance between overhead and performance gain for most targeted workloads. 100x would be just plain asinine, that is unless you'd have an absolutely terrible deep pipeline chock-full of hazards, along with an equally bad main memory latency :rolleyes: (arguably at the point of 100+ threads per "core" you wouldn't likely be in the category of traditional pipeline + SMT anyways)

Quote:

---

Originally Posted by pokipoki

More cores will always be better than more threads, hyper or not. AMD is right to add more cores in BD. Those who think adding cores does not provide better performance are handicapped by their restricted computing experience.

---

Isn't that somewhat of a contradiction? More cores directly implies more threads, since [hardware] threads are the low-level concept for program flow and at a basic level one core must have at least one thread of operation (while more can be multiplexed in SMT).

What you're trying to do here is make an overall justification for more cores without taking any real design constraints into account, while I'll add more cores certainly is the current industry trend. However, it's the architect's job to evaluate when it's applicable to add physical cores in lieu of SMT or any IPC improvement for that matter. While the concepts involved aren't hard per say, it's the slew of constraints that make these decisions more statistical analysis than judging based on raw merit.

The HT vs. cores argument will never be solved here. The reality is that we should just look at total throughput and spend less time thinking about how you get there.

Quote:

---

Originally Posted by Chrysalis

for the most part to me multi core is more about the future then now.

The vast majority of apps that I use are not multi threaded and are able to saturate a single core and be constrained by the cpu with idle cores. Intel must have realised the problem hence the turbo mode on the new processors. Apparently it is not easy to code multi threading so I expect it is not something we will see in mainstream apps anytime soon, it will be limited to very cpu heavy stuff such as encoding apps.

---

I know everyone uses their computer differently, but I needed multi-core before multi-core cpus even existed. It's very rarely that I'm only running a single single-threaded application. Adding more cores may not help one ST app, but it will allow me to run more apps simultaneously before they slow down. Not to mention having the spare resources to deal with all the background processes, daemons, etc always running in modern OSes.

What's going to matter to the majority of end users ( besides the biggest factor: the name on the box :rolleyes: ) is which processor will give them the best experience for the least money, not implementation details like core count, IPC vs throughput, etc. For the extreme part of the market, absolute performance is important, but often in these scenarios the apps are multithreaded or we are power users doing heavy multitasking. I'd suggest that it's a very small segment of the market that needs to run only one CPU-bound single-threaded app at maximum speed.

Quote:

---

Originally Posted by JF-AMD

The HT vs. cores argument will never be solved here. The reality is that we should just look at total throughput and spend less time thinking about how you get there.

---

I don't think there should even be an argument about this, SMT is not a replacement for cores, it is simply there to take care of inefficiency, or rather, it enhances efficiency. Intel did not push bloomfield as an octacore, but a quadcore, capable of rendering 8 threads, thanks to smt. SMT is not a fluke, and has proven real-world benefits. If it weren't for HT, bloomfield would struggle to compete with thuban in highly multithreaded apps. In some inefficiently coded apps the more threads you run the better results you'd get, and these scenarios are where HT helps a lot.

With that in mind, and since Intel is also in the multicore game, Intel seems poised to rely on SMT for the foreseeable future, to maintain their lead by processing more threads, albeit with less physical cores.

The main issue is that most people in the Hyper Threading (SMT) vs real Cores discussion can't state properly a decent comparision. The question is how much increase in die size and power consumption SMT equals to, comparing it to the extra performance when you are using that additional Thread, against an identical Core but without SMT support.

Intel has once stated if I recall correctly that inclusion of Hyper Threading on Pentium 4 was just an extra 5% of die size. Imagine the following with a 10% of die size area increase due to SMT support:

A standalone Core of a Processor without SMT (1 Core, 1 Thread): 50mm^2
A standalone Core of a Processor with SMT (1 Core, 2 Threads): 55mm^2

Lets say that you have a 1100mm^2 die size budget to spend adding Cores together for a Processor die...

1100mm^2 / 50 mm^2 = 22 Cores, 22 Threads
1100mm^2 / 55 mm^2 = 20 Cores, 40 Threads

And lets also assume that an application can scale well even with such a high amount of Threads. Now, compared to the fact that you're losing two physical Cores, does the extra 18 Threads gives you MORE performance than those physical Cores that you lose in the same die size space? If the response is yes, SMT is worth it if Software scales. If the response is no, then SMT is useless.

Quote:

---

Originally Posted by zir_blazer

The main issue is that most people in the Hyper Threading (SMT) vs real Cores discussion can't state properly a decent comparision. The question is how much increase in die size and power consumption SMT equals to, comparing it to the extra performance when you are using that additional Thread, against an identical Core but without SMT support.

---

And I would add, power is much more important than die size, unless you're talking something crazy.

And, in fact, that's what Intel said about Hyperthreading, in one of the Nehalem talks:

It was the feature that provided the most performance/W gain of the many that were added. It didn't take much space, it had great perf/W benefits, and the downside was actually in implementation complexity (tricky to get right) and validation (tricky to prove you got it right). As you can imagine, it really explodes the number of possible core states.

^^zir_blazer
That's the point I was trying to get at, there's so many variables/constraints involved that there's no easy direct comparison between more vanilla cores, SMT, or even the in-between variant Cluster-based Multi-threading (CMT) more applicable here. It's all about cutting the resource budget into the perceived best slice, when it's not even just the transistor budget (area) comprising the only constraint; there's still power-efficiency/density and overall chip development/logic/layout complexity that's affected, along with the varying performance gains[/loses] for each workload in evaluation.

Once Bulldozer is out it'll be nice to see an example of CMT in action and hopefully discern some bit of information on how the concept performs in application/implementation. Assuming that's what it'll implement :)

Quote:

---

Originally Posted by JF-AMD

The HT vs. cores argument will never be solved here. The reality is that we should just look at total throughput and spend less time thinking about how you get there.

---

Definately on the first part, but it doesn't hurt when discussions get you thinking [without propagating misinformation]. That reality is true for the majority of end-users/consumers, but there's at least a few around here that like to drill a little further into the details from either a personal relation to the industry/field or a general intellectual intrigue :D

Quote:

---

Originally Posted by Helmore

No, but another real CPU core takes twice the space and twice the power while HT only requires a little more power and a little more space and that's why HT is a good compromise.

---

Then how come a 1090T (hexa-core) uses less wattage than a i7-930 (quad-core with HT)? Aren't they comparable in performance?

Quote:

---

Originally Posted by richierich

Then how come a 1090T (hexa-core) uses less wattage than a i7-930 (quad-core with HT)? Aren't they comparable in performance?

---

http://techreport.com/articles.x/18799/4:confused:

you cant compare amd to intel to get an idea of how effective HT is. do an HT on/off test with the exact same system. HT increases power consumption, power efficiency and performance.
http://techreport.com/articles.x/15818/14

Quote:

---

Originally Posted by richierich

Then how come a 1090T (hexa-core) uses less wattage than a i7-930 (quad-core with HT)? Aren't they comparable in performance?

---

Then you didn't understanded anything. We're talking about the impact of SMT as an isolated feature, not doing a K10 vs Nehalem comparision.

Quote:

---

Originally Posted by richierich

Then how come a 1090T (hexa-core) uses less wattage than a i7-930 (quad-core with HT)? Aren't they comparable in performance?

---

cause a 1090T uses as much as a PII 940, which is 15 months older (when did i7 930 come out? if its more than 7-8 months ago, i would compare it to the 940 instead of the 1090T)

Looks like it's already been beaten to death, but just a quick rundown of reasons (each significant enough on its own):
1) Fundamentally different physical processes when it comes to power efficiency (SOI vs HKMG Bulk)
2) Cache/interconnection/chip-level designs differ at the transistor level -> More/less active logic
3) Vastly different pipelines and power consumption profiles -> Each has strengths/weaknesses in different applications/benchmarks
4) Power management is different (power-gating, etc.) -> Not all portions of the chip are consuming active power at a given moment
5) Considering the PII 940 and 1090T consume roughly the same amount of power, layout and process refinements skew the results widely

AMD have created a small doll with Intel i7 logo on it; poking and chanting voodoo chinese sounds in a basement dressed in red/green/black stuff while in the next room they collect the soul of the Nahalem in a big jar so that they can pour it in the new Bulldozer - Its that simple, mkay ?

Quote:

---

Originally Posted by Solus Corvus

I know everyone uses their computer differently, but I needed multi-core before multi-core cpus even existed. It's very rarely that I'm only running a single single-threaded application. Adding more cores may not help one ST app, but it will allow me to run more apps simultaneously before they slow down. Not to mention having the spare resources to deal with all the background processes, daemons, etc always running in modern OSes.

What's going to matter to the majority of end users ( besides the biggest factor: the name on the box :rolleyes: ) is which processor will give them the best experience for the least money, not implementation details like core count, IPC vs throughput, etc. For the extreme part of the market, absolute performance is important, but often in these scenarios the apps are multithreaded or we are power users doing heavy multitasking. I'd suggest that it's a very small segment of the market that needs to run only one CPU-bound single-threaded app at maximum speed.

---

I bet the browser you using to type that message is single threaded. :) Although I know you meant a single threaded app that maxes out the cpu :)

Your last sentence is key there. The vast majority of apps are single threaded bound but end users will like been able to run multiple apps at once without them affecting each other, multi core is defenitly useful for that.

For what its worth I think hyperthreading is useless near enough. A gimmick from intel. I run various servers, and servers love multiple cpu's, however in a server environment htt only serves to cause problems because apps when allocating threads to processors expect a real processor not some virtual processor that has no dedicated processing power. So eg. you can have 4 core intel with htt so 8 processors and mysql uses processors 1,2 and 4 with 1 and 2 been the same physical core which leads to an unbalanced load.