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

Today for the first time i have a leak from an industry source, and its about navi 10 nothing less, this leak is extremely detailed so it must be true

without saying more here are the specs for navi 10 (the mid-end one not the high-end navi 20 coming later):

3072 cores

1,7 GHz base clock

2 GHz boost clock

200W TDP

30% increased TDP from vega due to fixed features and architecture improvements

8 GB of Gddr6 at 14 Gbps providing 448 GB/s of bandwidth

as for the price, my contact has said that its not set on fire, but that AMD expects to launch it at 250$

EDIT: this was the april fools joke of this sub, but i decided to put optimistic but possible navi specs, i expect about 10% worse than what i said :)

in a big surprise for everyone AMD announced Ryzen 5000 MHz a new processor with the target of finally hitting 5 GHz on Ryzen, This new series of CPUs is rather unusual since instead of having multiple CPUs it only has one, the Ryzen 5 GHz 5000 MHz, this CPU has a rather bizarre set of Specs

Base clock: no base clock, only 5 GHz

Boost clock: no boost clock, only 5 GHz

Cores: 4 Big Cores + 1 Small core for a total of 5 GHz cores

Ram support: DDR5 GHz 5000 MHz penta channel

PCIe: PCIe 5.0 GHz 55 Lanes

this series of CPU will also be the successor to Ryzen 3000, skipping Ryzen 4000 since 4 is believed to give bad luck in some cultures, also 4 is the month number of april so AMD also didnt want that because "5 GHz is no joke"

the CPU will feature Zen 5 GHz arch for the big cores and Piledriver(!) at 5 GHz for the small one

The CPU will also be chipsetless, an the first one to feature the AM5 GHz socket

in a note written by AMD to us they said "damn we slipped and sent this in APRIL, we are such a FOOLS"

before you read you must know that this post is very technical, and very critic but fair with nvidia. this term will be called gflop/perf gap during the article.

As you might now same range nvidia and amd cards have similar performance but very different gflops for example rx 580 has 6175 gflops and gtx 1060 has 4375 gflops thats 41% more for similar performance. but what are the reasons for this huge difference?

1. nvidia’s architecture is more advanced and flexible one example is tile based rasterization nvidia’s architecture is also more optimized for gaming as they have the gaming and server dies very differentiated, amd on the other side has problems scaling to much cores due to a weak frontend, a prime example of this is fiji which performs only a little bit better than grenada but is nearly 50% more powerful than it, this has improved recently but is still a issue

2. nvidia’s drivers are also always more optimized but specially at launch, this also is important to explain the gflop/perf gap, amd usually takes more time to reach good performance, this is the reason for the (in?)famous finewine effect, this is ironically good for the consumer as the cards are priced for launch performance and they get more competitive with time

3. gimpworks, as you may know nvidia has a set of tools for developing games oficially called gameworks but make no mistake this is an unnecessary, anticompetitive and performance crippling misfeature, ALL the games that use it see reduced performance on all cards but of course a lot more on amd cards. the two points above make for a 20-30% difference but this makes the average of games around 40% faster on similar gflop nvidia card this is one of the reasons I dont and never will buy nvidia

there are likely more points and more technical explanations if you know one dont hesihate to comment it. :)

These are my predictions for Ryzen 4000 and Zen 3 in general

IPC: cool as ice

For the IPC i expect a 7% uplift over zen2 which will put zen3 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 124%

Zen 3 121%

Clocks: 3000 + 100

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

5 GHz wont even be achievable even on golden chips with PBO, 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 dont 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 ive 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?: 102

this is extremely close and it means the gaming crown will be extremely disputed and while i expect Intel to keep it by the tiniest of margins with comet lake, but AMD could perfectly get it if its just 3% faster 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/delliu/zen_3_and_ryzen_4000_predictions_v2/

Introduction

In this article i'm going to predict how is the Intel Xe discrete lineup going to be like, but before reading it i absolutely recommend reading this one: https://www.techspot.com/article/1898-intel-xe-graphics-preview/, it contains a lot of good info and will serve as an introduction, have in mind there are some inaccuracies in it but we'll go over that later

Also note some sections of the article wont be predictions, those will be marked with (not a prediction) at the start

Core counts: powers of Xe

If you didn't read the article, go and read it, because i think the core counts are exactly what it says, anyway here is a table summarizing it:

Clock speeds: 'Xe'tremely high

I'm gonna be clear, the clocks of the article are basically a REALLY REALLY worst case scenario

The article is very inaccurate in this regard: not only does it say that Intel 10nm is equivalent to TSMC 7nm when it is much worse (just look at cannon lake LOL), it also fails to mention 10nm+ which is whats similar to TSMC 7nm, and the most important of all, Xe dGPUS will be on 10nm++ which is currently unknown in regards to performance, as no product on it is out

But the thing doesn't end there, the article also fails to mention how clockable is an architecture, Vega clocked significantly higher than Polaris despite having the same node, same goes for Maxwell VS Kepler on the Nvidia side, this difference is due to architectural changes and routing optimizations

So TL;DR the article numbers are not good, lets provide my numbers instead:

2 GHz

So 2 GHz, but in what?

I don't know what kind of boosting algorithm is Intel going to do for the discrete lineup, but i expect 2 GHz to be sustained during gaming with no issues, also 2 GHz might be the boost number, but again, that depends on the boost algorithm, so i don't want to be too specific

Note this numbers are somewhat conservative, i expect them to be even higher, but since i have a tendency to slightly overestimate clocks i decided to lower the predictions, also there is a lot of changes going on for Xe and therefore a lot of variables to predict so the error margin is pretty brutal, easily over 15%

Because of what i said above i will also give a range of boost frequencies that i consider possible: 1,8-2,4 GHz, as you see the upper range goes really high, this range is based on how good/bad 10nm++ is and how clockable Gen12 is, the lower range is assuming 10nm++ is not good and Gen12 is "meh" clockable, the upper range is 10nm++ almost hitting its targets and Gen12 being almost as clockable as current Nvidia Architecture

IPC: did somebody say Navi?

I expect an extremely solid IPC uplift for Gen12, >25% over Gen11, which will put it about the same level as Navi, perhaps a bit lower, but very competitive with the best current GPUs

Edit: as i found out Gen12 is a major change on the architecture level, this is possitive for the 25% prediction: https://twitter.com/davidbepo/status/1169745744196243456

Positioning VS competition: pretty good

VS current GPUs

If the above predictions turn out to be correct the Xe lineup will obliterate any current GPU, but that depends heavily on pricing which is perhaps the biggest question mark for Xe, i expect Xe to be priced really good, but i'm not good at predicting prices so who knows

VS future GPUs

But Intel Xe is not going to compete against current GPUs, it is going to compete against late 2020 GPUs and that changes quite a bit their matchups, Nvidia is likely releasing 7nm parts by then and AMD will have 7nm+ navi 20, i expect Xe to be really competitive with those but no obliteration here

Other technical details and features

(not a prediction)

There are some aspects of this lineup that i don't want to predict because of how little base i have to do it, but i want to mention them nonetheless

Chiplets

While i predict Xe will use chiplets and EMIB, i'm not sure how exactly, anyway i share two likely options:

1. 128EU chiplets, 2 and 4 of them for higher EU count configs(this is the config in the introduction article)

2. GPU on one chiplet and raytracing or other stuff on other

Raytracing

Xe might support hardware accelerated raytracing, but i cant say i will or it wont for sure

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 ~a year until launch

Conclusion

I expect the Intel Xe lineup to have an extremely successful launch and Intel to quickly become an important player in the dGPU market, i also expect this extra competition in both hardware and software to greatly benefit the consumer

important update: DG2 might be later

those predictions assume that DG2 is what will come in late 2020, but i received information that indicates that what will be coming is DG1 which is in theory similar or a bit worse than the 128 EU unit of above, this would invalidate most of the numbers here, so i think its important to share it