Execution, Load/Store, INT and FP Scheduling

The execution of micro-ops get filters into the Integer (INT) and Floating Point (FP) parts of the core, which each have different pipes and execution ports. First up is the Integer pipe which affords a 168-entry register file which forwards into four arithmetic logic units and two address generation units. This allows the core to schedule six micro-ops/cycle, and each execution port has its own 14-entry schedule queue.

The INT unit can work on two branches per cycle, but it should be noted that not all the ALUs are equal. Only two ALUs are capable of branches, one of the ALUs can perform IMUL operations (signed multiply), and only one can do CRC operations. There are other limitations as well, but broadly we are told that the ALUs are symmetric except for a few focused operations. Exactly what operations will be disclosed closer to the launch date.

The INT pipe will keep track of branching instructions with differential checkpoints, to cut down on storing redundant data between branches (saves queue entries and power), but can also perform Move Elimination. This is where a simple mov command between two registers occurs – instead of inflicting a high energy loop around the core to physically move the single instruction, the core adjusts the pointers to the registers instead and essentially applies a new mapping table, which is a lower power operation.

Both INT and FP units have direct access to the retire queue, which is 192-entry and can retire 8 instructions per cycle. In some previous x86 CPU designs, the retire unit was a limiting factor for extracting peak performance, and so having it retire quicker than dispatch should keep the queue relatively empty and not near the limit.

The Load/Store Units are accessible from both AGUs simultaneously, and will support 72 out-of-order loads. Overall, as mentioned before, the core can perform two 16B loads (2x128-bit) and one 16B store per cycle, with the latter relying on a 44-entry Store queue. The TLB buffer for the L2 cache for already decoded addresses is two level here, with the L1 TLB supporting 64-entry at all page sizes and the L2 TLB going for 1.5K-entry with no 1G pages. The TLB and data pipes are split in this design, which relies on tags to determine if the data is in the cache or to start the data prefetch earlier in the pipeline.

The data cache here also has direct access to the main L2 cache at 32 Bytes/cycle, with the 512 KB 8-way L2 cache being private to the core and inclusive. When data resides back in L1 it can be processed back to either the INT or the FP pipes as required.

Moving onto the floating point part of the core, and the first thing to notice is that there are two scheduling queues here. These are listed as ‘schedulable’ and ‘non-schedulable’ queues with lower power operation when certain micro-ops are in play, but also allows the backup queue to sort out parts of the dispatch in advance via the LDCVT. The register file is 160 entry, with direct FP to INT transfers as required, as well as supporting accelerated recovery on flushes (when data is written to a cache further back in the hierarchy to make room).

The FP Unit uses four pipes rather than three on Excavator, and we are told that the latency in Zen is reduced as well for operations (though more information on this will come at a later date). We have two MUL and two ADD in the FP unit, capable of joining to form two 128-bit FMACs, but not one 256-bit AVX. In order to do AVX, the unit will split the operations accordingly. On the counter side each core will have 2 AES units for cryptography as well as decode support for SSE, AVX1/2, SHA and legacy mmx/x87 compliant code.

Fetch and Decode The Core Complex, Caches, and Fabric
Comments Locked

574 Comments

View All Comments

  • lakerssuperman - Thursday, March 2, 2017 - link

    People like me. I was previously running a 2600k overclocked. Nice chip. Still runs great, but I was looking for an upgrade about a year ago as one of the things I do a lot of is Handbrake conversion for my HTPC. Going to even the newest Intel 4 core got me maybe 20% improvement on one of my major workloads for insane amounts of money and going to the high end to get 8-10 cores was just not justifiable.

    I ended up buying a used Xeon/X79 motherboard combo for around $300 off ebay. 8 cores/16 threads and it works great for Handbrake. I lost some clock speed in the move so single thread performance took a bit of a hit, but was more than made up for in multi-thread performance. I can still game on this CPU just fine and I don't play the newest stuff right away anyway just because of time constraints.

    The X79 platform is fine for what I'm doing with it. Would I like the new stuff? Sure. And if I was in the position I was last year looking for an upgrade I don't see how I wouldn't get an 1800x. It gives me the right balance of features for what I do with my computer.

    If I was just gaming, I'd look at Intel currently because their 4 core i5 is the sweet spot for this. But I'm not just gaming so this chip is infinitely more attractive to someone like me. With the price and features I can't see how it isn't a winner and when the 4 and 6 core parts come out at likely higher frequencies, I think they are going to be the real winners for gaming.
  • rarson - Thursday, March 2, 2017 - link

    Ryzen is clearly well-suited to anyone who values high performance in a multitude of usage scenarios over one single usage scenario, especially if one cares about how much money they need to spend to achieve those results.
  • injurer - Friday, March 3, 2017 - link

    1800X is definitely designed for enthusiast, and AMD fans, but when you go to 1700X this is a price killer targeting the mainstream. 1700 is on the same boat but at even lower price. All the 3 are 8 core chips and are quite close to the 6900K but at 2-4 times lower price.

    At the end I really believe AMD are still having to show us the real potential of their architecture. Those chips are just the start. Remember Ryzen design is a new from its core, so they definitely have room to ecpand and enhance it.
  • bill.rookard - Thursday, March 2, 2017 - link

    Well, thing to remember is that for those looking for a new build, they now have a legitimate choice. I still do see in the future that things will only go more multithreaded, and even though the i7-7700k is still a great chip, having more physical cores and resources to throw at it will only help.

    To that end, again, anyone planning a NEW build from the ground up will be able to seriously consider a Ryzen system.

    Worst case, think about it. In the deep dive they had mention of 'competitive resource sharing' with SMT enabled. If you were to disable SMT on Ryzen - it would give you 8 PHYSICAL cores versus the 4 physical/4 logical cores of the 7700k. Without those resources being partially used across 16 threads - all resources would be allocated to the physical cores instead, potentially allowing more processing power per physical core.

    There's still quite a bit to be checked out and dug through.
  • lilmoe - Thursday, March 2, 2017 - link

    This. I want 2 things dug deeper in follow ups:
    1) Single/multi threaded performance with SMT disabled VS SMT enabled.
    2) Game comparisons with more sensible GPUs (which actually ship and sell in volume, IE: the ones people actually buy), like the GTX 1060 and/or RX 480.
  • BurntMyBacon - Friday, March 3, 2017 - link

    @lilmoe

    I agree with 1). Intel had HT for several generations before it was universally better to leave it enabled (still needs to be disabled some times, but these are more the edge cases now).

    Not so sure I'm onboard with 2). Pairing a $200 GPU with a $500 processor for gaming purposes seems a little backwards. I'd like to see that (GTX1060 / RX480) gaming comparison on a higher clocked R5 or R3 processor when they are released.
  • Meteor2 - Friday, March 3, 2017 - link

    I'd rather see tests paired with a 1080 Ti. At RX480/1060 level, it's well known the bottleneck is GPU performance not CPU. A 1080 Ti should be fast enough to show up the CPU.
  • lilmoe - Friday, March 3, 2017 - link

    @BurntMyBacon @Meteor2

    Lots of people, like me, are more into CPU power. I'm OK with a mid-range GPU. Gaming is not my top priority, and when I do, It's never above 1080p.

    It'd be interesting to see if there are differences. I wouldn't dismiss it, saying the GPU would be the bottleneck so fast.
  • bigboxes - Sunday, March 5, 2017 - link

    I'm with you on that. Gaming is way down in my priority list. I do it occasionally just because I love to see what my hardware can do. I currently have a ultrawide 1080p monitor. When I move to 4K then hopefully midrange GPU will cover that. My CPU is a 4790K. It's great for most tasks. I've been wanting to go to 6/8 core for some time, but the cost for the platform was too high. I think in a couple of years I will seriously think about Ryzen when building a new workstation.
  • rarson - Thursday, March 2, 2017 - link

    I am interested in seeing potential improvement due to BIOS updates. Additionally, I'm interested in seeing potential improvement due to better multi-threaded software. My hunch is that AMD is either on-par or better than Intel, or maybe damn near that prediction, so I think the 4-core parts will compare well to the current Skylake SKUs. I also expect them to overclock better than the 8-core chips. I guess we'll just have to wait for them to release.

    8 physical cores is definitely better than 4 cores with SMT/HTT/whatever you want to call it.

Log in

Don't have an account? Sign up now