Question Raptor Lake - Official Thread

[Hulk]

Since we already have the first Raptor Lake leak I'm thinking it should have it's own thread.
What do we know so far?
From Anandtech's Intel Process Roadmap articles from July:

Built on Intel 7 with upgraded FinFET
10-15% PPW (performance-per-watt)
Last non-tiled consumer CPU as Meteor Lake will be tiled

I'm guessing this will be a minor update to ADL with just a few microarchitecture changes to the cores. The larger change will be the new process refinement allowing 8+16 at the top of the stack.

Will it work with current z690 motherboards? If yes then that could be a major selling point for people to move to ADL rather than wait.

 

[Tuna-Fish]

Or some of the more-recent numbers are fudged. Or all the numbers are fudged. It's hard to say, but it's awfully fishy to me that we have some 13900k results matching the 12900ks (more or less) and then some others that far exceed it, in the same benchmark, in ST performance. Plus it's just GB5 so feh who cares about that garbage?

That's not that unbelievable, if you assume that the first results use some crappy ram. The difference between good DDR5 and the low-end stuff is already substantial on ADL.

 

[igor_kavinski]

v3.1 Changelog

• Update Mesh optimization pass to reduce game load up time by 70%
• Camera angle adjusted to be less top-down and adjust as the player zooms in and out
• Max threads increased from 16 to 24 to increase performance as many machines now have more CPU cores
• Update the Oxide logo
• Adjusted rendering priorities so that larger units look substantially better when there are fewer units on the screen
• Artemis HP reduced from 575 to 480
• Version bumped to v3.10
• Updated Turtle Wars scenario for balance changes from 3.0
• Updated Entropy scenario for same reason
• Regenerated Nashira map

Question for multi-core/parallel programming experts (if any here): why did they stop at 24 threads and not go all the way to 32 threads?

 

[Tuna-Fish]

Question for multi-core/parallel programming experts (if any here): why did they stop at 24 threads and not go all the way to 32 threads?

Presumably their workload doesn't evenly split and have some more heavy threads that they want to run on the P-cores without anything else on the other thread.

 

[shady28]

Ashes is definitely an interesting benchmark. It seems to make use of e-cores which is pretty awesome. Here is a 12900kf from yesterday within spitting distance of the 13900k.

View attachment 65745

The last update for Ashes includes this changelog:

v3.1 Changelog

• Update Mesh optimization pass to reduce game load up time by 70%
• Camera angle adjusted to be less top-down and adjust as the player zooms in and out
• Max threads increased from 16 to 24 to increase performance as many machines now have more CPU cores
• Update the Oxide logo
• Adjusted rendering priorities so that larger units look substantially better when there are fewer units on the screen
• Artemis HP reduced from 575 to 480
• Version bumped to v3.10
• Updated Turtle Wars scenario for balance changes from 3.0
• Updated Entropy scenario for same reason
• Regenerated Nashira map

If the game engine supported more threads, the 13900k would actually scale really well over the 12900k here. If the bigger L2 cache helps Raptor Lake get better minimum FPS, then that would be awesome, but we have to wait for reviews.

Frametime analysis needs to make a comeback.

They're close on that bar because it's GPU limited. But they're not that close if you look at the CPU frame rate.

Also worth noting, the person that put these scores up for the top 12900K and the 13900K is the same person. Most likely these are identical configs, same rig even.

For CPU part of the bench:
Normal batch went from 194->214
Medium batch 191->218
Heavy batch 168->194

12900KF :


13900K:

 

[dullard]

Question for multi-core/parallel programming experts (if any here): why did they stop at 24 threads and not go all the way to 32 threads?

The best example that I can think of is to imagine you need to move 20 people in a wedding from one location to the reception location an hour away. Suppose you have access to vehicles that can transport 5 people at once (1 driver and 4 passengers).

• 1 vehicle would take a long time. Since you can only move a net 4 people (a driver has to return) it would need at least 4 round trips and the 5th trip would end at the destination. Total time: 9 hours minimum. Add more time for fuel stops.
• 2 vehicles could do this faster. Total time: 5 hours minimum.
• 3 vehicles total time: 3 hours minimum.
• 5 vehicles total time: 1 hour minimum assuming all had enough gas.
• Not much you could do beyond 5 vehicles. But, maybe you could be certain to use cars that are all full of gas and have no maintenance problems. So you could almost guarantee that it would not take longer than 1 hour.
• You could even use 20 vehicles so everyone can go at their own pace, take their own route, listen to their own music, etc. But still you won't be any faster than the 1 hour it takes to do the drive.
• But what the heck do you do with 32 vehicles? How can 20 people reasonably drive all 32 vehicles? You'd have to do some really fancy people movement, double up on multiple round trips just to use all 32 vehicles. It would slow you down! Plus think of all the planning and scheduling you'd have to do to move 32 cars with 20 people. Why do all that costly effort? How much do you want to pay computer programmers to make this schedule and ensure it works?

Threads are the same way in most programs. Sure, there are artificial benchmark scenarios where you can just go from 20 people to 32 people or even arbitrarily have 160 people (5 per car lets you move 160 people with 32 cars in 1 hour). No problem and the more cars you have the better! But most real life software just isn't that way. You can't just adjust a benchmark setting and suddenly need to move 160 people to a wedding reception. You often just have 20 people to move. In real life, more threads just isn't always better.

 

[coercitiv]

why did they stop at 24 threads and not go all the way to 32 threads?

They're scaling to core count, not thread count. Makes sense if SMT is a mixed-bag for performance in their case.

 

[Zucker2k]

Raichu shares some interesting tidbits about Raptor Lake enhancements:

https://twitter.com/x/status/1558162390092771328

 

[CakeMonster]

I wish they would at least give a hint that they're not making stuff up.

 

[shady28]

I wish they would at least give a hint that they're not making stuff up.

 

[CakeMonster]

Ok, cool. I can imagine the cache and frequency as they've been discussed, will be interesting to see the ring bus. What does FE refer to?

 

[Kosusko]

I assume that AVX512, BF16 will be effectively used, which will be ensured by the new scheduler, and the L2 cache is adapted to this, not only in terms of size but also in improving the bandwindth of the L3 cache.

 

[Kaluan]

Question for multi-core/parallel programming experts (if any here): why did they stop at 24 threads and not go all the way to 32 threads?

That "update" came out just before Alder Lake launched, soon after that there were loads of pre-release ADL results conveniently seeded to that database, in another post it also specifies up to 16 core. 16 physical cores... 24 threads... hmmm I wonder CPU would have such a config! Haha

Their '24c/32t optimisation' update might follow shortly lol

 

[igor_kavinski]

Their '24c/32t optimisation' update might follow shortly lol

Let's wait and see

 

[shady28]

Ok, cool. I can imagine the cache and frequency as they've been discussed, will be interesting to see the ring bus. What does FE refer to?

No one seems to know

 

[Exist50]

I assume that AVX512, BF16 will be effectively used, which will be ensured by the new scheduler, and the L2 cache is adapted to this, not only in terms of size but also in improving the bandwindth of the L3 cache.

There's no indication that AVX512 is coming back anytime soon.

 

[Carfax83]

What does FE refer to?

I think it means "front end" but don't quote me.

 

[shady28]

Heh...

 

[mikk]

13900K 7zip decompress vs 12900K:

https://twitter.com/x/status/1559462256936886272

 

[Det0x]

13900K 7zip decompress vs 12900K:

https://twitter.com/x/status/1559462256936886272

Intel Core i9-13900K is reportedly 60% faster in 7-Zip decompression test than i9-12900K



As a comparison, seems to be much more competitive vs the 5950x in this benchmark now ("Post your 7-Zip v22.00 scores" @ TPU forum)

 

[Carfax83]

The boost in decompression can probably be accredited to the improvements to L3 cache performance and the increase in L2 cache size.

 

[coercitiv]

+ bigger L3

 

[tamz_msc]

Is it only cache though? LZMA is branch-mispredict heavy and FE, if it really means front-end, could be the more important factor.

 

[pakotlar]

Intel Core i9-13900K is reportedly 60% faster in 7-Zip decompression test than i9-12900K
View attachment 65975


As a comparison, seems to be much more competitive vs the 5950x in this benchmark now ("Post your 7-Zip v22.00 scores" @ TPU forum)

View attachment 65976

Should I be looking at the 171GIPS number or the 231, or the average, 201? On the 12900K all of those numbers are ~145. If it's the 231, it's 15% faster than 5950x, if 201, it's even.

 

[Det0x]

Should I be looking at the 171GIPS number or the 231, or the average, 201? On the 12900K all of those numbers are ~145. If it's the 231, it's 15% faster than 5950x, if 201, it's even.

You have both compressing and decompressing numbers, compare what you want

Overclocked 12900k @ 7000MT/s


13900k @ 6400MT/s


My 5950x @ 1900:4466MT/s (compressing scales alot with bandwidth, 16core would love ddr5 here)

(If running 1:1 synced memory with IF i would get 176.580gflops in compressing)

The ranking on the linked benchmark forum post is sorted by combined scores. (compressing+decompressing / 2 = totalt score)

 

[pakotlar]

You have both compressing and decompressing numbers, compare what you want

Overclocked 12900k @ 7000MT/s
View attachment 65993

13900k @ 6400MT/s
View attachment 65990

My 5950x @ 1900:4466MT/s (compressing scales alot with bandwidth, 16core would love ddr5 here)
View attachment 65991
(If running 1:1 synced memory with IF i would get 176.580gflops in compressing)

The ranking on the linked benchmark forum post is sorted by combined scores. (compressing+decompressing / 2 = totalt score)

13900K seems pretty good then. 60% bump on 12900K will probably make it competitive with 7950x (35% bump prior expectation over 5950X), though slower, especially if decompression can make use of AVX512.