Hacker News Reader

Comment by kfprt | Hacker News Reader

Didn't Intel already try something like this with Lakefield? It didn't go well.

Let's say the thread starts on a high performance core and enables the code paths for features the efficiency core doesn't have. How will the software know to not move the thread to the efficiency core? If it did do so wouldn't it throw errors? I frankly don't see how they can solve this problem with software and not have to recompile everything to be hybrid arch aware. In the android space everyone throws their phones away every few years so this hasn't been an issue. To me it seems like Intel is creating another Itanic situation where no one is going to compile their software to target the hybrid paradigm.

View on HN

Alder Lake fixes this issue by including all features on the efficiency cores, so a thread should be able to move between performance and efficiency cores seamlessly.

It also drops AVX-512 support entirely, presumably because the efficiency cores don’t support it and the problem you mention isn’t easily solvable.

It seems you are correct. https://en.wikipedia.org/wiki/Golden_Cove https://en.wikipedia.org/wiki/Gracemont_(microarchitecture)

Does this mean we will get RPi style Gracemont SBC's or did Intel drop that after Edison?

> It also drops AVX-512 support entirely

I wonder if Zen 4 will have AVX-512 support. If so, given that it will use a 5nm process instead of this processor's 7nm process, it will absolutely blow it out of the water.

It would be somewhat ironic to see Intel being trounced by an instruction set they invented and then stopped using!

Please, no.

AVX-512 was a mistake, causing Intel lots of issues for the benefit of a new benchmark. It heats up and clocks down the chip for other work. And it takes up too much space.

Again, please, no.

Previous iterations heated up the processor and forced it to clock down because Intel was stuck on the 14nm process.

Intel developed the instruction set and expected to rapidly shrink the die to 10nm and then 7nm, which would have fixed the power draw issues. The shrink never happened, and this then made AVX-512 look bad.

It's not AVX-512 that's at fault, it's the manufacturing process. Fix the process, and the instruction set can shine.

Many people writing vector code by hand say that they much prefer AVX-512 over its predecessors because it is complete, flexible, and powerful.

The only reason Intel didn't lose every benchmark against AMD recently is because for some workloads AVX-512 doubles throughput despite being hamstrung by the power draw and overheating problems.

A 5nm chip using AVX-512 might only need to clock down 10-20%, or not at all. Or just use turbo for a shorter period.

The manufacturing process would alter the whole chip. AVX-512 ratio would still be the same, still lead to similar issues. It was a mistake. I would not be surprised to see them undo it in same chips to get a better big.LITTLE design out since Atom does not have it.

Zen 4 [so far] from all the rumors actually seems to be competing against Intel 13th gen. (Both coming Q4 2022)

They also had to add Atom features to the "big" Core cores: UMONITOR, UMWAIT, and TPAUSE.

According to the Intel patches to LLVM, the Gracemont cores and the Golden Cove cores as configured in Alder Lake support the complete Broadwell ISA (i.e. including things like BMI1, BMI2 and ADX, which were not mentioned in the presentations).

Besides the Broadwell instructions, all the instructions supported by Tremont (the previous core in the Atom series of cores), but not by Broadwell, are also supported, plus VNNI from Cascade Lake and some of the non-AVX-512 instructions introduced by Ice Lake.

Thanks! It’s interesting because there are still problems with this model. The peak-optimized application architecture for a chip where four cores share L2 is obviously going to look different from the one where they share a slower L3, so it’s still weird to migrate for some programs. Most people aren’t going to notice.

I’m excited for this part because Tremont was never a thing normal people got to buy. I think it’s going to be a real pleasure to program these E-cores.

> How will the software know to not move the thread to the efficiency core?

There could be a dirty state flag that indicates whether vector registers or other advanced instructions were used.

> If it did do so wouldn't it throw errors?

The kernel could catch those errors and move the thread back to the performance core and resume execution at the trapped instruction and mark the thread as non-schedulable on the efficiency cores.

That could be interesting. I remember reading a report here years ago about a funny bug that was caused by the big and little cores having different endianness. Indeed the process would start on one core, process some data, get scheduled to the other core and boom, weird output. Does someone recall the story?

Haha. That sounds like a joke playing off the BIG.little name. I'd like to read about that.

Indeed. But apparently I was mistaken. It was the story about the different cache lines on the Exynos.

That seems like a too stupid bug to have existed in a production system.

However, there was a real problem a few years ago with some Samsung Exynos processors, where the cache line size was different between the big and the little cores.

A few programs made assumptions about the cache line size and had weird behavior after starting on one kind of core, then being migrated on the other kind of core.

You're probably remembering the bug where the big and little cores had different cache line sizes (https://www.mono-project.com/news/2016/09/12/arm64-icache/).

Wow. I mis remembered that quite spectacularly. Whoops.

https://medium.com/@niaow/a-big-little-problem-a-tale-of-big...

Reply on news.ycombinator.com