hmm, what about mixed cores a la big.LITTLE?
2 SR big cores [1 module]
4 bobcat cores
512 gpu style cores
+
opencl and boom!
single threaded perf and multithreaded perf in one package the size of richland
Yeah, that's the point anyway -- it's about games, not synthetics. Your chart is pretty much a worst case scenario.Assuming AMD's memory controller has improved.
Not seeing the scaling. At most in toms review is around 22% in games.
I'm fairly confident that it works the opposite of what you're suggesting. A more efficient memory controller would make there less of a need for higher bandwidth memory. It'd scale better, but you'd solve your bandwidth problem more quickly, and therefore wouldn't see any real world improvement.I was gonna say, isn't that an issue with AMD's current memory controller? While DDR3-2133 may provide a significant amount of bandwidth over DDR3-1600, AMD's memory controller isn't efficient enough to effectively use all of it; something Intel doesn't have as much of a problem with.
That's what been theorized. It's not making it in with Steamroller, however the issue "has been isolated," according to Anand. There wasn't any mention as to when AMD plans to do a rehaul, but given the timing of things, Excavator makes the most sense. Excavator will show up with DDR4, which would be the perfect time to do a re-plumbing since you're already tearing up the asphalt, so to speak.Isn't it scheduled for a redesign come Excavator?
In regards to Piledriver, it's actually pretty damn terrible, given the thread count. This is why AMD is focusing so much on the front end in Steamroller.Like inf64 said, maybe Excavator will bring up the single threaded performance up and even current PileDriver multi threaded performance isn't that bad.
That slide is from Mediatek. Not from AMD.
Should have looked at the Source I posted.
http://new.livestream.com/toms-live/events/2542914
Anyways, I am curious as to why AMD is using watermarked slides at their conference..??
.
In regards to Piledriver, it's actually pretty damn terrible, given the thread count. This is why AMD is focusing so much on the front end in Steamroller.
Meditek is apart of the HSA alliance
Mediatek is their partner in HSA foundation (my guess).
Should have looked at the Source I posted.
http://new.livestream.com/toms-live/events/2542914
Anyways, I am curious as to why AMD is using Meditek watermarked slides at their conference..??
It's describing mediatek/ARM products.. Just like the other slides talking about mobile products.
The scaling is quite poor, relative to the die space committed to the second thread. The uplift is better than hyperthreading, however the die space penalty is far more substantial -- an additional integer execution unit and LSU, among other things. Hyperthreading is a more efficient use of transistors than the CMT implementation seen in Bulldozer and Piledriver.Are you talking about Piledriver multi threaded..??
Because it is in no way terrible
The scaling is quite poor, relative to the die space committed to the second thread. The uplift is better than hyperthreading, however the die space penalty is far more substantial -- an additional integer execution unit and LSU, among other things. Hyperthreading is a more efficient use of transistors than the CMT implementation seen in Bulldozer and Piledriver.
Excavator core seems to be going after just that, building up the individual core
(...)
But if Ex. core comes at ~90% of Haswell's IPC , or roughly at IB+ territory, it won't mater if Skylake will be +10 or so % more than Haswell
With HSA wonder if it would be possible for hybrid crossfire where the iGP shares the GDDR5 memory on the discrete GPU...
hmm, what about mixed cores a la big.LITTLE?
2 SR big cores [1 module]
4 bobcat cores
512 gpu style cores
+
opencl and boom!
single threaded perf and multithreaded perf in one package the size of richland
The Scaling actually is quite good, much higher than Intel's SMT. You spend more logic (die space) for higher scaling. Simple as that.
A single 32nm PileDriver Module at 4GHz is equal in performance with a 32nm SandyBridge Core (+HT). Also, those two are almost the same die size.
Here we have almost the same performance by using two different micro architectures at the same litho process.
hmm, what about mixed cores a la big.LITTLE?
2 SR big cores [1 module]
4 bobcat cores
512 gpu style cores
+
opencl and boom!
single threaded perf and multithreaded perf in one package the size of richland
That would only mean Intels diespace is much more efficient used. And again show the weakness of AMDs CMT, due to the scaling issue. AMDs CMT only works in very high scaling multithreaded cases without demanding main threads. In short, you get all the good with Intels SMT without being penalized, unlike AMDs CMT solution that depends on very high scaling to yield the same efficiency. It also explains why AMD is slowly moving away from CMT one step at a time.
AMD competition on the bottom market isn't 240mm^2 CPUs like they are selling today, but the 120mm^2 and the sub 100mm^2 Silvermont CPUs. If anything the only thing that would "boom" is AMD margins with this chip, because they would need extra everything in order to support the extra small cores on the already big APU die.
Silvermont and Kaveri in competition? Please! Jaguar and Silvermont are the competitors in the craptop market.
But I agree, adding these little cores to a big core die makes little sense. They'd be better off widening the resources in a module, and having SMT+CMT (4 threads per module).
I would say that AMD CMT does not work at all. It's misleading to compare core per core, because all the support infrastructure that the core needs to work just isn't there. 32nm Sandy Bridge without the CPU part is 30% smaller than the CPU part of a 32nm APU. And it's not blank space, is transistor budget that consumes power even when only leaking, making the design a lot less efficient than Intel's.
In servers we can see how CMT designs scale badly, because once AMD tried to go over 4 modules they could achieve only paltry clocks, while Intel could get much higher clocks of their big die parts. While here on the forums people are claiming for 8 core Steamroller, Intel has 12 core/24 threads parts that would mop the floor with AMD chips in whatever multithreaded task you can think of, and even the 8C parts would be enough to hold the line against whatever AMD throws at them. AMD can only look for the poor scaling of their designs to blame for their server debacle.
And speaking about sharing... SMT is about sharing *all* resources of the core, while CMT is about sharing just a few of the resources. Intel (and IBM, and Sun, and everyone with SMT) can go huge on core resources and IPC because the resources will be used by more than one thread at a given time, while AMD cannot, because if they go huge on core resources it might end up with only added leakage while the core sits still for lack of threads. This is the reason for the anemic core (which they tried to compensate with high clocks), and this is why you cannot expect much IPC from AMD parts(I'll really save that 90% post for the posterity). CMT ends up delivering a much more inflexible processor than CMT, one that only shines when there are a lot of light threads on the fly, and sucks at everything else.
Oh, they are. Last time I noticed AMD didn't have many places to dump their single module parts.
They would be better off falling back to conventional designs like everyone else did.
Assuming AMD's memory controller has improved.
Not seeing the scaling. At most in toms review is around 22% in games.
And don't forget that Intel has a much more advanced uncore design. AMD are just hanging more and more modules off a crossbar, while Intel has a fast bidirectional ringbus. It's hard to know what comes down to core design, and what comes down to uncore. AMD for some reason cancelled their 10-core Terramar die, which was meant to come on a new platform, and instead doubled down on their already outdated AM3/MCM server platform. I don't know why, but I suspect that the on-chip fabric just didn't scale well enough to handle that many cores.