• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Raptor Lake Leaks + Intel 4 developments

Perfect_Chaos said:
New platform vs a refresh. I don't know if it means anything in terms of performance but I'd be disappointed if Zen 4 wasn't a decent bump above Raptor Lake, we will see.
Click to expand...

Yeah exactly. It it doesn't beat Raptor Lake comfortably across the board, it will be a huge letdown, especially since AMD will be so late to the party with PCI-Ev5/DDR5.

If it is at least 15% faster than Raptor Lake in the majority of games, I'll be buying a Zen4 on release, assuming it's stable and reliable.
 
Gondar said:
Without v-cache, i believe Zen 4 and RPL will have similar IPC, Zen 4 is completely new architecture on new node so they can achive that 26% more IPC, and if need they can release from the start v-cache versions, it will have better yield at that time, and Zen 4 will be more optimised for vertical stacking. About ddr4 part, if Zen 4 is full ddr5 then that means memory controller don't have compromises that hybrid design have, they will work at higher ddr5 speed and offer more modes, so it isn't that bad thing. I myself have plan to upgrade to next gen platform, ddr5 is future proof so higher price at start, but it will work longer so no problem for me, i will retire ddr4.
Click to expand...
From the CES reveal with the chip running at 5ghz I think that points to no Vcache on zen 4 from the start as it adds extra complexity to the manufacturing process and will drive up costs, My guess is AMD will do a mid gen refresh with the Vcache in limited quantities similar to what we're seeing currently as a counter to meteor lake if that arrives early.
 
Joxeon said:
From the CES reveal with the chip running at 5ghz I think that points to no Vcache on zen 4 from the start as it adds extra complexity to the manufacturing process and will drive up costs, My guess is AMD will do a mid gen refresh with the Vcache in limited quantities similar to what we're seeing currently as a counter to meteor lake if that arrives early.
Click to expand...
99% sure they won't need v-cache for Raptor Lake, but good to know they can release it, and they will if needed.
 
Zen 4 will also have more regular cache, and IPC similar to Raptor Lake, but they can add v-cache easily for even more gaming performance. We saw how v-cache transformed Zen 3 into ADL killer, with 10-15% less IPC, so if Zen 4 is closer to RPL or even better in IPC then difference will be bigger.
 
I wonder if they should just delay Raptor Lake now until the 1st half of 2023, and redesign it for 7nm EUV. It really depends if these cache rumours are true, and how much they can boost the L3 cache by. But the problem with this approach, is that Intel likes to have a new CPU architecture when they move to a new fabrication technology. Switching to 7nm EUV early could dampen excitement for Intel's 14th generation (Meteor Lake).

Intel is usually quite open about new architectures, and so far, it looks like the 13th gen will use a slightly improved version of Golden Cove.
 
Armageus said:
Shock as adding more cores adds more cache
Click to expand...

Hey buddy. Best to read the article before making assumptions like this. I've got 5 minutes, so will give you a hand this time.

Raptor Lake features many things, including the following

1. New architecture (new core arcitecture for P and E cores)
2. Improved cache design
3. Additional cores

The extra cache is not simply a byproduct of the extra cores. The article describes this in depth:

Alder Lake P-Core L2: 1.25 MB for each core
Raptor Lake P-Core L2 - 2 MB for each core

Alder Lake E-Core L3 - 2 MB for each core
Raptor Lake E-Core L3 - 3 MB for each core

Alder Lake E-Core L2 - 3 MB for each core
Raptor Lake E-Core L2 - 4 MB for each core

So, more cache per core, as well as more cores, nice and simply to understand :)
 
Dave2150 said:
Hey buddy. Best to read the article before making assumptions like this. I've got 5 minutes, so will give you a hand this time.

Raptor Lake features many things, including the following

1. New architecture (new core arcitecture for P and E cores)
2. Improved cache design
3. Additional cores

The extra cache is not simply a byproduct of the extra cores. The article describes this in depth:

Alder Lake P-Core L2: 1.25 MB for each core
Raptor Lake P-Core L2 - 2 MB for each core

Alder Lake E-Core L3 - 2 MB for each core
Raptor Lake E-Core L3 - 3 MB for each core

Alder Lake E-Core L2 - 3 MB for each core
Raptor Lake E-Core L2 - 4 MB for each core

So, more cache per core, as well as more cores, nice and simply to understand :)
Click to expand...

You might want to take your own advice and read. Alder Lake cache is not as you've claimed above. Far from it in fact, but you love getting carried away...
 
Grim5 said:
the amount of cache per core has increased, it pays to actually read the article
Click to expand...
Dave2150 said:
The extra cache is not simply a byproduct of the extra cores
Click to expand...

Some of it is a byproduct of extra cores however - by going from 8 to 16 "E" cores, you add two gracemont modules, each module includes 2MB L2, 3MB L3 = an extra 10MB to start with.


Dave2150 said:
Hey buddy. Best to read the article before making assumptions like this. I've got 5 minutes, so will give you a hand this time.
Click to expand...

As above - you might want to reread - given that Neither Alderlake E Cores, or Raptor Lake E Cores have L2 or L3 "per core" - it's per module.

:)
 
Robert896r1 said:
The L2 gains are significant for more cache hits. Those will certainly help. The more exciting part is going from svid to dvlr for power delivery.
Click to expand...

Not so much if the communications have to pass between modules, or over different bus topologies with various pool sizes and speeds.
 
jigger said:
Not so much if the communications have to pass between modules, or over different bus topologies with various pool sizes and speeds.
Click to expand...

The cache "hit" would be on its locally stored L2 data store which will be 2MB per P core and 4MB shared per E core cluster on RPL. If the "communications have to pass between modules" that's already a cache miss. The whole point of the increase for cache is to get more hits vs misses thus faster performance.


inline-olrak-raptor-lake-cache-layout-diagram.png
 
Robert896r1 said:
The cache "hit" would be on its locally stored L2 data store which will be 2MB per P core and 4MB shared per E core cluster on RPL. If the "communications have to pass between modules" that's already a cache miss. The whole point of the increase for cache is to get more hits vs misses thus faster performance.


inline-olrak-raptor-lake-cache-layout-diagram.png
Click to expand...

Increasing individual cache size is a double edged sword. Look outside the local pools or flush large amounts of cached data regularly.
 
jigger said:
Increasing individual cache size is a double edged sword. Look outside the local pools or flush large amounts of cached data regularly.
Click to expand...

Until that penalty, which is mainly latency at the cache pool level, supersedes the performance gain, there's no reason not to. I seriously doubt Intel engineers are walking into that scenario. Happy to revisit this when it's out.
 
Robert896r1 said:
Until that penalty, which is mainly latency at the cache pool level, supersedes the performance gain, there's no reason not to. I seriously doubt Intel engineers are walking into that scenario. Happy to revisit this when it's out.
Click to expand...

I can see where they could make gains in low core count situations, but there is a lot of hang-ups and overheads to this type of design.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom