K10 has 3 ALUs and 3 AGUs. No matter how hard you and others try to downplay K10 execution resources, fact is, a K10 integer core has more resources than a BD integer core.Originally Posted by -Boris-
The docs linked by Hans are pretty clear.
http://www.xtremesystems.org/forums/...&postcount=681
No, you are wrong. Old architecture has shared resources, new architecture has dedicated resources.
A BD integer core will do more IPC and perform single threads faster than an old core.
Why do you keep saying these things even though I have posted the information in multiple places?
JF...have you personally seen running BD chips yet or whatever the server variant is called? Just wondering how you're so sure if you haven't bench tested one yet.
Does anyone here know when BD compatible socket motherboards will go on sale?
As quoted by LowRun......"So, we are one week past AMD's worst case scenario for BD's availability but they don't feel like communicating about the delay, I suppose AMD must be removed from the reliable sources list for AMD's products launch dates"
I'm pretty sure that when you have the position JF has in a company you get pretty accurate numbers from engineering and so on. There is no need for him to sit down and bench engineering samples personally. Would be quite stupid if engineering lied about the performance in internal reviews and documents.
You know this isn't Dilbertland right?
Thanks for answering that JF.I'm pretty sure that when you have the position JF has in a company you get pretty accurate numbers from engineering and so on. There is no need for him to sit down and bench engineering samples personally. Would be quite stupid if engineering lied about the performance in internal reviews and documents.
You know this isn't Dilbertland right?
So if he's getting accurate numbers from engineering, then it's a simple thing for him to say, "BD numbers are better than existing chips". Simple right?
As quoted by LowRun......"So, we are one week past AMD's worst case scenario for BD's availability but they don't feel like communicating about the delay, I suppose AMD must be removed from the reliable sources list for AMD's products launch dates"
That's pretty much what he have said countless times already.Thanks for answering that JF.
So if he's getting accurate numbers from engineering, then it's a simple thing for him to say, "BD numbers are better than existing chips". Simple right?
http://www.xtremesystems.org/forums/...&postcount=602
Thanks for answering that JF.
So if he's getting accurate numbers from engineering, then it's a simple thing for him to say, "BD numbers are better than existing chips". Simple right?
in fact its been said couples of times by JF-AMD himself ....
sharing most inevitably mean communism for some .... but not for me .. if its to bring a good product at an affordable price with a big improvement over the last product im all for anything really
arguying with the man who works at the company to wich you decide to pick about said product .. and said person is in talk with engineers who built the damn thing ....
Last edited by Sn0wm@n; 08-31-2010 at 05:53 AM.
WILL CUDDLE FOR FOOD
Let's say their past history isn't as imaculate as you portray it. There is an alternate discussion on BD details on Aces and Paul Demone directly answers JFs claims :I'm pretty sure that when you have the position JF has in a company you get pretty accurate numbers from engineering and so on. There is no need for him to sit down and bench engineering samples personally. Would be quite stupid if engineering lied about the performance in internal reviews and documents.
You know this isn't Dilbertland right?
BD taped out a month or two ago. If they were lucky silicon is mostly functional. If not, they are working overtime to fix it and get working samples. Silicon is being characterized and in pre-validation stage.
ROFL. A Niagara has higher "aggregate" (across all threads) IPC than a US-IV
but far lower single thread performance. Listen for what a salesman doesn't
say! Higher single thread performance than K10? Probably, but at far higher
clock rates enabled by a deeper pipeline, simpler cores, and a process shrink.
I remember another AMD "great white hope" chip called Barcelona.
I remember another rash and brash AMD marketing guy called Henri Richard.
That guy said a lot of things about that chip, made a lot of fantastic claims
of how it would make Intel cry. AMD fans worshipped the ground he walked on.
The funny thing is that once Barcelona silicon was characterized, SKUs defined,
and the first pre-release internal benchmark data compiled that guy left AMD so
fast it made the air crackle. Once Barcelona was released it was obvious why. :-D
Good ole JF has said a lot of things about BD. My guess is he still has at least
18 months to spin BD before having a third party reality check. I hope unlike
Henri he sticks it out post BD release just to see his fancy footwork trying to
match these claims up to reality.
Until then I'll believe a gram of disclosure from AMD's current and recent design
engineers over a ton of claims from a marketing guy. My advice to AMD fans
hanging on to JF's every last word is to remember back on what Henri Richard
said in private vs what he said in public.
http://news.cnet.com/8301-13924_3-10433953-64.html
an excerpt of a 2004 internal AMD communication from former AMD Executive Vice
President Henri Richard, the company's then-highest-ranking sales executive: "If you
look at it with an objective set of eyes, you would never buy AMD. I certainly would
never buy AMD for a personal system, if I wasn't working here."
In other words, benchmarks and performance are second place at this time, most important is getting a functional chip.
What this all means, every claim about BD performance is based on estimates done without having actual silicon in hand.
SUN Rock was meant to be the greatest chip done in the past decade with with innovative features like transactional memory and scout threads. I still remember Jonathan Schwartz, how ecstatic he was over Rock.
Rock turned out a complete dud, burning 300w and abisymal performance.
Last edited by savantu; 08-31-2010 at 04:58 AM.
I don't agree with the word "estimates"
A design is validated and debugged long before it goes to silicon. Validation
is done both by cycle accurate software simulation and FPGA hardware
emulation. An FPGA hardware implementation of the core, or entire processor,
can run 10+MHz and can be made cycle accurate. This is also how you do
performance tuning during the design phase itself.
Typically operating systems are booted and many software applications
are run long before you go to silicon.
About your link......
What in this musing from the investment board inhabitants can be classified
as not being investor FUD and of any technical relevance concerning
the architectural details of bulldozer?
Regards, Hans
~~~~ http://www.chip-architect.org ~~~~ http://www.physics-quest.org ~~~~
Is this clear enough?
This is quite a fascinating architecture. If that RWT article is accurate then I am extremely interested in seeing some benchmarks.
I don't buy that overall per-core IPC must necessarily decrease (in relation to K10) because of reduced interger ALUs. Of course they will obviously miss out, compared to a 3 or 4 ALU core, on cases where int ILP is greater then 2. But in cases where the code is more mixed int and memory ops, IPC could go up in relation to K10 - based on available execution resources alone. Which case is more common obviously depends on the specific code being ran. Though I'd suggest that a program with consistently high integer ILP would be more efficient using packed integers (handled by the FPU) anyway.
If we add to that the fact that missed branches and cache misses (both significantly improved in BD) have a much greater effect on overall IPC than some missed ILP cases, it's clear that claiming lower IPC than K10 isn't really justified based on fewer ALUs alone. I doubt that BD will have lower IPC per-core than K10. In reality it's probably somewhere in the vast gulf between PII and SB.
As already noted though, IPC isn't the only factor in a processor's performance. This is obviously a high frequency design. The memory and cache subsystems are a big leap forward for AMD. They are designed to keep a large number of cores well fed - to minimize the amount of time that execution resources are waiting on data and thus increase efficiency. Intel will probably continue to lead in IPC by a significant margin. Whether AMD can increase frequency enough to make single threaded performance competitive remains to be seen. On the multi-threaded side BD sounds like a monster.
If AMD can't match Intel's single threaded performance it looks like we will have a split market come 2011. Office users and gamers might do best with SB while people doing encoding, folding, heavy multitasking, HPC, and servers might do best with BD.
do you have any clue as to what happens in post-Si validation? based off of your post i'd bet against it.
I don't have any reason to be in building 400. And it is better off that the marketing guy is not "dropping in" on them.
Our performance engineering team has done a real accurate job on performance modeling in the past, I have no reason to doubt them. Generally the worst that we see is too much conservatism, not too much optimism.
He's right. K10 has more resources, shared or not.
Friends shouldn't let friends use Windows 7 until Microsoft fixes Windows Explorer (link)
If you can't use it it isn't a resource. Phenom has only three integer pipes. In one of those pipes the AGU and ALU have to take turns being part of the resource pool.
OK, so let me get the gist of all of this whole thread down to two statements:
1. People are claiming Bulldozer will be slower than existing products because they are sharing resources in the processor and sharing is inherently worse.
2. People are claiming that even though Bulldozer has dedicated resources relative to the old architecture that shares them, this is worse.
OK, I got it now.
THey are Intel fanboysNo problem !
When AMD had 64-bit and Intel had only 32-bit, they tried to tell the world there was no need for 64-bit. Until they got 64-bit.
When AMD had IMC and Intel had FSB, they told the world "there is plenty of life left in the FSB" (actual quote, and yes, they had *math* to show it had more bandwidth). Until they got an IMC.
When AMD had dual core and Intel had single core, they told the world that consumers don't need multi core. Until they got dual core.
When intel was using MCM, they said it was a better solution than native dies. Until they got native dies. (To be fair, we knocked *unconnected* MCM, and still do, we never knocked MCM as a technology, so hold your flames.)by John Fruehe
I'll make it short and easy to understand. Original quote:
Which is 100% true, as K10 has more execution units. I don't see the words perfomance, shared or dedicated in this post. Then you say:
Which is wrong, based on the above. I just pointed it out, but it seems it was a perfect excuse to ignore what the guy is actually saying (as you like to do) and repeat the same post you've been repeating how many times now?
I hope you properly get it now.
Friends shouldn't let friends use Windows 7 until Microsoft fixes Windows Explorer (link)
Quotes taken out of context can be true, but in context they can mean something different. Your quote was a response to my post about pipes. He is trying to make 3 pipelines appear like 6 pipes. Which is a twist to the truth.
BD has more resources since it can use 2 ALUs and 2 AGUs every clock, Phenom II averages at 1.5 ALUs and 1.5 AGUs since the share pipe. Again, if you can't use it, it isn't a resource. 2+2=4 (3+3)/2=3.
The discussion is still around IPC. Even if you try to make it look different. And it's still about BDs integer execution capacity compared to k8 (10h), we are pointing out that BDs 4 pipes seems a bit stronger than K8s 3 pipes.
And by adding the different parts of K8s pipeline together some people here are trying to make them look twice as strong.
4 pipes equals more resources than 3.
Last edited by -Boris-; 08-31-2010 at 06:24 AM.
The thing is that it uses it. If the CPU can't use all 6 at the same time that's another thing. All 6 will get used at some point. Either way, they are on the die, they're connected, and they are used. Alternatively, not at the same time, whatever. But they are there, they are used and thus they are a resource. K10 has more resources than BD (integer "clusters").
Instructions per clock (compared to K10). Frequency doesn't matter, this is per clock:
IPC (CPU level) --> Will be higher, more "modules", double integer resources per "module", less resources per integer "cluster", better use of available resources per integer "cluster".
IPC ("module" level) --> Will be higher, double integer resources per "module", less resources per integer "cluster", better use of available resources per integer "cluster".
IPC (single integer "cluster") --> Less resources, better use of available resources. Higher or lower instructions per clock?
The bold part is likely lower, and that's exactly what savantu, terrace and others are discussing here. IPC per integer "cluster". We don't know for sure, since JF just says "IPC will be higher". At what of the previous levels? After all the BS, bans, etc. he still hasn't answered this question.
Now, if you throw frecuency in the mix, knowing that it will be higher than current K10 CPUs, of course you can say single integer "cluster" perfomance is higher. Just notice how he never uses IPC+higher+per integer "cluster" in the same sentence. The only info we know about single thread perfomance is that it will "be higher". Of course, because of the higher frequency, not because IPC is higher.
JF just has to answer the question and this debate is going to end fast: IPC per integer cluster has been increased or not? No BS, just yes or no.
Friends shouldn't let friends use Windows 7 until Microsoft fixes Windows Explorer (link)
Hans wrote for the K8:
http://chip-architect.com/news/2003_...it_Core.html#3Each Scheduler can launch one ALU and one AGU operation per cycle. The ALU operation may come from one x86 instruction while the AGU operation may come from another.
That is no 1.5, that is 3 ... maybe u missed the fact, that the MacroOps are splitted into µOps at that stage ?
this is how I think of them
Posting Permissions
Reply With Quote
Bookmarks