Does anyone actually care at all about frequencies? I care if my task finishes quickly. If it can finish quickly at a low frequency, fine. If the clock runs fast but the task doesn't, how is that a benefit?

My understanding is that both Intel and AMD are pushing high clocks not because it's what consumers want, but because it's the only lever they have to pull to get more gains. If this year's CPU is 2% faster than your current CPU, why would you buy it? So after they have their design they cover the rest of the target performance gain by cranking the clock, and that's how you get 200 W desktop CPUs.

>the commitment to higher memory bandwidth via on package memory; being able to count on higher bandwidth means you can expect to have more operations that are waiting on execution rather than waiting on memory, so wider execution has more benefits.

I believe you could make a PC (compatible) with unified memory and a 256-bit memory bus, but then you'd have to make the whole thing. Soldered motherboard, CPU/GPU, and RAM. I think at the time the M1 came out there weren't any companies making hardware like that. Maybe now that x86 handhelds are starting to come out, we may see laptops like that.

▲

Yizahi 4 days ago | parent [-]

It's only recently when consumer software has become truly multithreaded. Historically there were major issues with that until very recently. Remember Bulldozer fiasco? They bet on the parallel execution more than Intel at the same time, e.g. same price Intel chip was 4 core, while AMD had 8 cores (consumer market). Single thread performance had been the deciding factor for decades. Even today AMDs outlier SKUs with a lot of cores and slightly lower frequencies (like 500 MHz lower or so) are not a topic of the day in any media or forum community. People talk about either top of the line SKU or something with low core count but clocking high enough to be reasonable for lighter use. Releasing low frequency high core count part for consumers would be greeted with questions, like "what for is this CPU?".

▲

fluoridation 4 days ago | parent | next [-]

Are we just going to pretend that frequency = single-thread performance? I'm fine with making that replacement mentally, I just want to confirm we're all on the same page here.

>Releasing low frequency high core count part for consumers would be greeted with questions, like "what for is this CPU?".

It's for homelab and SOHO servers. It won't get the same attention as the sexy parts... because it's not a sexy part. It's something put in a box and stuff in a corner to chug away for ten years without looking at it again.

▲

wmf 3 days ago | parent | prev | next [-]

low frequency high core count part for consumers

That's not really what we're talking about. Apple's cores are faster yet lower clocked. (Not just faster per clock but absolutely faster.) So some people are wondering if Intel/AMD targeting 6 GHz actually reduced performance.

▲

gigatexal 3 days ago | parent | prev [-]

But the OS has been able to take advantage of it since mountain lion with grand central dispatch. I could be wrong with the code name. This makes doing parallel things very easy.

But most every OS can.

	▲	astrange 3 days ago \| parent [-]
		Parallelism is actually very difficult and libdispatch is not at all perfect for it. Swift concurrency is a newer design and gets better performance by being /less/ parallel. (This is mostly because resolving priority inversions turns out to be very important on a phone, and almost noone designs for this properly because it's not important on servers.)