Only if they can somehow force OEMs to use dual-channel memory, even at the slowest speed...
LPDDR4 would be a nice bet too.
Sent from my iPhone using Tapatalk
I completely understand you but this looks better than all of AMD comparatives in the past few years.
What about before the core line ? Intel was a mess failing to deliever for years but AMD was right on track. We could see AMD get on track again.
For me , I don't need an intergrated gpu on my gaming pc. So the fact that intel wastes space with that instead of adding more cpu cores is a reason that AMD may get my money. If its similar single thread performance (even 10% or so difference) but I get twice the physical cores at the same price or less .... Yes please .
On mobile intel's gpus suck so again if I get 10% single thread performance and the same or more cores + a better gpu then yes please.
A surface pro with a quad core zen and a gpu capable of playing the latest games at 720p + ... yes please !
I think it's reasonable to assume that for this demo, AMD chose an application that was rather favorable to Zen. In practice I would expect that, on average, Zen would have a measurable IPC deficit against Broadwell, and a slightly larger one against Skylake/Kaby Lake. Additionally, I doubt AMD will be able to match Intel's clock speeds.
As a reminder, the i7 6700K hits 4.0GHz with a turbo clock of 4.2GHz. Let's say Kaby Lake only brings that up to 4.1GHz and 4.3GHz.
Let's also assume (wild-ass, somewhat optimistic guesses, but that's the best we can do for now) that on average, Zen has a bit over 80% of Broadwell's IPC, so maybe 80% of Kaby Lake's, rounding things a bit. Let's also assume that commercial Zen CPUs will be clocked at 3.4GHz with a turbo clock of 3.7GHz.
Single-threaded performance, relative to Kaby Lake's: 80% × 3.6/4.3 = 0.69 = 69%.
Multi-threaded performance, relative to Kaby Lake's: 80% × 3.4/4.1 × 2 = 1.33 = 133%, assuming ideal scaling and 8 cores vs. 4.
If AMD can pull this off, their competitive position will be considerably improved, since they're currently hopelessly outmatched regardless of the number of threads, but I would be (very pleasantly) shocked if Zen managed to come within 10% of Kaby Lake's single-threaded performance. Still, it's a brand new architecture, so we can also reasonably expect that there's more low-hanging fruit in Zen than Kaby Lake, therefore that AMD will manage relatively larger incremental performance improvements for the next few years, potentially narrowing the gap a bit.
You cant compare Bulldozer with Zen, they are 2 completely different architectures. BZ were a good concept but a horrible implementation, it was so bad that AMD desired to throw in the trash the whole architecture and start a new one. Just for reference, BZ needed to start at 5GHz to be competitive against Intel, of course AMD couldn't get enough money to make it happen and we all know how they ended.
I think that if we have ES running at 3GHz about 6 months before its realize is a very good sign. I don't know if they would be able to get to the 4Ghz but their level of performance its pretty good still. One thing to notice is that AMD said they are not matching TDP for TDP so spec AMD chip to consume more, how much? we will have to find out.
To me the more interesting thing is to see how well and how long it will take Intel to react to this, since they have been giving the minor evolution in their designs in order to save money so now they will have to respond to AMD or they could be in serious trouble in 1 or 2 years. CPU race looks interesting once more. Lets hope this time it last.
I think that if we have ES running at 3GHz about 6 months before its realize is a very good sign. I don't know if they would be able to get to the 4Ghz but their level of performance its pretty good still. One thing to notice is that AMD said they are not matching TDP for TDP so spec AMD chip to consume more, how much? we will have to find out.
To me the more interesting thing is to see how well and how long it will take Intel to react to this, since they have been giving the minor evolution in their designs in order to save money so now they will have to respond to AMD or they could be in serious trouble in 1 or 2 years. CPU race looks interesting once more. Lets hope this time it last.
Yeah but Bulldozer/Piledriver was designed specifically for it (and even so, fell short). It also ran on a process that was tuned for high clock speeds. At 28nm, Steamroller is clocked lower. At 28nm with high-density libraries (HDL), Excavator is clocked lower still.
Since HDL are as much about power efficiency (at moderate clock speeds) as they are about density, and since Zen is supposed to replace both Excavator and Puma, I fully expect AMD to keep using them at 14nm. Further, this 14nm process is not tuned for high clock speeds, it's a generic process aimed at SoCs for handheld devices, mobile CPUs/APUs, GPUs, etc.
I certainly hope I'm wrong, but I don't see AMD hitting 4GHz with Zen, at least not initially.
Not exactly. At least for the integer pipeline, it is built on the concept that multi threading is enough to outpace the potential loss caused by sharing "non-critical" resources. It did deliver in this regard (better scaling than SMT), but the scaling base was too low that it was backwards from K10. Then when they want to scale the single thread performance, they might have hit a point of standalone cores with SMT making better sense, e.g. trying to scale your decoder to more than 4 ways, etc.
Or maybe they just want to play safe.
IMO the sharing of the "FP" unit (mind you, it runs packed integer too) should be considered separately. I would say the race of multithreading with "good single thread performance" probably had driven this sharing for higher area efficiency and lower cost, just that it turns out to be hurting too.
Sharing the FP/vector unit (or anything) between two cores has a cost (syncronization, latency and distance). Dedicated FP/vector unit can be powered down when there are idle periods. It costs a bit more area, but is way more power efficient. Similar trend can be seen on GPUs (esp Nvidia).
AVX-512 has native support for both scatter and gather. It has also lane masks. It was very hard to automatically compile loops to SSE/AVX(1&2), because scatter, gather and lane masking was not supported. Only simple loops with no index/pointer data reads/writes were supported. AVX-512 makes autovectorization much more simple and more efficient. It also allows efficient execution of simpler SPMD-style programming models instead of writing machine intrinsics. Instruction sets must evolve to make programmer's life easier. AVX-512 is a great example of this. It's not super relevant today, but as compilers will evolve, it will become more important also for this segment.
TSX is another great extension. TSX makes shared data structures (such as memory allocators) possible with no need of any locking (CPU tags cache lines to transactions and supports roll back). In many cases this provides nice performance boosts. There is still no proof that Zen supports TSX. The forthcoming Skylake Xeons will.
I agree with you that 8 core Zen will sell like hot cakes if it compares favorably in perf/watt to Intel's dense power optimized 8 core Xeon D (designed to match Facebook's needs). Limited clock ceiling doesn't matter in this segment as Xeon D is running at 2.1 Ghz.
Google is investing heavily in algorithm design. I have experimented with some of their open source code. They certainly do embrace vector instructions, even the newest ones. One example of AVX-2 usage: https://github.com/google/highwayhash.
Last edited:
ARM Scalable Vector Extensions (SVE) announced today. Up to 2048 bit vector width. Target = HPC and data centers. Good to see AVX-512 getting some competition. Now both ARM and x86 have wide vector support.
http://www.anandtech.com/show/10586...tor-extensions-aiming-for-hpc-and-data-center
Last edited:
itsmydamnation
Veteran
Yes i am aware of the improvements from scatter, gather. What i dont think you high end engine/gfx people understand is just what enterprise applications look like, for example what instruction sets does MS exchange, AD, objective, Trim, HP CSA, the farms of Zen app or Zen desktop etc etc let alone the in house app's or the sea of just rubbish enterprise apps. They are horrible coded loops in loops with conditions, jumps etc everywhere let alone using an SIMD instruction set. Let's not even pretend that the average code monkey working on the average code base well threaded etc.
So AMD might have something, we will probably know in a day or two as core counts grow you would expect them to have something, with the follow on to Zen rumored to be 48 cores . But every *aaS, Vmware farm etc is full of guests with low core counts, it makes up the very fast majority of server farms and cloud instances ( out side big DB). With things like Docker you dont run bigger VM's you just spin up more.
i think across the board from 8 to 32 cores its looking pretty good, we have people with access to hardware in this thread saying so
.itsmydamnation
Veteran
https://www.computerbase.de/2016-08/amd-zen-architektur/
slides inside, nothing about tsx, but there isn't a lot of specific detail either.......
slides inside, nothing about tsx, but there isn't a lot of specific detail either.......
Similar threads
