I regard them as unusually rational choices given their problem with power usage, and pressure from all sides by those who do better there. Several of the changes also seem like responses to efficiency problems with other products that are relatively recent, although given the time it takes to design these things, perhaps Intel foresaw their upcoming issues with chiplet efficiency, with E-cores being unable to save power due to everything else around them, and also with the low-power island (I speculate) being too limited.
Intel certainly has a good chance to win battery benchmarks. In actual usage, though, the other processors are quicker to complete any interactive tasks asked of them. So it'll be a battle of two philosophies: 1. don't ever power up into the high wattages, and 2. "race to sleep" and then power down again sooner.
I was thinking about that with all the first-gen "AI machines" and 16G of RAM. Surely that will seem a bit restrictive as AI models develop? I imagine the trend will be towards larger models, and the rest of the desktop experience has to fit there, too.
They went all-in. Everything not meeting an actual need was thrown overboard. Compare that to Qualcomm with 12 cores, swinging wildly at those benchmark wins. Has AMD or Qualcomm split their 12 cores into 4 & 8? Who will take the efficiency crown? I can't recall there ever having been so much happening at once before.
Agreed, even set the moment most of the better LLMs need more RAM than that. Mixtral is around 48gb. 32 is okay but really there should be a 48 and 64gb option for future proofing. Especially considering the GPU will be eating a reasonable amount of the RAM.
It's a 4 performance core laptop part with on package RAM, you didn't expect it to replace a 4090 right?
Helps at the very least by removing a layer of testing from speculative execution rollback?
CAMM2 will be for Arrow Lake. Lunar Lake is low power mobile to compete with Qualcomm Snapdragon. 16-32GB of RAM is plenty for that, and no point in expandable memory for compact devices; main point of the on package RAM is to save space that can be used for bigger batteries.
E-cores are in 4-core clusters on Meteor Lake and Raptor Lake (excluding the LP E-cores on Meteor Lake.)
It's RAM that has to cover both GPU and CPU, I personally consider 32GB about minimum for serious work. A 4080 with 16GB is likely in a system with at least 32GB of RAM, giving 48GB total on less balanced builds it'll have at least 16GB for the CPU and 16 for the GPU.
Oooo nice find on Chips and Cheese' Lion Cove preview, I had seen a bunch of others (including Anandtech's poorly apparently AI-written tripe, so sad to see them fall
), and Chips and Cheese definitely looks the most through of what I've seen so far.Yeah, unless your phone is running some virtual machines/containers or a LLM locally, it is probably more than really needed. 16GB seems like a ton for a phone. 24GB seems silly. I'm sure it can fill it all up with something but having a bunch of junk cached that you will never need isn't really effective in a lot of cases, you're just burning battery for nothing.
Again, this is a low power 4 big core + bunch of E cores part. If it comes anywhere near the power of a desktop it's mission accomplished.
This is customized for mobile-only and ported to TSMC, so likely they removed as much of the avx512 hardware as they could to reduce costs. Arrow Lake is the version that will be shared with Xeon servers and so that would be the one (if any) with AVX512 present but disabled in the consumer hardware.
I feel like I say this at least once a month, but putting RAM on package does not make it faster; the speed of DDR5 and LPDDR5X are not determined by the package they are put in, but by the internal timings and rise times of the DRAM module. You might save a bit of power by keeping traces short, but the memory doesn't actually get faster just because it is closer. There is a maximum distance you can route DDR memories due to signal integrity, but it is pretty long and not a real limitation. That is why we are going to DDR6 at 12800 MT/s on DIMMs with JEDEC timings, and overclocked (socketed!) modules closer to 16000-20000 MT/s. Physically you can send data at those frequencies over PCB traces.
Xeons will almost certainly still have it due to the perf/watt gains for multithreaded code. Removing it only makes sense if you want to optimize the P cores for single thread performance exclusively, which is not what 60 core Xeon servers are about.
Xeons will definitely have it, don't get me wrong. My proposal is this-- drop SMT and use all that saved space on e-cores, see how that measures up.
Judging by the evidence that we already have, adding SMT2 to a wide & fast P-type core yields >20% more peak throughput for <10% larger silicon area. In more concrete numbers: if 5 P cores (without SMT2) are our reference point, then adding SMT2 to them requires the die space of 5.5 original P cores, but yields peak throughput of 6 P cores. Downside is that the software in question must spawn 10 rather than 6 threads to reap that peak throughput.
My own worst workload, clicking build to running in ~4 minutes on the M3 pro, double that on an 5800X, is both together. Some parallel parts using all the cores, some low threaded parts running on just one or two threads.
Excellent post, and makes total sense. Certainly at the consumer level the weights change, and it would make more sense there.
