Printable View
It could be more efficient to use one module if that means it can turbo (higher) instead of two when using a lower amount of threads. At least from a power consumption perspective it could be smarter to use one module instead of two.Quote:
Originally Posted by JkS
2 threads in a module at 90% IPC of seperate modules at 110% speed will be ~100% performance but power consumption should be lower.
Good points marten_larsson. There are still a few things we don't know about the design,so I guess we should wait and see how the cores are handling the workloads when workload is less threaded(than the core count).
I would expect that responsibility ultimately ends up at the OS thread scheduler's mercy (or use of direct thread binding). It should still pose a similar situation as Hyper-Threading/SMT, the scheduler could use whatever logical processors it wants, however it *might* not necessarily know how to optimize for the underlying micro-architectural implications, e.g. the logical to physical mapping and their resource-sharing relation.Quote:
Originally Posted by JkS
The more I hear about Bulldozer, the more I see it as an adaptation of the ideas inherent in the UltraSPARC T2/3 architecture, with AMD mainly emphasizing single-thread latency instead of going all out on throughput :p:
i think i understand what you meanQuote:
Originally Posted by marten_larsson
example:
4 threads each on their own module might use 70% of the TDP and overclock 10-15%
vs
4 threads on 2 modules which would use about 50% of the TDP and overclock 20-25%, but have 5-10% less IPC due to shared resources.
in the end it might actually break even or be negligible differences for either route, which is kinda good since it means no matter how messed up windows is at deciding threads, BD knows how to overclock for max performance.
Manicdan there is also a cooperative prefetch bonus when threads share same L2 cache,which in turn may increase the performance to some degree.But maybe it's already counted in the already mentioned 80% boost when module is fully loaded. The shared frontend will act similarly to intel's SMT in other beneficiary way:it will smooth out inefficient usage by filling unused integer pipelines as quickly as possible ,just as SMT functionality does on one intel Nehalem/SB core.Only in AMD's case we have a whole core to grab the data,not just a vacant port in the execution stack ;).That's why AMD can see 80% increase from 2 threads and intel sees 20%-25%.
If im not mistaken, DENEBs integer Execution unit has 3 integer pipes PLUS 3 Loas/Store (AGUs) pipes when Bulldozer Integer Execution Unit has 2 integer pipes PLUS 2 AGen(Address Generator).Quote:
Originally Posted by zalbard
So we have 3 int pipes for DENEB vs 2 int pipes for each BD Integer Execution Unit.
it's 3 ALU/AGU for K10, they are general pipes. ( the third pipes give 5% more performance said by AMD ).Quote:
Originally Posted by Aten-Ra
it's 2 specialised ALU, and 2 specialised AGU. so it's more faster on integer on Bulldozer. And i think this is a more efficient disign about power comsuption.
That's early! Epic! :eek:Quote:
Originally Posted by andos
Edit: wait, it's not a release, it's a presentation. Or do I get it wrong?
ok lets all hold hands and pray for just one benchmark
How credible would we consider cebit here?Quote:
Originally Posted by andos
That's an official statement.Quote:
Originally Posted by FlawleZ
That's the official Cebit page... Pretty credible if you ask me. But unveiling does not equate launching.
if it is 50% then... it has to be BD? perhaps they will name them phenom III?Quote:
Originally Posted by informal
http://www.abload.de/img/47mob.jpg
Well, first the above slide is a little bit misleading for someone that dont knows the DENEB (Magny Cours) architecture.Quote:
Originally Posted by madcho
Secondly i believe the slide wants to show the difference of the CMP vs Bulldozers Cluster-Based Multithreading design and so the slide is not an accurate representation of Denebs (Magny Cours) Integer/fp Execution Units.
Denebs integer execution unit has 6x pipelines, 3x ALUs (Integer) and 3x AGUs (Load/Store) and the Integer Scheduler can issue 6x MicroOP (uops) to it.
Bulldozer integer execution unit has 4x pipelines, 2x ALUs (Integer) and 2x AGen(Address Generators) Plus a Load/Store unit (40 Load/24 Store) and the Integer Scheduler can issue 4 uops to it.
The DENEB don’t have FP FMACs but 3x Pipelines, FADD, FMUL,FMISC
Bulldozer FP has 4x pipelines, 2x 128-bit FMACs and 2x 128-bit MMX and one FP shared Scheduler that can issue 4x uops to the FP execution unit.
lol isnt the MC pic supposed to be of bobcat?
No more Phenom, no more Athlon. Probably it will be simply called AMD FX.Quote:
Originally Posted by god_43
i think your mixing up one major thingQuote:
Originally Posted by Aten-Ra
deneb has 3x pipelines, but they can do EITHER, NOT BOTH at the same time.
so 2 alu and 1 alg
or 3 alg and 0 alu
but not 3 and 3 at the same time
BD is always going to do 2 alg and 2 alu per core
First of don't like the design nor do I trust the bold assumption/statement made for bulldozer here (perhaps, just have to see myself as currently still consider AMD making same mistake than Intel). Also, I think HT calculation is a bit inaccurate considering ratio is closer to 165% not 118% (and not by being intel fanboy just been testing a lot of their cores), but even this 165% sucks as it's never stable for general application code for real cores. I wonder what would similar application pressure do to AMD bulldozer like server database pressure against high clock would it uberly fail like Intel's HT or still calculate correctly.
What ever happened to 'real cores' only strategy.
"Real cores" still exist. Instead of using up die space for real cores, AMD has managed to almost achieve the performance of two real cores by using shared resources. Think about it. You can achieve 85 to 90% performance of two real cores with 1 module but you're reducing logic die space, heat and power consumption. All good IMHO. :clap:Quote:
Originally Posted by genetix
I do understand this. I just prefer solid real cores only no matter would the "virtualized" cores do clean 200% that only means so could the actual module/core. Makes big decesion when we talk about real cores if it comes up to 4 modules or clean 8 core XEON you can be pretty sure it ain't gonna be modules :)Quote:
Originally Posted by freeloader
but that's an bad example I am just saying I dislike the idea how current architectures are build.
Just a reminder -- the CPU does not schedule, the OS does. Questions about how threads are distributed should be investigated at the OS level. I.e. How much has AMD worked with MS to understand the most effective, efficient scheduling?Quote:
Originally Posted by informal
I think JF once said they are collaborating with MS on how BD thread scheduling will be handled per AMD's own suggestions(since they should know best as day designed the thing :) ).
Yep. Wouldn't surprise me. Regardless if it is SMT or CMT, there is an asymmetric distribution of resources between two shared vs two physically different cores (or modules to retain the same level of meaning).Quote:
Originally Posted by informal
Best performance would to distribute over module first then pair up. I am certain this is being comprehended within the OS for BD.
Yes my bad, Deneb has 3 pipesQuote:
Originally Posted by Manicdan