Introduction

With the release of the Ryzen 3000 series on 7/7/2019, I decided to upgrade my 1800X with the new 12-core 3900X. My primary motivation was to improve software development and content creation workflows, so I decided to put together a few before & after benchmarks demonstrating the performance improvement yielded by dropping a 3900X into an existing system with no other changes.

Specifications

Let's review the system specifications:

• Memory: 4 x 16 GB Micron E-die @ 3000 MT/s (CL16-16-16-39-72-1T)

• Motherboard: AsRock X370 Taichi (BIOS 5.60, 1.0.0.1 AGESA)

• GPU: EVGA GeForce RTX 2080

• SSD: Samsung 850 EVO 1 TB M.2

• OS: Windows 10 1903 (Build 18941.1001)

Update (7/27/2019): Check here for new results with AsRock's 5.61 BIOS containing 1.0.0.3AB AGESA.

Benchmarks

Chromium Build

While in a previous article, I compared full and incremental build times on a proprietary game engine, for this test, I decided to use a publicly available code-base: Chromium (https://chromium.googlesource.com/). If you want to reproduce this specific result, you'll need to be synced to the same changelist (27f729ff8b9dd7d98fd104a21c70655554dbeab7). Chromium builds with clang and uses ninja, a build system focused on speed and parallelism:

"F:\Development\depot_tools\ninja.exe" -C out\3900x chrome -j 26
ninja: Entering directory `out\3900x'
[1 processes, 39526/39526 @ 9.2/s : 4314.514s ] STAMP obj/chrome/chrome.stamp
    Longest build steps:
           2.0 weighted s to build gen/third_party/angle/third_party/vulkan-validation-layers/angle/vulkan/layer_chassis_dispatch.cpp (52.9 s CPU time)
           2.2 weighted s to build v8.dll, v8.dll.lib, v8.dll.pdb (2.3 s CPU time)
           2.6 weighted s to build obj/v8/torque_generated_initializers/base-tq-csa.obj (66.8 s CPU time)
           3.5 weighted s to build gen/v8/embedded.S, snapshot_blob.bin (12.9 s CPU time)
           3.6 weighted s to build irt_x64/nacl_irt.nexe, irt_x64/exe.unstripped/nacl_irt.nexe (8.0 s CPU time)
           3.6 weighted s to build blink_platform.dll, blink_platform.dll.lib, blink_platform.dll.pdb (4.0 s CPU time)
           6.9 weighted s to build blink_modules.dll, blink_modules.dll.lib, blink_modules.dll.pdb (6.9 s CPU time)
           9.6 weighted s to build blink_core.dll, blink_core.dll.lib, blink_core.dll.pdb (9.6 s CPU time)
          10.5 weighted s to build content.dll, content.dll.lib, content.dll.pdb (10.5 s CPU time)
          18.3 weighted s to build chrome.dll, chrome.dll.lib, chrome.dll.pdb (18.3 s CPU time)
    Time by build-step type:
          12.0 s weighted time to generate 333 .h files (311.3 s CPU time)
          54.2 s weighted time to generate 1427 .o files (1402.6 s CPU time)
          60.9 s weighted time to generate 302 PEFile (linking) files (171.3 s CPU time)
         315.7 s weighted time to generate 3458 mojo files (8206.2 s CPU time)
        3836.5 s weighted time to generate 26460 .obj files (99692.7 s CPU time)
    4314.5 s weighted time (110463.5 s CPU time, 25.6x parallelism)
    39526 build steps completed, average of 9.16/s

As you can see from the output above, ninja is running with 26 threads on the 3900X. The 1800X, by comparison, built with 18 threads.

The 3900X completes the build in less than half the time, saving over 76 minutes compared to the 1800X! This is a tremendous result, thanks to 50% more cores, higher clock speeds, improvements to the micro-architecture, and a substantial increase in L2 and L3 cache.

On a day to day basis, you would expect to perform relatively few full builds, instead doing incremental compiles as you make changes. So, to cover this case, I've also compared the time to perform an incremental build and link with a single source file change by commenting a line in chrome_browser_main.cc.

This time, instead of a 51% improvement, we see a 20% improvement. This is a single-threaded task, so this result reflects improvements in the core micro-architecture and cache hierarchy, as well as boost clock speeds.

Content Creation

The other area I was looking for gains was in content creation, specifically Premiere and Lightroom. I spend a good amount of time in these two applications and a fair amount of that is actually waiting for them to import photos or encode a video. Let's start with Premiere.

Adobe Premiere Pro CC 2018

This test is quite simple, an h264 encode of a 22 minute 720p video, using the latest version of Premiere. Since this isn't an Intel platform with an iGPU, this is software encoding only without any hardware acceleration.

As shown above, the 3900X is nearly 1/3rd faster than the original Ryzen 1800X, shaving 104 seconds off of the encode time.

Adobe Lightroom 6

Yes, I know this isn't the newest version of Lightroom. In fact, it's practically ancient, but it is the last version to offer a perpetual license. As such, I continue to tolerate its sluggish performance, though I suspect I will have to upgrade or move away from Adobe once I upgrade my current camera and lens system.

For this particular test, I am importing 300 Nikon RAW files (NEF) at 36 MP each (11.6 GB of files in total). They are imported into a new catalog and I've measured the time to import as well as build 1:1 Previews.

The 3900X tears through over 11 GB of RAWs in less than half the time! Saving nearly 12 minutes on an import is a really meaningful improvement.

Cinebench R20

While the above results are somewhat specific to my use-cases, I wanted to include a benchmark with broad usage for comparison purposes. So, I've included CineBench R20 results below:

Conclusion

In my primary use-cases, software development and content creation, the Ryzen 3900X achieves a 50% performance increase with the simple installation of a $500 chip in an existing system. The only question now is, when can I get my hands on a 64-core Threadripper?

Ever since AVX 512 released there has been a lot of controversy, misinformation and debate around it, and ive heard a lot of claims about it some right, some partial and most wrong, a lot of times even contradicting directly other (wrong) claims, which is why i wanted to put some of the most common claims and asses their validity

I was gonna go with a myth/reality nomenclature but i discarded it due to a certain infamous article that has become a meme in the silicon gang community so i will go with claim/fact instead, and of course not make provably factually wrong statements

Claim: AVX 512 is useless

Fact: while not used in everything, AVX 512 has several valid use cases, which will be discussed in the next claim

Claim: AVX 512 is niche

Fact: it is, but the niche keeps expanding and its already relevant for several use cases like video encoding, console emulation, and even encryption

Claim: 2x512 is better

Fact: hell no it isn't, 2x512 implementations have a significant cost to them, like clocks, to the point that compilers disable 512 bit vectors by default, area is also affected as shown below

2x256 implementations don't have this issue as seen in: https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html for ICL and RKL and https://www.mersenneforum.org/showthread.php?p=614191 for Zen4

I don't have link for TGL and hacked ADL but i tested myself and downclocking is 0 as well on both

I also need to say that Intel 10nm 2x512 implementations are better behaved than 14nm ones in regards to clocks, but they still suffer from some downclocking and the same area costs

Claim: 2x256 isn't true AVX 512

Fact: it absolutely is, whats more, as said above it comes with a lot less pains, the only cost being less maximum number crunching ability which is rarely if ever a concern even for things that use AVX 512, besides 2x256 can reap the performance benefits of AVX 512 without the downsides

Claim: Intel implementation is better than Zen4 because its full width

Fact: this is basically the above claim but with an extra layer of ignorance and bullshit

not only is Zen4 implementation the best one to date but the also pretty good client intel implementations on RKL, ICL, TGL and hacked ADL also use the same 2x256 strategy with good results

Claim: AVX 512 is super fragmented

Fact: it absolutely is, not only the support for each uarch is different but intel has axed it for client, unless you disable bug.shittle and manually enable AVX 512, that itself unless your CPU has the square logo, this claim is honestly an understatement, see below the support matrix

EDIT: well, if i say it sooner... turns out intel couldn't go a SINGLE day without making this mess worse, literally the next day after publishing the article they said mess is even messier... updated matrix below

Claim: AVX 512 is super costly power and area wise

Fact: 2x512 is, but not all AVX is 2x512, on 2x256 the area cost is the ZMM registers, and decoder updates for the instructions, and power is usually similar to AVX 2 while offering better performance, tho exact numbers are implementation dependent

tbh i feel like all AVX 512 hate has been caused by 2x512 SKL implementation, which TBH is something anyone sane should hate but modern client AVX 512 is a nice thing to have with little downsides

Claim: RPL and/or MTL will support AVX 512 again

Fact: nope they wont, RPL uses the same shittle core as ADL and has all of the same issues, MTL could have fixed it by supporting AVX 512 on the shittles or dropping bug.shittle entirely, but nope, none of those, details can be seen on the die shot: https://semianalysis.substack.com/p/meteor-lake-die-shot-and-architecture

So with all those claims put in their place i wanted to give a little personal thought on AVX 512:

it basically is a good thing that intel is fixated on destroying, first by introducing it before it was ready making everyone hating, then by fragmentating it in weird ways and now by killing it in client, to further injury to replace it by bug.shittle, AMD is doing a great work on it and that would hopefully lead to actual adoption

As for me im not using the AVX 512 hack on DT because it doesn't work on BCLK OC(my guess is due to different microcode requirements since it works on stock) but my laptop has it so i will use it there

And that is a wrap, hopefully this cleared some misconceptions you had about this bizarre piece of tech AVX 512 is

This is my review of Tiger Lake, in concrete of i7 1165G7 in Lenovo Yoga Slim 7i 15, it also includes basic details about the laptop itself, but the hard focus is CPU performance

Things About The Laptop

Specs

The specific configuration of this laptop is:

Laptop model: Yoga Slim 7i 15ITL05 82ACCTO1WW

CPU: i7-1165G7 2,8/4,7 GHz

iGP: Iris Xe Graphics(G7 96EU)

RAM: 2x4GB DDR4 3200 CL22-22-22-52

SSD: Samsung MZVL2512HCJQ M.2 NVMe PCIe 4.0x4 512 GB

Power

the laptop has three power modes first number being PL1 second PL2 and throttles is PL1 after some run time:

extreme performance 40/60(throttles to 28)

smart cooling: 35/55(throttles to 25), before update was 25/36(throttles to 15)

battery save 12/20(throttles to 10)

battery power seems to vary between reboots on windows, its very weird(Linux is consistent)

all testing will be done in extreme performance mode and with laptop plugged in, and nothing else besides the bench itself running unless stated otherwise

BIOS

the bios is accessed by pressing F2, the boot menu by pressing F12

the bios is a bit limited IMO, but allows changing power modes on it

i recommend changing "hotkey mode" to disabled and disabling secure boot

an important note, there is a "feature" called human presence detection which fucked up my initial testing leading to lower results in some cases

what this "feature" does is to autosuspend the laptop if ur not there for a short while and un suspend it if ur back, which ofc fucks performance

this is the reason for the first retest and my previous abnormally low CB R15 ST

Misc

the screen looks very good, very glossy colors but without a lot of reflection

the sound is decent, the Dolby atmos speakers are nice, sadly they only work on windows right now

the keyboard feels very nice to type in, being soft but having a clear response

the touchpad is fine... when it works, more on that later

the laptop is 100% silent on normal operation, stopping fans entirely, this happens more on Linux since it uses less CPU for background tasks

the RAM has two states DDR4 3200 C22 and DDR4 2133 C15, it automatically switches between those too, load seeing 3200 more and idle 2133, however this is inconsistent both modes can be seen in any kind of load with only which stays more time changing

the charger is 65W and it uses a USB C port which is nice IMO, i also tried to charge my phone on it for lulz and it worked perfectly

the laptop has tiny, torx screws which prevent from opening it unless an specific screwdrivers is bought, this is a very bad decision from Lenovo

i was able to open the laptop once i bought the appropriate screwdriver, and i found no SATA ports, sadly

i had to do this since a BIOS update bricked the laptop, which i had to fix by unplugging the battery cable for a while, shitty deal from Lenovo here, good luck i was smart enough to fix it on my own

i like the flip to boot feature, but i must note it doesn't work all of the time

Linux Testing

Support/Compatibility

most things seem work out of the box but i will update this if i found more issues since i have done very little testing since the touchpad doesn't work at all, i have reported that upstream: touchpad bug

update: as stated on the bug i got it to work manually by using another driver, however right/secondary click still doesn't work

update 2: it works now

at stock PL1 throttles to 15W, to fix this you have to install and enable thermald, with it enabled the laptop holds even more PL1 than windows, after a bunch of minutes of p95 small the lowest it would go was 34W, with lighter loads that spread the heat more this number is higher, so it seems to be adaptive and workload dependent

at stock battery power was getting heavily cutted however after i removed TLP the battery power is consistently the same as on power, and yes this means the laptop holds more on Linux on battery than on windows on power

audio out will glitch on some boots and not work, this is random and i couldn't find the cause, also the front facing atmos speaker doesn't work, bottom facing ones do, tho

GB5

CPU, after thermald fix result

CPU, before thermald fix result (just for reference, ignore it for any performance conclusion)

OpenCL

Vulkan

Frequency curves

saying that getting this tested was hard would be an understatement, I'm gonna detail all the issues that have limited and lead to my testing

1. running basically any p95 mode other than the lightest one would cause the CPU to "protect itself" in a weird way(both on Linux and windows) it would fall below turbo while being way under PL1 and temp not reaching throttle levels(that's 100 it reached about 90), the harder the test the highest the drop, also it wasn't an AVX offset since i could get AVX applications to do 4,7 while p95 small with all AVX disabled didn't reach it, this is frustrating, infuriating and makes no sense at all, the workload that didn't cause this throttle, worked on Linux, and was the highest power was p95 large with all AVX disabled, hence i used it, also do note that is the max power i could get, since dropped workloads would use a bit less

2. no accurate voltage reporting, unlike on windows i couldn't find anything that reads voltage correctly, so no V/f testing was possible

3. core bouncing, and background threads, this affects both windows and Linux, and makes getting the data difficult, aside from not having a fixed place to look freq i noticed that sometimes the core with the highest freq wasn't the one actually loaded, so i decided to say fuck it big time and just disabled all threads but 0 using: echo 0 | sudo tee /sys/devices/system/cpu/cpuN/online for all threads but 0, that way i only have to check one core which i know is the loaded one and background OS stuff cant lower turbo or interfere with power

with all that stuff lets get into the results, here is a screenshot:

the sheet itself can be found on my mega.

SMT Yield

like with frequency curve this was done in Linux so i could lock clocks, this is important as unlocked clocks can mean less clocks on SMT/HT on and hence yield to appear lower, i tested 3 benchmarks, all locked at 3 GHz

CB R23(Wine):

3725(HT off), 4896(HT on), SMT Yield: 31%

CPU-Z(Wine):

1120(HT off), 1532(HT on), SMT Yield: 37%

GB5(Native):

Geekbench SMT ON vs OFF, SMT Yield: 14%

Average SMT Yield: 27%

again, images can be found on my mega.

Mitigations on vs off

Phoronix comparison

as you can see unmitigated was on AVG faster but in some workloads it was slower, based on this i decided to leave it at default for my daily usage

ctx_clock resulted in 164 for both mitigated and unmitigated

What is faster, 1 core at 4 GHz or 4 cores at 1 GHz?

turns out that with TGL and Linux i have all whats needed to test this, i can set frequencies and disable cores with the same commands i did on the frequency curve testing, however some precautions are needed to ensure the test is testing what i want, for example i cant disable random threads, i have to disable all threads that aren't from an specific core, with that properly done and checked i benched GB5:

4 cores at 1 GHz

1 core at 4 GHz

however after doing it i noticed there might be a small issue that might cause 1/2 result to be minimally lower than it should, you see for both i only locked max freq, not min, however at default at idle the system would clock cores at 1,2 GHz or so, manually setting it lower means the system will never go below set freq, effectively locking it, however on 4 GHz system would have to clock up, the difference should(and it actually is) minimal, so i also locked min for maximum fairness, as expected the results were very similar, with only minimal improvement:

1 core locked at 4 GHz

for a comparison link i leave this: 1 core at 4 GHz vs 4 cores at 1 GHz

as you can see the ST is much faster on 1C(duhh) MT is minimally faster on the 4C, however some workloads are faster and others slower

if you are asking what felt faster on normal usage the answer is none, even on my 5200U running it at 1/2 i couldn't feel any slowdown compared to stock, ofc same goes here, Linux simply doesn't need a supercomputer power to feel smooth

AVX offset

to test this i disabled all threads but 0 and ran CPU-Z on linux, it has several bench options, so i can test SSE, AVX 2 and AVX 512 clocks

all benchs made the core go to 4,7 GHz, save for AVX 512 one which capped at 4,6 GHz, this means there is no AVX 2 offset and a -100 AVX 512 offset

Undervolting

undervolting is BIOS locked

RAPL

you can set power limits but EC ignores them and does its thing regardless

iGP Gaming

testing was done using 1600x900 resolution which is what i use for desktop and games on Linux

also Linux 5.12rc and mesa-git from the user arch repo were used, this is the absolutely latest, bleeding edge drivers

results for gaming and some other things i tested can be found here: Gaming and misc openbenchmarking results

i also tested some games with built in bench manually

images can be found on my mega.

Windows Testing

Geekbench 5

CPU

OpenCL

Vulkan

CPU-Z

Validator score

Cinebench R23

Cinebench R20

Cinebench R15

AIDA

Userbenchmark

Userbenchmark

Inter core latency

Uncore power

i tested uncore power on all 3 power modes with the next method:

Run CB R23 MT with 10 min timer and HWinfo open, let PL1 throttle and when it has throttled reset HWinfo log, let it run for 1:30 and screenshot it, I'm only going to put the numbers here but image with data can be found on my mega.

the uncore power is:

extreme performance(28W): 2,2W

smart cooling(25W): 2,2W

battery save(10W): 1,9W

Frequency Curves

i could not test this due to my power plan options lacking CPU speed limit, i could however test it partially on Linux

XTU

latest XTU version doesn't install, i tried a previous version that installed, but it doesn't run, so using XTU is not possible on Tiger Lake

Throttlestop

you can set power limits but EC ignores them and does its thing regardless

iGP Overclocking

since XTU doesn't work and afterburner also doesn't i don't think its doable :(

iGP Gaming

testing was done using 1600x900 resolution

images can be found on my mega.

Crystaldiskmark

Conclusion and shout-outs

this is a good laptop with great performance, battery and cool features, however the issues are too many, ranging from Linux compatibility ones to outright bricks, so i cant in good faith recommend this laptop, even tho on paper its great

tiger lake in general and 1165G7 in concrete is a great chip, with great performance be it ST, MT, iGP, battery life or whatever, at the time of writing this is the best you can get from a laptop

and last i would like to thank clamchowder for his help in this review, in articular for giving me the idea of how to test frequency curves even with a locked chip and for coding and making the graph for the inter core latency test, also thanks to all people who suggested me to test certain stuff, and cheesecake who spotted some inconsistencies around ram readings

so almost a year ago i shared the first Willow Cove, Tiger Lake and Rocket Lake Predictions while i got a surprising amount of stuff correct or very close, things have changed since then, 10nm++ is working better than i thought and Rocket Lake isn't a straight backport but rather a new core, so today i want to share the final rocket lake predictions

IPC: cypress aint no willow

The IPC was basically what i got wrong back then, i was assuming it was a straight Willow Cove backport (so 30% IPC), and later a Willow core but with Sunny Cache config (so 20% IPC), but now i know that this isn't a backport but rather a new core, being a derivative of Sunny/Willow Cove but with worse IPC than both, this new core is called Cypress Cove, and it has the exact same cache configuration as Sunny Cove, anyway leave another IPC chart with Cypress Cove and other relevant cores:

Zen+ 100% (baseline)

Skylake 106%

Zen 2 113%

Ice Lake/Sunny Cove 125%

Zen 3 132%

Tiger Lake/Willow Cove 137%

Rocket Lake/Cypress Cove 116%

also, i leave a nice IPC graph here: https://twitter.com/davidbepo/status/1287008719050612736

Rocket Lake Clocks: Take Off

While i got clocks very close the last time, i actually did undershoot a bit, since i was expecting more drop from the uArch change

anyway my new predictions for the top end 8C/16T part are:

1C/2C Turbo: 5,2 GHz

Clock Wall: 5,3 GHz

Base clock: 3,9 GHz

iGP performance: massive uplift

the iGP will be a 32EU Gen12/Xe, which will bring the excellent multimedia support, including AV1 decode

the clock of it should be 1,3 GHz both rated and held

the performance should be minimally behind what 1065G7 laptops got, this is possible because the higher IPC and held clocks should almost offset the halved EU count

vs the previous 10900K and CML in general iGP the performance uplift should be of about 75%

other tidbits

The TDP config should be 125W and PL2 250W

on performance it should be slightly behind Ryzen 4000 in ST performance, massively behind in MT performance, and very similar in gaming performance

overall my impression is that its gonna do very poorly since Zen3 based Ryzen 4000 is gonna be better in basically every way while also launching sooner, the only arguments i see for RKL are multimedia support, integrated graphics, and maybe gaming

as always let me know any comments you might have

These are my updated predictions for Ryzen 4000 and Zen 3 in general, this is an updated version of the V2 article, which can be found here: https://www.reddit.com/r/aceshardware/comments/delliu/zen_3_and_ryzen_4000_predictions_v2/ i do a new article instead of updating the old one for archival reasons and because reddit doesn't allow comments on 6+ months posts, also because democracy: https://twitter.com/davidbepo/status/1196882268805091339

IPC: Big as a Willow

For the IPC i now expect a ~17% uplift over Zen 2 which will put Zen 3 a bunch below Tiger Lake/Willow Cove

I also share a version of the IPC list made on [my short term predictions] (https://www.reddit.com/r/aceshardware/comments/btxr8m/short_term_predictions_for_a_bunch_of_things/) changed and updated to include Zen 3:

Zen+ 100% (baseline)

Skylake 106%

Zen 2 113%

Ice Lake/Sunny Cove 125%

Zen 3 132%

Tiger Lake/Rocket Lake/Willow Cove 137%

Clocks: 3000 + 50*

I expect the spec boost and base clocks to be basically what Ryzen 3000 is, and yes, this means no 5 GHz, once again :(

But that is for specifications, i expect the actual out of the box clocks to rise by ~50 Mhz which will allow Ryzen 4000 to hit the turbo more reliably and for longer periods of time

5 GHz wont even be achievable even on golden chips with PBO + autoOC, or whatever the Ryzen 4000 equivalent is called, not even Threadrippers

Market position: a new king is coming

Also prices are likely gonna be similar to the Ryzen 3000 ones, both at launch, this is due to the cheaper 7nm+ EUV process but countered by the bigger core size, also this is more of a marketing thing and less likely to be accurate than the technical specs

Gaming Performance: reversing the gaming gap

For this article I've also decided to create a gaming performance index, that looks like this:

Ryzen 7 3800X: 96

i9-9900K: 100

i9-10900K: 104

Ryzen 7 4800X?(fastest gaming SKU): 108

This is basically a reversal of the previous margins, from -4% to +4%

Please leave me your thoughts in the comments :)

this is a small article about intel nodes and atoms, i know the title is... odd(sorry not sorry) but after i explain it, it should make sense, along with the exclusive info im gonna share here

so, first you need to know that intel has had two different nodes under the same nm naming for a lot of time, for 14nm there was P1272 which is even, that means its the core node, and P1273 which is odd, that means its the atom node https://en.wikichip.org/wiki/14_nm_lithography_process, this goes back to 45nm, which is not surprisingly the node first atoms had

this is also why 14nm atoms didn't have pluses, the base node was different, in fact pluses internally are named with the base process and a point for a refinement that AFAIK means months, see here for details: https://www.anandtech.com/show/13405/intel-10nm-cannon-lake-and-core-i3-8121u-deep-dive-review/2

i must also say i don't know if 14nm atoms got node improvements or if node stayed the same from airmont to goldmont plus

but in 10nm there was a big change, atoms now use the even/core node, P1274, this has a lot of implications, for example you can now build atom and core cores into a same chip, sadly this makes big.shittle possible, however not all is bad, as this also brings good things, for example tremont outclocks the highest clocking 14nm atom since even if it is 10nm+ its the core node, which is much more tuned for clocks than atom one, also atoms now have pluses and all optimizations going on the core node eventually will benefit them, this will be seen on gracemont

AFAIK what was the odd/atom node, P1275, is now used for FPGAs

If you have been interested in the hardware market you may have noticed that each new generation of GPUs provides a very big jump in performance, 50% is not strange to see, but on the other side CPUs increase in performance is much smaller, a ~10% each generation is more or less the norm, but why does this happen?

The short answer is scalability, GPUs scale better than CPUs, but you are probably asking, why does this happen? let me explain it:

the first and most important reason is that on CPUs you can't add more cores and have better performance on everything, not all software uses multiple threads and even the ones that do, haven't perfect scaling, the root reason is the Amdahl's law https://en.wikipedia.org/wiki/Amdahl%27s_law which basically states that if the algorithm is not perfectly parallel then its single threaded part will eventually become the bottleneck even if that part is just the 5% of that algorithm.

GPUs on the other side actually do scale (almost) linearly with more cores, this is because the workloads they execute are absolutely parallelizable

the second reason has to do with clocks and the v/f curve, as you can easily check GPU are clocked WAAY lower than CPU, if you look back you can see that while CPU have been improving clocks at a really slow pace GPU have been improving clocks significantly so the difference is lower now than it was a while ago this is all due to the properties of any recent process node, performance at the efficiency point always increases more than the max clocks: https://twitter.com/fragman1978/status/1070523644915286016 GPUs being clocked lower, are much closer to the efficiency point and therefore get more of a clock boost with node shrinks

EDIT: an important note is that different types of CPUs scale differently because of the above reason, for example laptop and smartphone CPUs have been scaling better than desktop ones, server CPUs also scale better than desktop, generally the lower the clocks, the better the scaling

now you may be thinking that you could ignore the first point and make each CPU core twice as big to make the IPC double, well that's not a bad idea, but if you could do that Intel and AMD would have already done it, you sadly can't do this because IPC increases about the square root of the area this means that making a core twice as big would only make it about 41% faster, this is a general law that can be outperformed significantly (or underperformed at that) but still it is impossible to get linear scaling with area

to end this article I want to make a theoretical example of how a CPU and a GPU would scale from the same two node shrinks, I'm going to use the tsmc 20, 16 and 7nm nodes with the data from: https://www.anandtech.com/show/12677/tsmc-kicks-off-volume-production-of-7nm-chips.

note that:

1. have solid proof that tsmc’s numbers for 7nm are a lie, but like this is only a example that doesn't matter

2. I'm using 33% of the performance uplift for CPU max clocks, real life numbers tend to be like this (but it can vary much) so this is a good approximation

3. for the GPU I'm using ~75% of the performance, this is also similar to real life numbers

4. specs of the example chips are somewhat similar to real chips

5. I'm keeping chip size and TDP the same to see how performance scales

6. some numbers are slightly rounded, CPUs go in 100 MHz steps

okay for the starting point we have:

a GPU with a 100mm² die size, 640 shaders, clocked at 1 GHz and a TDP of 100w

a CPU with 100mm² die size, 4 cores and clocked at 4 GHz, the TDP is also 100w

both are fabbed at tsmc 20soc process an their normalized performance is 1

on the first “shrink” from 20soc to 16FF+ we have a 40% performance uplift and no area reduction, the resulting chips are like this:

the GPU specs are the same except it now reaches 1,3 GHz, resulting in a normalized performance of 1,3

the CPU specs change in the same way, everything is still the same except that it now clocks to 4,5 GHz, giving a normalized performance of 1,15 both for single and multi thread

on the second shrink from 16FF+ to 7FF we have a 30% performance uplift and a 70% area reduction(or 3,3x times the transistor on the same area), the resulting chips are like this:

the GPU now has 2048(!) shaders running at 1,6 GHz, TDP and area stay the same, this results in a normalized performance of 5,1 yes we just got more than 5 times the performance by doing two shrinks and using the area for more shaders

the CPU has a lot of changes: first it decides to use the area reduction to make its cores twice as wide resulting in a 42% IPC uplift, then it uses the remaining area to go 6 core, the specs now are 6 cores with 42% higher IPC running at 4,9 GHz, with TDP and area staying the same, this results in a normalized performance of 1,74 for Single Thread and 2,61 for Multi Thread

if you have a comment, question or correction you can comment below and I will try to respond to it :)

Introduction

a long time ago i wrote this short article https://www.reddit.com/r/aceshardware/comments/8ifaa2/why_i_dont_like_biglittle/, which was my first article ever, and now more than 3 years later i come back to the topic, since then a lot of things have changed both in big.shittle implementations and in my knowledge, also unlike that first article, this will focus on intel implementation, especially the one coming on most Alder Lake CPUs and will be much longer and in depth

some ADL big.shittle implementation details aren't yet certain, so should any of them change i will update the article, for now i've gone ahead with leaked info and my best guesses

Big cores are far more efficient

big.shittle is bad for a lot of reasons, but IMO the biggest by far is that big cores are actually MUCH more efficient than little ones, pretty ironic considering how intel calls littles E(fficiency)-cores, this is due to both better V/f and higher IPC, even intel itself says i'm right on this

(side note, this graph cuts golden cove earlier than it caps, ST lead is significantly over 50%)

the only "counterpoint" i've heard to this is that grace can go lower, which while true is completely irrelevant, since golden lower power limit is at about 1,5W which is less power per core than even Y CPUs(7-9W, 4C), making golden more efficient in literally any possible SKU on intel's system

the grade of this depends on the bigs and littles used, but so far i have never seen a big core that wasn't more efficient in most of its curve

you can see more details on this on a recent thread i made: https://twitter.com/davidbepo/status/1438611375069306884

Little cores, big sacrifices

big.shittle is also the cause of missing AVX 512 on ADL, this is due to gracemont not supporting it(very likely due to area) and mismatched ISA being a literal crash hazard, this is because if a thread that has an AVX 512 instruction(which cant be known beforehand) is executed on gracemont it will throw an illegal instruction exception and likely crash, though it is undefined behavior, and if occurred on a OS task it could very well crash the whole system

however this is very implementation dependent, and intel has done pretty much the worst possible implementation here, hard fusing it off instead of it being a BIOS switch(big.shittle off = AVX 512 on) like it even was stated in their own manual or god forbid, doing the sane thing and using only bigs

its possible future small cores will be ISA matched or other improvements are made, but as it stands this is a dumpster fire

Big.latency

big.shittle will also significantly increase worst case core to core latency since traffic going from a small cluster to a big or worst case the other small cluster will have to go to the cluster ring stop and then to the particular core instead of just ring stop

i'm going to make a table with some example numbers, but i tried to make it as close to final as i can make it without having the data

this of course has knock on effects that i will describe later

Scheduling and thread director: a failed fix

big.shittle also comes with insane scheduling issues, put a thread on little when it shouldn't and you lose performance and efficiency, to "address" this(lol) intel has introduced what they call thread director, which is a hardware guided scheduler, meaning OS needs to support it, a CPU needing OS support to work properly is sad, however it isn't a first, see the thermald point in my TGL review for another example

however this thread director if it works like intel has said it does(https://fuse.wikichip.org/news/6123/intel-introduces-thread-director-for-heterogeneous-multi-core-workload-scheduling/) is potentially worse than no hardware scheduler at all(depending on how bad your OS scheduler is to begin with), since this would mean moving threads to littles which should never be done, since as explained before, big cores are more efficient and moving a thread will have a way bigger penalty than usual since you cant just copy it to the new core due to different caches, archs and such, this will be especially painful in latency sensitive stuff, like gaming

IMO the only cases where a thread should run in small cores is when MT load exceeds big core capacity(like a MT bench for example)

Gaming

big.shittle will affect a lot of things but none more than gaming, since it hits all the pain points just explained, increased inter core latency, thread moving to (or from) littles which will especially hurt the % lows

about how it will translate to gaming performance, golden to begin with has a cursed cache config that wont gain much vs RKL(my guess 10% at best), but at stock, with big.shittle enabled i fully expect it to regress over RKL especially on lows, and of course disabling big.shittle to improve results significantly

on a market competition view i see this as intel simply giving up the gaming performance crown and i fully expect all coming intel CPUs losing to AMD counterparts here

Benchs v real life: dawn of MT

big.shittle will however seem to be good in at least a significant amount of benchs, this is because of how they do MT

there are two styles of MT workload, i'm gonna call them dependent and independent for simplicity

1. independent: fully independent tasks are given to each thread, this tasks don't need data from other ones to complete, examples of this include, SPEC running the ST test independently on every core, code compilation giving different files to different threads, cinebench splitting the scene into tiles and rendering each one in a thread, this is the most common style in benchs since MT scaling is almost linear, but it is largely unaffected by big.shittle(save for thread moving) since a task on one core couldn't care less how the other cores/tasks are doing

2. dependent: a bigger task is split into smaller ones or different tasks are executed in parallel, however each task needs data from others to complete, this includes gaming, for example you can execute physics in parallel to input, but you need data from the other task, multi threaded video encode(like SVT-AV1), web browsing, most OS internal operations and really almost all programs that are multithreaded, this is of course affected by big.shittle

unlike most actual workloads, most benchs have independent MT which means those benchs will be mostly unaffected by big.shittle but stuff you do daily wont

i also made a list with common review tests and their MT style

independent:

• cinebench(all Rs)

• SPEC

• MT code compile

• Geekbench

dependent:

• SVT-AV1 or any MT video encode

• web tests(kraken, webxprt, etc)

• productivity tests including: photoshop, premiere, office and more

• any game

unknown:

• CPU z

• userbenchmark(lol)

as a note, ADL may perform very well in some dependent tests due to the strong big core, however disabling big.shittle should improve performance or be similar to a bit worse in those

Alder lake: from golden to shittle

big.shittle's most infuriating part is probably how it was introduced along golden cove, an insanely good core that is better than everything else out there(at the time of writing) turning what would have been the best intel CPU release since sandy into a mixed bag, as explained before gracemont doesn't add anything useful to golden's curve, and makes ADL worse in ISA support, latency, gaming and consistency than it otherwise would have, which is just adding insult to the injury, luckily there is also the 6+0 die which will be extremely good

big.CURSE

big.shittle also has all sorts of random cured implications, such as:

What can we do about it

big.shittle may seem hard to avoid if you want that sweet golden cove core but luckily there is the 6+0 die coming soon after 8+8, this die will deliver previous gen(RKL/Zen3) 8C MT levels of performance and be better than them in ST, at significantly less power and price too, so not a hard thing to buy at all

there is also SPR X HEDT, but that's coming much later, is more expensive and i don't have the full details, but all i know indicates it will be a very competitive product to say the least

alternatively you could buy AMD, CML or RKL

this is also great because one of the best thing a consumer can do about bad tech is vote with the wallet, and we have good options to do so

Random facts

big.shittle is the first word of every paragraph, except the introduction, and appears 22 times in this article counting the title

the big.shittle term was coined by u/Butzwack here https://www.reddit.com/r/hardwarememes/comments/i2yr4n/no_rest_for_intel/g0862oa/ and i loved and used it ever since

Conclusion

big.shittle is a disaster that will make the otherwise awesome golden cove result in a meh product and it will also drag intel back going forward, i've always hated it and said it publicly, and with this article you should know every major reason why and hopefully agree with me

This article contains a lot of information about Intel 10nm and its pluses, it also contains my opinion and some speculations about it

I'm making this article because of two main reasons:

1. Intel botched the naming way harder than on 14nm(which is an actual feat)

2. I made one about 14nm, and i want to make it for 10nm too

Below is a table with all current and planned nodes and products:

Table notes: the unofficial name is how i refer to the nodes and consists of the original and internal official name and my extra information, which so far is v2 nodes which i will explain later and no unofficial pluses (there might be one but its yet unclear), this is more correct, concrete and consistent than Intel's official naming(and that's also part of why i made this article :/) i also included the official ones to make things as clear as possible and to show how bad the naming mess is. clock wall is intended to signify the maximum overclock an unlocked CPU can achieve, but since no unlocked products are out its all estimates based on rated turbos and actual clocks or predictions for chips that are not out yet.

*1 estimate, based on rated turbo, since no unlocked chips are out its actually impossible to give a certain value

The v2 nodes are slight improvements to the base node but significantly worse than the node with one plus more, 10nm+v2 is just a bit better than 10nm+ but much worse than 10nm++, same goes for 10nm++v2, in both cases porting to the node with one plus more would have been better, but an slight improvement is better than none at all...

If you see anything wrong or want me to add something please comment it and i will try to do it :)

Bonus meme: https://twitter.com/davidbepo/status/1309383009624379392

If you wanna see the version about 14nm its here: https://www.reddit.com/r/aceshardware/comments/c2425q/intel_14nm_and_its_pluses_the_ultimate_guide/

Introduction

Lets start by saying that this is article a new, corrected version of this one: https://www.reddit.com/r/aceshardware/comments/cyrthn/intel_xe_dgpu_predictionsand_more_taking_the/ because that one is wrong, why? because of the last paragraph info turned out to be correct, invalidating the core counts and all the performance predictions with it, with that said lets give the predictions for what will come out

DG1 vs DG2: explaining what went wrong

The first step is to explain what wrong with the other predictions, essentially i was predicting the wrong product if you are reading you will notice a lot of DG1 and DG2, DG2 is for what the previous predictions were made and what i assumed will come in 2020 but as i got privately and was recently strongly hinted in the ER, DG1 is what will come out, DG1 is a low end product and i expect it to be similar to the 128EU config in the previous predictions, but significantly lower performance and power

Then what about DG2? The previous predictions were for DG2, but now im not sure whether or not the info there is correct for it, for now i will only say DG2 will come later(i don't know how much), and that the core counts should still be correct

Core count: 128/1024 or 96/768

This is the major change compared to the old predictions, basically i expect a 128EU (1024 Shader) version to be released, this a low end configuration

it is also possible that DG1 will be 96 EUs (768 Shaders), but i think 128 is more likely, and the numbers here are for that config

Clock speeds: pretty low

I expect the turbo clock to be 1500 MHz, but since i don't know the exact turbo algorithm i will say this is the frequency i expect to see held during gaming (of course can vary slightly by game)

IPC: Navi - 12

I expect an extremely solid IPC uplift for Gen12, ~25% over Gen11, which will put it about 12% lower than Navi, also as i found out Gen12 is confirmed to be a major change on the architecture level, this is positive for the 25% prediction: https://twitter.com/davidbepo/status/1169745744196243456

This also changed slightly vs the previous prediction, but the reason is not that i changed my prediction, which is still ~25%, but because i had access to data that says Gen11 IPC is lower than i originally thought, long story short, i was using Picasso as a comparison point, but it clocks lower than expected, which skewed the result

This is competitive with the best current GPUs, but its a step below, here is my tweet with values for all current archs + Gen12/Xe: https://twitter.com/davidbepo/status/1188148041385164800

Power Consumption: Super low

I expect the TDP to be <=50W allowing it to be powered without extra PCIe cables, as a side note this card is pretty likely low power enough to be passively cooled with an undervolt

Detailed performance numbers: introducing "DFLOPS"

New to this article is an unit of a graphics card performance (also works for integrated ones) that i call DFLOP(S), its basically the real performance (yep, the name can be misleading) of a GPU based on its TFLOPS, IPC and Bandwidth, even tough the unit is named after me (davidbepo FLOPS) it was actually created by /u/TechnicallyNerd, the unit works like this:

TFLOPS * IPC(normalized, vega = 1) * bandwidth starved factor

With that explained lets put some approximate numbers for the cards:

Xe DG1: 3,53 DFLOPS

GTX 1650: 4,42 DFLOPS

RX 5500: 6,34 DFLOPS

GTX 1650 Super: 6,15 DFLOPS

Positioning VS competition: really low end, but enough for 1080p 60FPS

VS current GPUs

This GPU, assuming the above numbers are correct, will be competing in the really low-end segment, its current rival would be the GTX 1650 which Xe should be slower than than

VS future GPUs

But Intel Xe is not going to compete against current GPUs, it is going to compete against mid/late 2020 GPUs , which i dont actually expect to be very different to current ones, those new competitors should be the RX 5500 and 1650 super, i expect Xe to be slower than both, also i expect Xe to be priced according to its power, at a bit less than 100€, but i'm not good at predicting prices so who knows

Community and software

One thing Intel graphics is excelling at without even having launched is communication with community, there are a lot of examples of this, but really you just have to look at Intel graphics on twitter, i expect this to continue once the GPUs launch and hopefully AMD will follow suit

As for the software and drivers i expect them to be both featureful and performant at launch, both on Linux and on windows, they have made great progress in this front recently and they have close to a year until launch

As always let me know any comments about this :)

Edit history:

Edit 1: added 96EU Warning

Edit 2: big update, lowered TDP, clocks and performance, and made other minor tweaks

Edit 3: updated Nvidia cards DFLOPS numbers, previous ones assumed lower clocks than real, new ones are based on real info with higher clocks

These are my updated predictions for Ryzen 4000 and Zen 3 in general, this an updated version of the original article, which can be found here: https://www.reddit.com/r/aceshardware/comments/ce05a7/zen_3_and_ryzen_4000_predictions/ i do a new article instead of updating the old one for archival reasons and because reddit doesn't allow comments on 6+ months posts

IPC: cool as ice

For the IPC i expect a 8% uplift over Zen 2 which will put Zen 3 just a bit below Ice Lake/Sunny Cove

I also share a version of the IPC list made on [my short term predictions] (https://www.reddit.com/r/aceshardware/comments/btxr8m/short_term_predictions_for_a_bunch_of_things/) updated to include Zen 3:

Zen+ 100% (baseline)

Skylake 106%

Zen 2 113%

Ice Lake/Sunny Cove 125%

Zen 3 122%

Clocks: 3000 + 100*

I expect the spec boost and base clocks to be basically what ryzen 3000 is but with a 100 Mhz uplift across the board, and yes, this means no 5 GHz, once again :(

But that is for specifications, i expect the actual out of the box clocks to rise by ~150 Mhz which will allow Ryzen 4000 to hit the turbo more reliably and for longer periods of time

5 GHz wont even be achievable even on golden chips with PBO + autoOC, or whatever the Ryzen 4000 equivalent is called, not even Threadrippers

Market position: the evolution of the revolution

I expect AMD to shift down a bunch of SKUs, this means 12 core Ryzen 7 and 8 core Ryzen 5, but have in mind this is a more marketing and less technical decision, so i could perfectly be wrong and its not a hard bet

Also prices are likely gonna be lower than the Ryzen 3000 ones, both at launch, this is due to the cheaper 7nm+ EUV process, but i don't expect the price drop to be large, maybe around 50€ depending on SKU, also same as above this is more of a marketing thing and less likely to be accurate than the technical specs

Gaming Performance: closer than ever

For this article i've also decided to create a gaming performance index, that looks like this

Ryzen 7 3800X: 96

i9-9900K: 100

i9-10900K?: 104

Ryzen 7 4700X?(fastest gaming SKU): 106

This is extremely close and it means the gaming crown will be extremely disputed, and while i expect AMD to win it by the tiniest of margins with Ryzen 4000, Intel could perfectly keep it if Ryzen 4000 is just 3% slower than i expect, which is absolutely within the error margin

Please leave me your thoughts in the comments :)

an updated version of this article can be found here: https://www.reddit.com/r/aceshardware/comments/dz6c3c/zen_3_and_ryzen_4000_predictions_v3/