AMD CPUs, SoC Rumors and Speculations Temp. thread 2

Page 50 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
@juan that price point on octa core Zen sounds plausible. Probably with harvested 6 core parts targeting the to end quad core i7s in pricing. My guess is Zen won't be cheap per se, but still represent good value compared to equivalent Intel. I also see your point on quad core variants being based on the apu die.

@jdwii, as Zen features a form of smt, an 8 core Zen would already be 16 threads. I doubt there would be much demand for more than that on desktop currently so I'd guess this generation a 16 core / 32 thread part is unlikely.

 


The top models are obviously Opterons, but yeah, this focus on going wide again is a bit worrying, given BD's performance limitations.
 


Well wide for the server side makes sense (Intel already offering 18 cores / 36 threads after all, the monster 32 core was rumoured to be an multi chip design so largest single zen core would likely be 16 / 32 thread i.e. similar to Intel).

As for the desktop, we haven't really heard much from AMD on core counts so this is all speculation. I expect zen will have 4, 6 and 8 core (8, 12 and 16 thread respectively) parts available once the full line is released. They'll undoubtably have dual core / quad thread APU parts further down the line based on Zen to slot in against the i3s.
 


AM4 is limited to 8 cores and 16 threads. The possibility OEMs release the server socket for consumer desktop is, in my opinion, very small.
 


Hum, no sure what you mean by "going wide again is a bit worrying".

Intel Broadwell-E for desktop --> 10 cores / 20 threads
AMD Zen for desktop --> 8 cores / 16 threads

Intel Broadwell-EP for server --> 28 cores / 56 threads
AMD Zen for server --> 32 cores / 64 threads
 

Its 90% beyond me but I read others commenting elsewhere and it suggests zen will have uop cache similar to SB, amd term l0 cache. Interesting, Im waiting for others analysis.

 


That info just gives more details about how AMD engineers plan to obtain that 40% IPC gain. About the uop cache, well it was expected... at least by some of us.

In fact, I was talking about uop cache on Zen a pair of weeks before Desdrenboy leaked that. I mentioned the uop cache as example of why I use the issue-wide to characterize the wide of Zen microarchitecture instead using decoder wide as Desdrenboy uses: decoder-wide is useless (and misleading) when execution units are being feed from the uop cache:

https://semiaccurate.com/forums/showpost.php?p=255047&postcount=2050

On the speculative diagram about Zen there is another part where Desdrenboy and me disagree. He claims separate integer and memory schedulers, I claim Zen will bring an unified scheduler. He uses jaguar as baseline for his speculation and I use Cyclone as baseline for mine.
 


In a rapid scan, it seems an accurate description, except by two factors: (i) the claim of "four floating point units", without noticing those are not full units (two of them only can do additions and the other two only can do multiplications), therefore it is better to claim Zen has two (full) FP units of 128bit wide if we want to compare it with other microarchitectures and (ii) the reproduction of one of the old leaked slides that were showed to be fake

http://juanrga.com/en/the-fake-zen-slides.html

In fact the Zen core diagram showed in the tech4gizmos page shows inexistent 256bit FMAC units.
 
Some Stoney Ridge comparisons with other low end CPUs.

http://wccftech.com/amds-stoney-ridge-performance-market-positioning-detailed/

Not too exciting but they should be really cheap dual-cores.
 


uop cache is interesting...

Transactional memory would be interesting as well...if they pull that off successfully...it would be game changing.

They recommend turning off software prefetch. That either means a big hike in branch prediction performance expectations...or some huge issue elsewhere with software prefetch. I expect that the recover point they are implementing might be a portion of this logic.

I still see victim cache references here...though I wonder if those are still references for BD/PD/SR/EX, since my understanding is that Zen is using a different method of cache than Victim.
 


Not really when Intel already has Transactional Memory. Would benefit AMD for sure.
 
On Haswell and Broadwell yes but I have not seen anything about it in Skylake or if they have published a fix.

As well I was just saying it is not a feature that would be beneficial if Intel also has it. Beneficial would be a feature that only they have that would increase performance such as a new version of SSE or AVX that Intel might not have.

Problem is that AMD has not really implemented any instruction sets that Intel has not already done and that might be due to the fact that they have very little for R&D. Maybe Zen will bring them back to where they can introduce instructions that can benefit them before Intel has them.
 
I don't think they will gain anything from implementing extensions that Intel doesn't because Intel controls the market, it would be a waste of effort. FMA4 being pretty much just that, probably never will be used even though it has some advantages to FMA3.
 


If AMD has working transactional memory...then it will be game changing.

Intel has claimed to have that for some time...however...they still cannot figure it out...to my knowledge it is not addressed in skylake either.
 


Past year, AMD's Papermaster admitted that Zen will not caught Intel on performance, but will put AMD in "comfort zone". This year Lisa Su admitted that Zen performance targets the 80% on the server market. This would really stop the unending "faster than Skylake", "game changer", "the new K8",... kind of hype.
 


Are we still going on about that? Do I REALLY have to repeat the same performance arguments I made over a year ago?
 


Everything I have found shows it is disabled on Haswell and Broadwell but nothing on Skylake.

Intel has it working but there is a erratum that they have yet to get completely worked out.

My point is only that if AMD gets it working I highly doubt Intel would not be able to get it working as well considering the massive difference in budget for R&D there is between the two.
 
Transactional Memory isn't going to give a performance boost for most workloads anyway; if anything, I'd expect a performance loss in games. Reasons are exactly the same as they were when we last discussed this over a year ago.
 


Servers is where they are going to make their money...and that is a best case for transactional memory.
 


If they have the necessary branch prediction to make it work, sure. Transactional Memory incurs a heavy penalty (2x) for missed branch predictions, and Intel has led AMD in that department for some time.
 
Status
Not open for further replies.