Why Apple does not list the CPU speed of Silicon Macs?

[theorist9]

I hope so. I plan on riding my 2020 for as long as I can. Running 2 extra 27" 4K screens, but rest of my needs are small, 1 TB internal only used for system, everything else goes on an external 4TB Thunderbolt drive, TMs to a 4 TB SSD, which CCCs to an 8TB GDD and with unlimited Backblaze Im set.

My other huge caveat is moving away from Catalina. New OSes look like candy crush to me. hate them. Cnat stand the wifes and kids M1s on Ventura. I have a dozen clients, and my workflow is a lot of moving around in Finder accessing files, Cat is far, far far cleaner. One click to access anything.

View attachment 2184180

Do you mean cat in Terminal?

What I'd like is something like LaunchBar, except for files instead of apps. I use LB to find frequently-used files, but doesn't work as well for them. I have to give them special short names.

I'm pretty happy with Monterey. I tried Ventura, but the rendering was messed up--it gave me a headache. I could have tried recalibrating* but didn't want to bother, since Monterey works well for me, so I just switched back. I've read there's a color bug.

*Text doesn't look optimal for me until I've calibrated each of my monitors with my iRite colorimeter. Usually one needs to recalibrate for each new OS, but the difference in going from Monterey to Ventura was much greater than it should have been, suggesting to me something funky was going on.

 

[kschendel]

I've not yet made the transition to AS, and I'd be really curious to see if that's the case for routine office operations. But based on my experience with my 2019 i9 iMac, I'd expect it's not. That's a relatively fast machine, yet I experience repeated irritating delays of 0.5 s – 3 s for routine operations with Office apps—like clicking between cells in Excel—often accompanied by spinning beachbballs. AS would need to reduce these at least 10-fold for them to become imperceptible, yet I'd expect AS to be only about twice as fast as my i9 iMac for such operations. ...

Geez. How big / complicated are these Excel sheets? I'm running a late 2013 rMPB with a 2 GHz Haswell CPU, and I've never run into anything like that. On the other hand I'm not running large corporate budgeting sheets either. I find myself wondering if you're really CPU limited, or if it's memory and/or Excel paging large sheets to storage somehow.

 

[theorist9]

Geez. How big / complicated are these Excel sheets? I'm running a late 2013 rMPB with a 2 GHz Haswell CPU, and I've never run into anything like that. On the other hand I'm not running large corporate budgeting sheets either. I find myself wondering if you're really CPU limited, or if it's memory and/or Excel paging large sheets to storage somehow.

I do run some big ones, but size doesn't seem to affect this behavior. I see it even on my smaller sheets. And I don't know what's causing it. Excel, like most Office programs, is a very large, complicated kludge that's been built up over a few decades. Some with Intel Macs reports the same thing; others with Intel Macs (like yourself) do not.

I've got plenty of memory (128 GB total), the vast majority of which remains unused except when I'm doing scientific computing.

I think it has to do with Excel not working as well on the Mac as on Windows, since Excel has far less delays on my PC even though my Mac is newer and faster.

I did try working on my spreadsheets in a 64 GB RAM disk, and that appeared to help a bit (still had the beachballs, but they appeared to go away a bit more quickly), but it's hard to tell since the beachballs aren't repeatable and thus amenable to timing.

 

[Vref]

Because the marketing people said it wouldn’t be a good idea?

 

[badgerbadgerx2]

Catalina. See my last screen shot, which is using xtraFinder to restore color labels and sidebars. xtra finder Has a TON of finder customization.

XtraFinder add Tabs, Dual Panel, and numerous features to Mac's native Finder

www.trankynam.com

I only color calibrate my iMac screen, I dont bother with the others

 

[mr_roboto]

But *everything* I have read, watched, questioned, touched, etc, says M chips make 64 GBs look like 128.

You may have read it in many places, but it was all urban myth.

Putting aside the tangent of VRAM, which has already been covered, broadly speaking, applications use memory for two things:

1. Program code
2. Data

When it comes to #1, arm64 is more dense than x86. That means if you recompile the same source code for arm64, the binary will be smaller than the x86-64 binary. But this is a small effect, no more than 10% on average IIRC. Furthermore, in most cases (particularly the most memory-hungry apps), code uses much less RAM than data.

So what about #2, data? Well, in macOS, all arm64 data formats are literally identical in size to their x86-64 equivalents. No change.

The only remotely plausible idea I've seen along these lines is that Mx Macs can swap faster than the old Intel Macs, meaning that in circumstances when you don't actually have enough RAM and the computer is swapping, an Apple Silicon Mac may maintain a higher fraction of its normal performance than an Intel Mac would. This is probably true to some extent. But even if we assume this is so, this is only unlocked by not having enough RAM to run the programs you want without swapping, and swapping still robs you of a lot of performance.

 

[badgerbadgerx2]

Sure, thats plausible. In the long past, the issue with running out of ram and hitting the drive for "swap" meant hitting a slow HDD. SSDs helped and now flash Drives help even more.

As with many discussions here, some of this is specific to the user. No one on this board has the same workflow and application use as I do.

The only actual true way to test what I have seen is to have a 64 GB studio on my desk and run the same daily tasks and see what the numbers say. Again, going bu what other have said to me, and watching the rest of my family run 8 GB on their M1s without issues, Im more optimistic than not.

 

[Analog Kid]

Because the marketing people said it wouldn’t be a good idea?

More likely the marketing people were told it's not a good idea an sent back to their caves.

 

[Analog Kid]

I have 128 Gb in 2020 iMac as well. My usage is different, Im all Adobe CC for print, not web, pushing some very large PSD files and 100 page magazines. ID< AI< PS< Acrobat < DW, multiple browsers all day -- and I hit swap often.

But *everything* I have read, watched, questioned, touched, etc, says M chips make 64 GBs look like 128. So would be OK with trying it. I feel ya, to replace my 2020 iMac is a $4000 spend. Studio display + 64/1TB Studio. (I only need a small internal) Jumping from a $3000 studio to a $5000 studo for 128 Gb ram doesnt seem like a good use of $.

I just think comparing Intel ram use to M ram use is not the same?
View attachment 2184058

There are nearly identically the same. Most of your RAM is consumed with data and the data will look the same no matter which 64bit platform you're running on.

Code will be slightly different, but ironically the whole point of CISC was to reduce the memory footprint of code (memory used to be expensive) so the Intel code segment may be a touch smaller. It's not enough to make a difference at the Activity monitor level-- code is much much smaller than data.

 

[MallardDuck]

On a fresh install of Windows 11 ARM, the performance for desktop apps (Office, etc.) is tolerable. I've not tried (nor require) anything more sophisticated on Windows.

It's ok for games that don't need significant GPU support. Think Dragon Age: Origins, but not Insurrection or mass effect.

 

[leman]

The only remotely plausible idea I've seen along these lines is that Mx Macs can swap faster than the old Intel Macs, meaning that in circumstances when you don't actually have enough RAM and the computer is swapping, an Apple Silicon Mac may maintain a higher fraction of its normal performance than an Intel Mac would. This is probably true to some extent. But even if we assume this is so, this is only unlocked by not having enough RAM to run the programs you want without swapping, and swapping still robs you of a lot of performance.

To add to this, Apple has hardware assisted memory compression, so they can pack more inactive memory pages into RAM without any performance overhead. This is particularly effective for modern desktop multitasking, where you can have a bunch of heavier open apps but only few are actually performing active work. The RAM for the apps on the background can be parked/compressed, making the system more responsive overall. And decompression is faster than application switching animation. Combine this with larger memory pages and low-latency swap and you have a system that reacts snappily even under heavy memory contention.

Of course, none of this will help you if your active work actually needs a lot of RAM (that is, if the data access is random across a large set of memory objects). I think this is the main source of confusion in these things.

Code will be slightly different, but ironically the whole point of CISC was to reduce the memory footprint of code (memory used to be expensive) so the Intel code segment may be a touch smaller.

ARM64 produces both smaller code and less instructions on average than x86-64, because ARM64 packs more information per instruction. In fact, it’s the most dense of mainstream ISAs at the moment. Only compressed RISC-V produces smaller code (but still needs more instructions). That awkward moment when RISC is more CISC than actual CISC…

 

[Analog Kid]

ARM64 produces both smaller code and less instructions on average than x86-64, because ARM64 packs more information per instruction. In fact, it’s the most dense of mainstream ISAs at the moment. Only compressed RISC-V produces smaller code (but still needs more instructions).

Hm. Thumb, or the full instruction set? Do you have any data that demonstrates that? The best I'm finding is this:

https://research.cs.wisc.edu/vertical/papers/2013/isa-power-struggles-tr.pdf

Which is kind of a mixed bag and targeting very small benchmark applications. It's all 32bit too. Bytes per instruction is definitely lower for x86, but Arm seems like smaller binaries for floating point and some server benchmarks. Some of those seem like aberrations though, so it's hard to tell.

If those numbers are to be trusted, then it implies that x86 succeeded in reducing the number of bytes read per instruction but that they need more instructions to perform the same work-- which would mean that CISC failed at the one thing it was supposed to be good at.

[Note to the peanut gallery: I don't want to get into the whole "there's no such thing as CISC or RISC" pedantry-- the truth is x86 was designed to do more with more complex instructions that require more sophisticated decoding and Arm was designed to use simpler instructions and a more predictable decode path. Yes it's more complicated than that but forgive the shorthand.]

Caveat aside, is this an indication that modern x86 code is using more RISC like instructions within the x86 instruction set to gain performance over code density and are out RISCing Arm at their own game? That would just be more evidence to me that modern code uses far fewer of those crufty instructions and Intel needs to wack the legacy instructions over a generation or two and produce a more svelte, less backwards compatible core to compete.

 

[Xiao_Xi]

ARM64 produces both smaller code and less instructions on average than x86-64, because ARM64 packs more information per instruction. In fact, it’s the most dense of mainstream ISAs at the moment. Only compressed RISC-V produces smaller code (but still needs more instructions).

In summary, when RISC-V is using fewer instructions relative to other ISAs, the code likely contains a significant number of branches. When RISC-V is using more instructions, it is often due to a significant number of indexed memory operations, unsigned integer array indexing, or library routines such as memset or memcpy.

[1607.02318] The Renewed Case for the Reduced Instruction Set Computer: Avoiding ISA Bloat with Macro-Op Fusion for RISC-V

arxiv.org

 

[leman]

Hm. Thumb, or the full instruction set? Do you have any data that demonstrates that?

This is 64-bit ARM. Data: https://www.bitsnbites.eu/cisc-vs-risc-code-density/

[Note to the peanut gallery: I don't want to get into the whole "there's no such thing as CISC or RISC" pedantry-- the truth is x86 was designed to do more with more complex instructions that require more sophisticated decoding and Arm was designed to use simpler instructions and a more predictable decode path. Yes it's more complicated than that but forgive the shorthand.]

Yeah, but this is all hidden behind legacy cruft of several decades. What’s most relevant is that ARM64 is a clean, relatively new design, that aims for ease of decode and maximizing useful information per instruction.

Caveat aside, is this an indication that modern x86 code is using more RISC like instructions within the x86 instruction set to gain performance over code density and are out RISCing Arm at their own game?

I think this is simply an indication that RISC vs. CISC is an outdated dichotomy that trivializes the complexity and design choices that go into a modern ISA. While RISC-V does follow the RISC philosophy to the letter, they pay for it in other ways.

View attachment 2184981

[1607.02318] The Renewed Case for the Reduced Instruction Set Computer: Avoiding ISA Bloat with Macro-Op Fusion for RISC-V

arxiv.org

From the paper you quote: “However, we observe that on SPEC CINT2006 RV64G executes on average 9% more instructions than ARMv8”

 

[mr_roboto]

To add to this, Apple has hardware assisted memory compression, so they can pack more inactive memory pages into RAM without any performance overhead.

They may have hardware assist in theory, but in public Darwin kernel source releases the page compression and decompression routines don't use it. And memory compression has been part of x86 macOS for ages and ages, far longer than Apple Silicon Macs have been a thing.

 

[mr_roboto]

Hm. Thumb, or the full instruction set? Do you have any data that demonstrates that? The best I'm finding is this:

https://research.cs.wisc.edu/vertical/papers/2013/isa-power-struggles-tr.pdf

You can get some comparison data from your own Mac. Most apps are "fat" binaries containing code for both architectures, typically compiled from exactly the same source code with similar compiler settings. You can use the 'otool' command in Terminal.app (requires you to have installed Xcode, or at least the Xcode command line tools) to dump info. Here's an example from my machine, leaving out many lines of output not relevant to the relative size of Arm and x86 code.

% otool -fv /Applications/Numbers.app/Contents/MacOS/Numbers architecture x86_64 size 16513632 architecture arm64 size 15277168

Caveat aside, is this an indication that modern x86 code is using more RISC like instructions within the x86 instruction set to gain performance over code density and are out RISCing Arm at their own game? That would just be more evidence to me that modern code uses far fewer of those crufty instructions and Intel needs to wack the legacy instructions over a generation or two and produce a more svelte, less backwards compatible core to compete.

No, it's something else entirely. When AMD extended the i386 ISA to 64-bit, they took a very conservative and backwards compatible approach. They kept nearly all existing 32-bit instruction encodings, so all new "long mode" instructions which do one or more of these three things had to be encoded with an additional new prefix byte (REX):

- use 64-bit operand size in an instruction which doesn't default to 64-bit operand size
- use any extended register added by AMD64 (R8 to R15, XMM8-15, YMM8-15, CR8-15, or DR8-15)
- use one of the uniform byte registers SPL, BPL, SIL, or DIL

Thus, 64-bit x86 instructions are at best the same size as 32-bit instructions, but more often larger. If you write code to do exactly the same thing as before, just on 64-bit data values instead of 32-bit, it is likely to grow in size simply because REX instruction encodings are bigger.

This is mitigated somewhat by the availability of an additional 8 general purpose and vector/FP registers. Compilers can take advantage of these to emit fewer stack spill and fill instructions, i.e. the same job gets done in fewer (but individually larger) instructions. Nevertheless, on average, x86-64 code is less dense than i386 code.

What you suggest re: "wack the legacy instructions over a generation or two" isn't likely to happen any time soon. "Legacy" i386 instructions are still a fully legitimate part of x86-64. Compilers still emit them, software still uses them (if you don't need to do a 64-bit computation and the instruction doesn't use any of the extended registers, why use the longer REX encoding?). So you're talking about literally abandoning compatibility with Windows and all its software.

The time to do something like that would have been when AMD came up with AMD64. They could have done something a bit more like what Arm did with 64-bit, where the 64-bit Arm ISA uses a fundamentally new encoding scheme that is 100% incompatible with 32-bit Arm. (An Arm CPU in 64-bit mode cannot decode 32-bit Arm instructions, and vice versa.) But that didn't happen because at the time, AMD had no power to make anyone adopt a fundamentally new ISA, so they had to go with not rocking the boat much in hopes that Microsoft would see their design and like it as a way to bridge the entire existing 32-bit x86 ecosystem into the 64-bit era. Which Microsoft did, and that's how AMD64 got adopted.

 

[theorist9]

You can get some comparison data from your own Mac. Most apps are "fat" binaries containing code for both architectures, typically compiled from exactly the same source code with similar compiler settings. You can use the 'otool' command in Terminal.app (requires you to have installed Xcode, or at least the Xcode command line tools) to dump info. Here's an example from my machine, leaving out many lines of output not relevant to the relative size of Arm and x86 code.

% otool -fv /Applications/Numbers.app/Contents/MacOS/Numbers architecture x86_64 size 16513632 architecture arm64 size 15277168

And looking at a handful of apps shows the difference is app-dependent:

What are otool's size units? I couldn't find that in the man file.

These relative sizes are very different from what's seen in Finder. E.g., according to otool, Excel is nearly twice the size of Outlook yet, according to Finder, Excel (2.04 GB) is actually a bit smaller than Outlook (2.12 GB).

The man file seems to say that otool (when run without specific file arguments) shows all executable files, including libraries. Is that right? In that case is the difference because Outlook's non-executables are collectively much larger than Excel's?

Terminal code:
otool -fv /Applications/Mathematica.app/Contents/MacOS/Mathematica
otool -fv /Applications/Microsoft\ Word.app/Contents/MacOS/Microsoft\ Word
otool -fv /Applications/Microsoft\ Excel.app/Contents/MacOS/Microsoft\ Excel
otool -fv /Applications/Microsoft\ Outlook.app/Contents/MacOS/Microsoft\ Outlook
otool -fv /Applications/Microsoft\ PowerPoint.app/Contents/MacOS/Microsoft\ PowerPoint

 

[ddhhddhh2]

Although I'm not sure what OP really cares about, from the perspective of "acquiring data," people do have the right to know this information, of course, Apple also has the right not to disclose it. However, OP mentioned that for those who don't use multi-core performance much, single-core evaluation is important. Yes, so I suggest that OP can refer to the single-core performance score of the M1/2/..., which is a good reference. Nevertheless, I still think that it has little reference value.

Apart from that, I am also one of those who believe that single-core performance is very important. Sometimes vendors will exaggerate, but when it comes to computer usage, in most cases, it is the single-core performance that serves you. Indeed, we have many tasks running at the same time, but many tasks often operate simultaneously with the efficiency of multiple "single-core."

Oh, by the way, speaking of "speed," I want to share two little stories. The first story was many years ago when I used the PowerMac G4-400 in the company. The company also had some Pentiums, Pentium III or IV, and also had 7200, 9600, Umax, and G3...etc. I remember that at that time, it seemed like the clock speed war began. Out of curiosity, we compared the crazy speed of Pentium IV with the "apparently" slow speed of G4, and the results were quite interesting. In most cases, the G4 was not slower than the Pentium, and in some cases, it was even faster, but looking at the speed alone, the G4 was still stuck in MHz.

The second little story is about the iMac C2D. Many years later, I bought one to use at home, and the company had a G5 quad. Out of curiosity again, I compared the output speed of the C4D project, and the result was that the dual-core 2.0 iMac C2D actually won over the 2.5 G5 quad.

So, is it important to know the speed numbers? I don't think so, I even think it is almost worthless in evaluating.

 

[Sydde]

In addition to REX, x86 also has the XOP/VEX/EVEX prefixes, used for FP and vector ops. Most of these are a total of 3 bytes (or 2 bytes in some cases), and that is before you even get to the opcode. So, basically any FP or vector operation is going to be larger than the ARM equivalent. Judicious use of the GPR file and pre/post-indexing modes can give ARM a major code density advantage in these ops.

One thing that might sometimes lead to confusion is that the ARM ISA only supports inline address displacements of 12 bits (4K bytes). This means that to reach a larger offset, you have to load a value into a register and index by it. What is lost in the conversation is that displacements are primarily used to access elements in a struct – it is quite rare to encounter a struct with even 500 named fields, so 12 bits is adequate for nearly all needs.

On the other side, x86 offers 8 bit displacements, which are fine for a large fraction of needs, but if you go over that, which can be pretty easy, that 9th bit will cost you 23 additional bits (IOW, the x86 ISA offers 8-bit or 32-bit displacements). When the larger displacement is needed, it is going to fluff up the code dramatically, for a lot of wasted bits, and there really is no more practical way to work around that.

I have seen the output of compilers in the '90s, and it was pretty dire. Just a decade later, we had compilers generating code that was cleaner and faster than a practiced assembly programmer could produce. High-level source code can be written with excessive verbosity and the compiler will condense it down to the optimal result. This is the main reason that x86 is still competitive. Compilers produce the most efficient code possible, which leans toward RISC-like coding principles, which helps maintain sensible code density and good performance.

 

[Analog Kid]

This is 64-bit ARM. Data: https://www.bitsnbites.eu/cisc-vs-risc-code-density/

Now that's a really interesting bit of reading. Thanks. It shouldn't be surprising but it's not what I expected.

I think this is simply an indication that RISC vs. CISC is an outdated dichotomy that trivializes the complexity and design choices that go into a modern ISA. While RISC-V does follow the RISC philosophy to the letter, they pay for it in other ways.

I'd argue that it's only an outdated trivialization if you insist on thinking of things as inflexible and extreme. If you can accept the fact that all engineering is a series of optimizations and tradeoffs, then CISC and RISC are good ways of illustrating those tradeoffs.

No, it's something else entirely. When AMD extended the i386 ISA to 64-bit, they took a very conservative and backwards compatible approach. They kept nearly all existing 32-bit instruction encodings, so all new "long mode" instructions which do one or more of these three things had to be encoded with an additional new prefix byte (REX):

- use 64-bit operand size in an instruction which doesn't default to 64-bit operand size
- use any extended register added by AMD64 (R8 to R15, XMM8-15, YMM8-15, CR8-15, or DR8-15)
- use one of the uniform byte registers SPL, BPL, SIL, or DIL

Thus, 64-bit x86 instructions are at best the same size as 32-bit instructions, but more often larger. If you write code to do exactly the same thing as before, just on 64-bit data values instead of 32-bit, it is likely to grow in size simply because REX instruction encodings are bigger.

Interesting in its own right, but it seems like the reduced density of x86 started before the 64bit transition. The article I link above shows 32bit Arm with a similar (and at times better) code density than 32bit x86.

What you suggest re: "wack the legacy instructions over a generation or two" isn't likely to happen any time soon. "Legacy" i386 instructions are still a fully legitimate part of x86-64. Compilers still emit them, software still uses them (if you don't need to do a 64-bit computation and the instruction doesn't use any of the extended registers, why use the longer REX encoding?). So you're talking about literally abandoning compatibility with Windows and all its software.

No, I'm talking about deprecating the worst offenders in the instruction set and patching over them. Once upon a time I saw estimates of how much of the x86 decoder logic is dedicated to what fraction of the instruction set-- maybe it was in the post-mortem for Itanium. I can't remember the exact numbers but there's a definite Pareto distribution at work. Getting those instructions out of circulation would certainly help.

Announce now that within so many years the worst instructions will no longer have hardware support in the CPU then start cutting them out. The only way to get compilers to stop using them is to stop supporting them. Windows will evolve to stop including them. New code will still run fine on old hardware because old hardware will be a superset. Old code can run on new hardware through trapping unknown opcodes and emulating the old instructions in software.

The M-series can run translated x86 about as fast as Intel can run it natively. Apple has given them a roadmap to salvation.

The time to do something like that would have been when AMD came up with AMD64. They could have done something a bit more like what Arm did with 64-bit, where the 64-bit Arm ISA uses a fundamentally new encoding scheme that is 100% incompatible with 32-bit Arm. (An Arm CPU in 64-bit mode cannot decode 32-bit Arm instructions, and vice versa.) But that didn't happen because at the time, AMD had no power to make anyone adopt a fundamentally new ISA, so they had to go with not rocking the boat much in hopes that Microsoft would see their design and like it as a way to bridge the entire existing 32-bit x86 ecosystem into the 64-bit era. Which Microsoft did, and that's how AMD64 got adopted.

As you say, it couldn't happen then because AMD didn't have the power. Intel was too wrapped up in their VLIW EPIC fever dream at the time to think straight.

Intel maintained their hegemony for decades based on the FUD of breaking with legacy. What I'm reading in these few articles suggests that they can recover some of their lost ground by shedding the dead weight. I don't think "we missed our chance" is going to cut it...

 

[leman]

They may have hardware assist in theory, but in public Darwin kernel source releases the page compression and decompression routines don't use it. And memory compression has been part of x86 macOS for ages and ages, far longer than Apple Silicon Macs have been a thing.

They don't publish these kind of details as part of the open source code. The OS ships with different implementation for this stuff. I can't find a link now, but from what remember these things have been well documented by various OS hackers.

 

[leman]

I'd argue that it's only an outdated trivialization if you insist on thinking of things as inflexible and extreme. If you can accept the fact that all engineering is a series of optimizations and tradeoffs, then CISC and RISC are good ways of illustrating those tradeoffs.

There were good ways sometime in the eighties when they actually reflected the engineering tradeoffs. But CPU design has moved quite a bit in the last decades. I just don't see these terms carry useful information anymore. CISC is basically used as synonym for x86, and then people look at all the legacy cruft and prefix monstrosity and say "you see, this is why CISC sucks". But the funny part is the "CISC" parts of x86 like ENTER and LEAVE instructions have been declared obsolete for a very long time, the only real "CISC" instruction that is probably more commonly used "rep movs" variants for fast memory copy — since current generation of x86 CPUs accelerates this. But — shocker — ARM has introduced similar instructions for fast memory copy in ARMv9. So is ARM now also CISC?

At the end of the day, when you dig deep enough, it all boils down to people equating RISC with load-store architectures. If that's really the case, then why do we even talk RISC vs. CISC when load-store and reg/mem does the same?

 

[Malus120]

It's actually really simple. I don't know how this thread is 4 pages long...

Apple so far only bins chips based on core count (they disable cores for the entry level models and add more cores for higher end models) and not on clock speed.

As all Apple Silicon CPU's of a given generation (so far) offer functionally equivalent performance on their performance cores (unless thermal throttling like the Mx MBA,) listing the clock speed is effectively meaningless for 99% of people (and anyone who actually cares can easily check.)
(While there may be minor deviations with something like the 16" MBP, these are generally within what would be considered the margin of error performance wise.)

Intel and AMD bin CPU's based on how high the cores can clock. Thus as different products at different price/core counts / thermal envelopes can have very different clock speeds it makes sense to list them in the specifications.

 

[Toutou]

Sure, thats plausible. In the long past, the issue with running out of ram and hitting the drive for "swap" meant hitting a slow HDD. SSDs helped and now flash Drives help even more.

I'd just like to point out that SSDs are made of flash memory (the same kind of memory that USB flash drives use), they just use it carefully and do lots of housekeeping. So "flash drives" is not a new category of drives or anything, we're still using the same technology, just faster and a bit more complicated. The HDD->SSD step is still the last big one.

 

[Analog Kid]

There were good ways sometime in the eighties when they actually reflected the engineering tradeoffs. But CPU design has moved quite a bit in the last decades. I just don't see these terms carry useful information anymore. CISC is basically used as synonym for x86, and then people look at all the legacy cruft and prefix monstrosity and say "you see, this is why CISC sucks". But the funny part is the "CISC" parts of x86 like ENTER and LEAVE instructions have been declared obsolete for a very long time, the only real "CISC" instruction that is probably more commonly used "rep movs" variants for fast memory copy — since current generation of x86 CPUs accelerates this. But — shocker — ARM has introduced similar instructions for fast memory copy in ARMv9. So is ARM now also CISC?

At the end of the day, when you dig deep enough, it all boils down to people equating RISC with load-store architectures. If that's really the case, then why do we even talk RISC vs. CISC when load-store and reg/mem does the same?

I agree with what you're saying. Those tradeoffs still exist, buried in all the layers of technology trying to mitigate them. I don't mean CISC<=>x86, RISC<=>Arm. That was my point above about not wanting to get into the pedantry about what those words mean. They form part of a framework within which to discuss tradeoffs in a design not specific instances of anything.

What caught my attention, frankly caught me off guard, is that while the core x86 instruction set was built built with the intention of reducing memory footprint of the code (what we now call CISC, though that term was meaningless before RISC arose as an antonym)-- the modern x86 binaries are larger. I'd never thought about it because the trivial differences in code size just don't matter that much anymore.

It shouldn't have surprised me, that's what happens when you keep adding layers and layers to something as the last few comments have laid bare, but it drove home the point to me that x86 isn't well adapted to the modern world and is no longer well adapted to the old world either.