Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel's New Chimera: Alder Lake

agner.org

Post reply on HN
Print view View original

131–140 of 253 posts

Re: Intel's New Chimera: Alder Lake

#131

Post by zasdffaa »

jiggawatts wrote: post #126
zasdffaa wrote: post #84

Earlier quoted context omitted.

I've not used columnstore in MSSQL but in fact I likely know more about the innards of MSSQL than you. WRT memory, all I mant was that if your working set doesn't fit in RAM, you're screwed regardless. Nothing will save you, so check that first. I don't know what your 70GB means in this context - please check. > It then parallelises this across all cores/hyperthreads, so I get 100% utilisation on 16 cores. that sugge…

I do know a thing or two about MS SQL optimisation also. 8) So keep in mind that the SSD I'm referring to can read at 7 GB/s. Not seven gigabits... 7 gigabytes per second. I've benchmarked some not-so-old servers (the entire box, not a VM!) as capable of only 35 GB/s streaming reads from main memory! So these days "disk" is more like "5x slower memory". It used to be 100-1000x slower. I told one customer to get a 16x…

SSDs will have higher latency than ram, and I seriously wonder if they actually can hit 7GB/sec, or only theoretical. Ram is faster, always, in latency and bandwidth.

> I've benchmarked some not-so-old servers (the entire box, not a VM!) as capable of only 35 GB/s streaming reads from main memory!

Then you have either a low-end server or something is very wrong (I think you benchmarked wrong, see below). You should be getting maybe 15 GB/sec per channel, so 4 channel = 60GB/sec, for a decent server you may well have 6 or 8 channels. (figures may be a bit off but 35 is puzzling me).

You may have measured on a single core, but each core has its own mem reading stuff so it should multiply up if your benchmark uses extra cores.

Anyway, I have to get back to work on my dual-core haswell. Good luck!

(Edit: 15 * 4 = 60, not 80, corrected)

Re: Intel's New Chimera: Alder Lake

#132

Post by zasdffaa »

esyir wrote: post #122
kouteiheika wrote: post #57

Earlier quoted context omitted.

> wtf do you need more cores for??? Wat are you doing? I have a bunch of embarrassingly parallel workloads which I have to run regularly (text analysis, machine learning which is not easily accelerated on a GPU, etc.). > consider buying a server. I looked into it; not really an option. Those are vastly more expensive, really loud (I need a quiet workstation), have significantly lower boost clocks (I also need single-…

Nobody said you needed an enterprise grade server. A simple desktop with proxmox or something installed would work just fine.

Err, I did

Re: Intel's New Chimera: Alder Lake

#133

Post by zozbot234 »

sorenjan wrote: post #129
moffkalast wrote: post #127

Earlier quoted context omitted.

Well it would make some sense to have perhaps 2 or 4 single core speed focused cores for the main process that you're currently working on, and then add as many of the smaller E cores as you can, to handle the hundreds of background processes so that the P cores can run uninterrupted by them. If this works that way in practice is anyone's guess though.

I think a single E core can handle all the background processes when they're not doing any real work. I currently have around 250 processes and 3500 threads running on my computer, and the CPU utilization is 1%. It would probably make sense to use an extremely power efficient core that's only used for background services, one core that could be clocked much higher than all the rest for the foreground thread(s), and m…

> It's clear that we need something in between regular quad core CPUs, and GPUs connected through PCIe. Some kind of parallel compute unit should be standard in pretty much all CPUs (or SoCs) eventually.

So, an iGPU accessing unified RAM?

Re: Intel's New Chimera: Alder Lake

#134

Post by native_samples »

can16358p wrote: post #14

Perhaps the easier option would be DRM software and anything that needs instructions that are only on a specific core type, stick to those cores. It might reinvolve changes to DRM software but looking at the current compromises, looks like a better deal. Of course Intel should have thought of this and didn't pick this route. I'd love to see the reasoning though.

Intel is in general heavily constrained by whatever Microsoft chooses to do with Windows. It's not like Apple where they can introduce a new hw feature and then immediately use it in the operating system. For example the M1 Macs have the big little architecture integrated with Grand Central Dispatch. Many, many interesting Hardware features have died in the Intel world because the Windows team simply did not add good enough support for it and there was nothing Intel could do.

In this case detecting DRM software and scheduling it differently would require sophisticated support in the operating system, or even ideally DRM support implemented by the operating system. However these things are probably beyond Microsoft's capabilities in its current state.

Re: Intel's New Chimera: Alder Lake

#135

Post by Klasiaster »

Traster wrote: post #80

You get a bunch of smart hardware guys into a room, they design this funky exotic architecture. Then the software goes "Allocate these threads to whatever is idle" and suddenly you've completely lost any possible advantage and are thrashing around with no idea what you're doing. The big-little architecture from Apple was accompanied by software that basically handles that for you. From what I heard there were similar…

So true, my experience with the BIG.little ARM platform and a regular Linux kernel is that you always end up with the wrong scheduling and the system underperforms because it uses the little CPU for a compute-intensive single-thread task… I'll just avoid these kind of systems.

Re: Intel's New Chimera: Alder Lake

#136

Post by adrian_b »

inkyoto wrote: post #120
paulmd wrote: post #82

Earlier quoted context omitted.

Variable-width is the new hotness but it doesn’t work well on all tasks. If your task is fixed-width, or the algorithm changes based on task width, you kind of need to know the hardware width. And shuffling, perjuring, swizzling, and bit-shifting don’t translate very well to these approaches. Nor is there really an easy way to operate these in a fixed-width mode. https://gist.github.com/zingaburga/805669eb891c820bd22…

> Variable-width is the new hotness […] Hardly new. The VAX 6000 Series Vector Processor supported variable length vectors with up to 64 vector elements: With the VAX, the vector register has a maximum length of 64 elements. Each element can contain up to 64 bits. The elements used can be enabled or disabled by setting bits in a Vector Mask Register (VMR). The programmer usually determines the range, or limits the nu…

Variable length vectors have been available much earlier than any VAX.

The most notorious vector computer is Cray-1 from 1976, and it already had variable length vector operations using a vector length register (and also 64-element vector registers).

All later vector computers and also both the vector extension of the RISC-V ISA and the SVE extension of ARM have been strongly inspired by the ISA of Cray-1.

CDC STAR-100 introduced a few influential ideas, but it had a low performance because it did not have vector registers (the operands of its vector instructions were arrays stored in the main memory).

Re: Intel's New Chimera: Alder Lake

#137

Post by hyperbovine »

delusional wrote: post #46
em500 wrote: post #37

Earlier quoted context omitted.

The top Alder Lake desktop CPU has 16-cores, 8P+8E, compared to 8P in the 11-th gen. The E cores get around half the performance of the P cores, so the 8P+8E is get roughly the performance of a hypothetical 12P+0E CPU. The very high core parts are reserved for Xeon (a 56 core Alder Lake Xeon has been leaked, but I think the P/E split is still unknown). What people need to realize is that a P cores takes around 4 time…

It's worth making it explicit that many home computing tasks are highly parrallelizable because the work is actually completely separate programs. If you watch a video while writing a document in word, that's trivially parrallelizable.

I should not like to have to read that document.

Re: Intel's New Chimera: Alder Lake

#138

Post by q-big »

native_samples wrote: post #134
can16358p wrote: post #14

Perhaps the easier option would be DRM software and anything that needs instructions that are only on a specific core type, stick to those cores. It might reinvolve changes to DRM software but looking at the current compromises, looks like a better deal. Of course Intel should have thought of this and didn't pick this route. I'd love to see the reasoning though.

Intel is in general heavily constrained by whatever Microsoft chooses to do with Windows. It's not like Apple where they can introduce a new hw feature and then immediately use it in the operating system. For example the M1 Macs have the big little architecture integrated with Grand Central Dispatch. Many, many interesting Hardware features have died in the Intel world because the Windows team simply did not add good…

I would rather say that if such a CPU breaks DRM software, this should be considered a feature.

Re: Intel's New Chimera: Alder Lake

#139

Post by PartiallyTyped »

adam_arthur wrote: post #22
kouteiheika wrote: post #16

Personally I don't really see a point in having a hybrid architecture like this unless it'll lead to massively increased core counts, and so far it doesn't look like it does. AMD still beats Intel in both core counts and power efficiency, and they're only using P cores so... what's the point of having E cores? But maybe that's just because it's a first generation technology for Intel? I hope things improve in the fut…

AMD beats them because they are a process node ahead. Dunno why every comment implies there's some design gap that leads to M1 or AMD being more powerful or efficient. It's 90% the process node. There is no magic design sauce that makes those chips better. The big/little design change did seem to improve performance quite a bit for Intel, even using the same manufacturing node as before

AMD does not beat Intel [1] unless we limit the CPUs to the same wattage (see efficiency benchmarks below).

[1] https://www.tomshardware.com/uk/news/ryzen-7-5800x3d-vs-core...

Re: Intel's New Chimera: Alder Lake

#140

Post by layer8 »

mrath wrote: post #2

I don't have an idea on CPU design. Can this lead to M1 like performance?

Compared to the M1, Intel is still restricted by the existing memory and I/O interfaces and by x86 compatibility, which means they can’t do certain things the M1 did, like the integrated unified memory (for massive memory bandwidth) and the relaxed memory model. And as the siblings explain, the P/E design is more about power efficiency than about performance, although the increased power efficiency does allow for more cores at the high end.
Post reply on HN