[Techpowerup] AMD "Zen" CPU Prototypes Tested, "Meet all Expectations"

[erunion]

Abwx,
I see you were utterly defeated on Semi-Accurate by the Internet STRONGMAN, Juanrga. :biggrin:

I'm convinced juanrga is stuck in a feedback loop but doesnt realize it.
Several times he's made speculation about zen and within a few days that same information appears on one of the several copy-paste tech news site.
Rather than realizing those sites are just plagiarizing his forum posts, he believes independent sources are providing the same info. Thus he believes he's on the right track.

 

[TechGod123]

I'm convinced juanrga is stuck in a feedback loop but doesnt realize it.
Several times he's made speculation about zen and within a few days that same information appears on one of the several copy-paste tech news site.
Rather than realizing those sites are just plagiarizing his forum posts, he believes independent sources are providing the same info. Thus he believes he's on the right track.

This is funny.

 

[looncraz]

You appear to have no idea what it costs to add a new execution unit. The cost isn't die area (ALUs take minimal area on modern chips), but clock speed. The clock speed of chips is limited by the longest path, both in transistors that need to switch and wire distance that needs to be crossed, that has to be traversable in a single clock cycle. This longest path is almost invariably found in the forwarding network that shuffles results from one execution unit to another. Adding more execution units is very easy, but it also directly reduces the maximum clock speed of your chip.

If you are stuck on the same process, yes, that's true. But Intel hasn't exactly been stuck on 45nm. They are on 14nm.

Intel has been adding very little to the performance since Penryn:

http://files.looncraz.net/intel_ipc_claimsvbench.jpg

Of course, AMD went the other way

 

[CHADBOGA]

I'm convinced juanrga is stuck in a feedback loop but doesnt realize it.
Several times he's made speculation about zen and within a few days that same information appears on one of the several copy-paste tech news site.
Rather than realizing those sites are just plagiarizing his forum posts, he believes independent sources are providing the same info. Thus he believes he's on the right track.

LOL

I have invited him to these forums, but so far he hasn't taken up the invitation. :biggrin:

 

[NostaSeronx]

Would be more beliavable if you said their fixed their construction cores finding better cache implementations.

Well from what I gathered these are the changes;

'New' 2-Level Branch Predictor;
L2 BP -> Predicts branches that hit both cores.
L1 BP -> Predicts branches that hit a single core.

'New' L1 Instruction Cache;
- Dual-ported
- More associativity
x Possible larger size

'New' Fetch/Decode;
- A 32B/2 fetch unit per core. (32B/2 -> 32B every other cycle)
- 2 * small Decode + 2 * big Decode unit per core. (Small -> 1x AMD64 or 128-bit FPU macro-op // Big -> 1x AMD64 or 128-bit FPU or 256-bit FPU macro-op)

'New' IEU/LSU arrangement;
- 2 LD AGLUs // 1 PipelinedMul/Load AGLU - 1 PipelinedDiv/Load AGLU
- 2 LD/ST AGLUs // 1 Branch/LD/ST AGLU - 1 POPCNT/LD/ST AGLU
- Eqv to 4 ALUs + 4 AGUs

'New" L1D Cache;
- Quadported
- 2 Load ports
- 2 Load or Store ports

'New' FPU arrangement;
- p2 is fused into p1
- p0/p1 have been increased from 128-bit width to 256-bit width

L2 Cache / L2 Interface changes;
- No more 4KB WCB // Don't really know -> 512KB L2_0/512KB L2_1, Crossbar, Shifters, bleh.

The core name for the 22FDSOI version is "Harvester", the 14FF version is "Crane".

 

[looncraz]

I'm convinced juanrga is stuck in a feedback loop but doesnt realize it.
Several times he's made speculation about zen and within a few days that same information appears on one of the several copy-paste tech news site.
Rather than realizing those sites are just plagiarizing his forum posts, he believes independent sources are providing the same info. Thus he believes he's on the right track.

He's stuck, that's for sure. An entire forum trying to explain to him that the AGU:ALU ratio, by itself, means almost nothing for CPU performance and he just keeps saying they don't understand, it's about the ratio, not how many there are... I've been in arguments with him before, there's only one way to handle him... which is to search for the "Ignore" option :thumbsup:

I just wish SemiAccurate had open forums, I'd love to get in on that conversation (what can I say, 'm a glutton for punishment :twisted.

 

[looncraz]

Well from what I gathered these are the changes;

'New' 2-Level Branch Predictor;
L2 BP -> Predicts branches that hit both cores.
L1 BP -> Predicts branches that hit a single core.

'New' L1 Instruction Cache;
- Dual-ported
- More associativity
x Possible larger size

'New' Fetch/Decode;
- A 32B/2 fetch unit per core. (32B/2 -> 32B every other cycle)
- 2 * small Decode + 2 * big Decode unit per core. (Small -> 1x AMD64 or 128-bit FPU macro-op // Big -> 1x AMD64 or 128-bit FPU or 256-bit FPU macro-op)

'New' IEU/LSU arrangement;
- 2 LD AGLUs // 1 PipelinedMul/Load AGLU - 1 PipelinedDiv/Load AGLU
- 2 LD/ST AGLUs // 1 Branch/LD/ST AGLU - 1 POPCNT/LD/ST AGLU
- Eqv to 4 ALUs + 4 AGUs

'New" L1D Cache;
- Quadported
- 2 Load ports
- 2 Load or Store ports

'New' FPU arrangement;
- p2 is fused into p1
- p0/p1 have been increased from 128-bit width to 256-bit width

L2 Cache / L2 Interface changes;
- No more 4KB WCB // Don't really know -> 512KB L2_0/512KB L2_1, Crossbar, Shifters, bleh.

The core name for the 22FDSOI version is "Harvester", the 14FF version is "Crane".

This would be quite interesting. Not so sure about predicting branches across cores - it seems these should be largely unrelated as branches exist in single threads of execution. The new FPU arrangement would also seem to be a regression, performance wise, though may well save power. Same with the decoder arrangements.

This could make sense for a small, low clocked, CMT design, though. Losing the write coalescing cache (what you call WCB?) would certainly be a problem with permanently segmenting the L2. Smaller should mean lower latency, which would certainly help.

The question is, are you just making this up for kicks, or do you have a valid reason to believe this to be the case

 

[LTC8K6]

If you are stuck on the same process, yes, that's true. But Intel hasn't exactly been stuck on 45nm. They are on 14nm.

Intel has been adding very little to the performance since Penryn:

http://files.looncraz.net/intel_ipc_claimsvbench.jpg

Which suggests that it is actually not too easy to get a large performance gain?

 

[TechGod123]

Well from what I gathered these are the changes;

'New' 2-Level Branch Predictor;
L2 BP -> Predicts branches that hit both cores.
L1 BP -> Predicts branches that hit a single core.

'New' L1 Instruction Cache;
- Dual-ported
- More associativity
x Possible larger size

'New' Fetch/Decode;
- A 32B/2 fetch unit per core. (32B/2 -> 32B every other cycle)
- 2 * small Decode + 2 * big Decode unit per core. (Small -> 1x AMD64 or 128-bit FPU macro-op // Big -> 1x AMD64 or 128-bit FPU or 256-bit FPU macro-op)

'New' IEU/LSU arrangement;
- 2 LD AGLUs // 1 PipelinedMul/Load AGLU - 1 PipelinedDiv/Load AGLU
- 2 LD/ST AGLUs // 1 Branch/LD/ST AGLU - 1 POPCNT/LD/ST AGLU
- Eqv to 4 ALUs + 4 AGUs

'New" L1D Cache;
- Quadported
- 2 Load ports
- 2 Load or Store ports

'New' FPU arrangement;
- p2 is fused into p1
- p0/p1 have been increased from 128-bit width to 256-bit width

L2 Cache / L2 Interface changes;
- No more 4KB WCB // Don't really know -> 512KB L2_0/512KB L2_1, Crossbar, Shifters, bleh.

The core name for the 22FDSOI version is "Harvester", the 14FF version is "Crane".

Source?

 

[NostaSeronx]

Do you have a valid reason to believe this to be the case

AMD Boston has all the eggs.

- The Cache-Coherent Data Fabric based on Hypertransport.
- The second GPU team which development followed Gustafson and Larrabee.
- Offloading of the Bulldozer team as well.

So, you have a single team working on a CPU, a GPU, and a data fabric that combines CPUs and GPUs. Huh.

Then, everyone realizes Zen/K12 was a "global effort." While this was only done by AMD Boston and contractors @ an extremely low budget.

it seems these should be largely unrelated as branches exist in single threads of execution.

If both cores are operating on the same codeset, the L2 BP predicts branches. If both cores are operating on different codesets, the L1 BPs predicts branches.

 

[looncraz]

Which suggests that it is actually not too easy to get a large performance gain?

No, Intel has been doing mostly targeted improvements based on the highest paying customers. This is part of why they now have 95% of the server market (and part of why the most popular benchmarks show the biggest gains).

While it isn't a cakewalk to get more performance, Intel has had what it takes to do so at their fingertips for years.

Merging the assets of two cores to work on one thread is entirely feasible, though they will certainly need to group execution resources carefully and add an extra stage or two to keep clock rate high.

It's all about organizing what is going to be executed. In this scenario there will be two ALUs which can do multiplication and two that can do division, so you put them next to each other and give them a end-of-line scheduler. Side ports between the scheduler stages will allow non-specialized instructions to move to another ALU scheduler if a slot becomes available while specialized instructions are queued. It is, indeed, at least one more stage, but you have twice the computational resources available, so who cares?

Aside from just the lack of motivation, the valid arguments against this are power draw, scaling, and marketing. Power draw should be something that can be managed, whereas scaling will require far more work (though very traditional efforts will do the trick). Marketing, however, is an issue. This, by no means, could be called anything other than a single core. I'd call it a 4DMacroCore when using double the resources and executing four threads.

So we'd have Dual 4DMacroCore CPUs which can handle eight threads and performs like an i7 in multithreaded loads, and spanks it in single threads.

 

[LTC8K6]

No, Intel has been doing mostly targeted improvements based on the highest paying customers. This is part of why they now have 95% of the server market (and part of why the most popular benchmarks show the biggest gains).

While it isn't a cakewalk to get more performance, Intel has had what it takes to do so at their fingertips for years.

Then you are claiming that Intel can best Zen easily whenever they need to, even if Zen is faster than Skylake.

So it seems like you are basically saying Zen has no chance.

Either AMD can't get the performance up there, or if they do, Intel can easily crank out a faster chip.

 

[TechGod123]

Then you are claiming that Intel can best Zen easily whenever they need to, even if Zen is faster than Skylake.

So it seems like you are basically saying Zen has no chance.

Either AMD can't get the performance up there, or if they do, Intel can easily crank out a faster chip.

The latter may be true. But wait! That would only be true if AMD wasn't ALSO going to be releasing Zen+.

You assume AMD will stand still, don't you think they've learnt by now?

 

[Azuma Hazuki]

And where exactly are the scary catmen getting this information from? It SOUNDS interesting, especially since Harvester and Crane appear to be what Orochi always should have been, but this is completely out of left field.

 

[TechGod123]

And where exactly are the scary catmen getting this information from? It SOUNDS interesting, especially since Harvester and Crane appear to be what Orochi always should have been, but this is completely out of left field.

I have a hard time believing Zen was cancelled.

 

[TurtleCrusher]

I have a hard time believing Zen was cancelled.

This.

Quotes have been saved :sneaky:

 

[looncraz]

Then you are claiming that Intel can best Zen easily whenever they need to, even if Zen is faster than Skylake.

So it seems like you are basically saying Zen has no chance.

Either AMD can't get the performance up there, or if they do, Intel can easily crank out a faster chip.

Intel can best Zen easily and have already done so unless Zen is an astonishing success and the 40% claim was a gross under representation of the improvement over Excavator.

Zen will be Haswell +/- 10%, IPC-wise.

I had a friend who worked at Intel doing CPU microcode (he worked on Pentium 4, IIRC). He said, even then, that Intel could easily double the performance of their CPUs by doing away with a policy he called "copy exact." He said that they were not allowed to optimize existing microcode at all, they could only add to it.

Apparently this meant there was guaranteed compatibility, but that the microcode was full of workarounds and performance issues aplenty.

This is not surprising from a corporation like Intel, they have a LOT riding on maintaining proper compatibility and they don't really have to worry about optimal performance. I have no clue if this policy still exists, or even if I fully understood what he meant, but it is a good example of the type of thing that can happen in Intel that could never happen in a more vulnerable company. You don't leave a doubling of performance on the table.

If you compare the die sizes of Intel CPUs and their competition, the situation becomes rather clear. Intel is advancing on a cadence as they are exactly so they can give the appearance of progress without becoming too efficient too fast. They do NOT want the holy grail of performance, that would hurt sales immensely. Already, the "fast enough for the average Joe" computers are only being upgraded after they have a failure... many years, or even a decade or more, later.

In addition, Intel knows that they can't get too far ahead of AMD. If they were to make AMD any more irrelevant than they have, they will be facing massive legal battles in several countries - even without AMD initiating anything (since they have agreed to not do so). This is probably yet another disincentive to make genuine attempts at significant progress.

Just imagine the mainstream socket getting a 6 core CPU option without an iGPU from Intel... they won't do that, even though there is no doubt there is a significant enough market to make it profitable.

 

[Exophase]

I had a friend who worked at Intel doing CPU microcode (he worked on Pentium 4, IIRC). He said, even then, that Intel could easily double the performance of their CPUs by doing away with a policy he called "copy exact." He said that they were not allowed to optimize existing microcode at all, they could only add to it.

Apparently this meant there was guaranteed compatibility, but that the microcode was full of workarounds and performance issues aplenty.

I am very skeptical of this claim. Unless the microcode was contributing to something very, very broken there's no way any change in it would result in a 2x performance difference. Even a CPU like Pentium 4 wouldn't be spending that much time in microcode.

 

[coercitiv]

You sound like you really know your stuff, showing a technical grasp I've only ever seen from Looncraz before (and both of you have disturbing cat avatars...weird). But this is so far beyond the pale.

Nosta is a strange cat, some of us believe he's not a real cat at all: tends to post lists of technical details of upcoming architectures, has little to contribute after product launches in terms of evaluation/confirmation for said technical details.

 

[TechGod123]

This.

Quotes have been saved :sneaky:

How can it be? Its said to been on track REPEATEDLY. I find it odd how some people are so good at self delusion.

 

[DrMrLordX]

Something to pay attention to here, as well, is that Excavator is pretty much dead even with Penryn for IPC.

I'm not sure that's accurate. The_Stilt was nice enough to post some XV numbers @ 3.4 GHz (no throttle/turbo) using his dev platform, and adding 40% to his Cinebench R10 numbers would put Zen ahead of Skylake per clock (assuming the same number of cores). 8c/16t Zen would be an R10 monster. Now when you take into account that R10 is mostly an fp SSE2 benchmark, and when you take into account that much of Zen's improvements in IPC over XV will come from:

1). Faster cache
2). Presumably shorter pipeline (less performance loss from stalls)
3). additional fp resources

you will probably see improvements from Zen on the high side in a benchmark like Cinebench R10. The open question is: how high will Zen clock? Maybe not all that high (at least as a base clock), but we'll find out soon enough.

 

[Phynaz]

Intel can best Zen easily and have already done so unless Zen is an astonishing success and the 40% claim was a gross under representation of the improvement over Excavator.

Zen will be Haswell +/- 10%, IPC-wise.

I had a friend who worked at Intel doing CPU microcode (he worked on Pentium 4, IIRC). He said, even then, that Intel could easily double the performance of their CPUs by doing away with a policy he called "copy exact." He said that they were not allowed to optimize existing microcode at all, they could only add to it.

Apparently this meant there was guaranteed compatibility, but that the microcode was full of workarounds and performance issues aplenty.

This is not surprising from a corporation like Intel, they have a LOT riding on maintaining proper compatibility and they don't really have to worry about optimal performance. I have no clue if this policy still exists, or even if I fully understood what he meant, but it is a good example of the type of thing that can happen in Intel that could never happen in a more vulnerable company. You don't leave a doubling of performance on the table.

If you compare the die sizes of Intel CPUs and their competition, the situation becomes rather clear. Intel is advancing on a cadence as they are exactly so they can give the appearance of progress without becoming too efficient too fast. They do NOT want the holy grail of performance, that would hurt sales immensely. Already, the "fast enough for the average Joe" computers are only being upgraded after they have a failure... many years, or even a decade or more, later.

In addition, Intel knows that they can't get too far ahead of AMD. If they were to make AMD any more irrelevant than they have, they will be facing massive legal battles in several countries - even without AMD initiating anything (since they have agreed to not do so). This is probably yet another disincentive to make genuine attempts at significant progress.

Just imagine the mainstream socket getting a 6 core CPU option without an iGPU from Intel... they won't do that, even though there is no doubt there is a significant enough market to make it profitable.

Copy Exactly is used in manufacturing, not design. It means every line in every fab is an exact clone of every other. If an optimization is developed at one location it is rolled out to other locations. This is in contrast to other fabs that use SPM on a per line basis. The purpose is to reduce cost.

I believe I read somewhere that Intel syncs their manufacturing processes every 90 days.

Intel page.

 

[ShintaiDK]

Broadwell-E will be 3.3Ghz for 8 cores and 3Ghz for 10 cores. All at 140W.

Anyone in their right mind still believing in 4Ghz Haswell IPC 8C/16T at 95W with 14 LPP for Zen?

 

[AtenRa]

Anyone in their right mind still believing in 4Ghz Haswell IPC 8C/16T at 95W with 14 LPP for Zen?

Find me a single post that talks about 8core 16threads ZEN at 4GHz and 94W TDP.

 

[NostaSeronx]

1). Faster cache
2). Presumably shorter pipeline (less performance loss from stalls)
3). additional fp resources

1). Inclusive 8 MB L3 Cache per 4 cores. Kind of shoots down that faster cache notion.
2). BD -> XV has 15 pipeline stages for the Integer side. ZN/ZN+ has 17 pipeline stages for the Integer side.
3). The additional FP resources is negated by having MAC units rather than FMAC units. 2 128b AVX Adds + 2 128b AVX Muls or 1 128b/256b AVX Muladd.

Summit Ridge vs Cannonlake SoC
- CL atleast has an iGPU

Raven Ridge vs Cannonlake SoC
- CL has moar coars.
- CL uses MCDRAM.