81–90 of 241 posts
I sit firm in my belief that the best thing Microsoft could do for their laptop ecosystem is to add support for a "max fan speed" slider somewhere prominent in the Windows UI. People want the option to make their laptop silent or nearly silent. And when users do need the power, they generally prefer a slightly slower laptop at a reasonable volume rather than the roar of a jet engine. Laptop manufacturers want their d…
Earlier quoted context omitted.
Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…
One more: there's more to an ISA than just the instructions; there's semantic differences as well. x86 dates to a time before out-of-order execution, caches, and multi-core systems, so it has an extremely strict memory model that does not reflect modern hardware -- the only memory-reordering optimization permitted by the ISA is store buffering. Modern x86 processors will actually perform speculative weak memory acces…
Earlier quoted context omitted.
Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…
Some notes: 1. Consider M1's 8-wide decoder hit the 5+ GHz clock speeds that Intel Golden Cove's decoder can. More complex logic with more delays is harder to clock up. Of course M1 may be held back by another critical path, but it's interesting that no one has managed to get a 8-wide Arm decoder running at the clock speeds that Zen 3/4 and Golden Cove can. A715's slides say the L1 icache gains uop cache features inc…
AMD/Intel maintain I-cache and maintain a uop cache kept in sync. Using a tiny part to pre-decode is different from a massive uop cache working as far in advance as possible in the hopes that your loops will keep you busy enough that your tiny 4-wide decoder doesn't become overwhelmed.
2. The float workload was always BS because you can't run nothing but floats. The integer workload had 22.1w total core power and 4.8w power for the decoder. 4.8/22.1 is 21.7%. Even the 1.8w float case is 8% of total core power. The only other argument would be that the study is wrong and 4.8w isn't actually just decoder power.
3. We're talking about worst cases here. Nothing stops ARM cores from creating a "work pool" of upcoming branches in priority order for them to decode if they run out of stuff on the main branch. This is the best of both worlds where you can be faster on the main branch AND still do the same branchy code trick too.
4. This is the tail wagging the dog (and something else if your numbers are correct). Complex x86 instructions have garbage performance, so they are avoided by the compiler. The problem is that you can't GUARANTEE those instructions will NEVER be used, so the mere specter of them forces complex algorithms all over the place where ARM can do more simple things.
In any case, your numbers raise a VERY interesting question about x86 being RISC under the hood.
Consider this. Say that we have 1024 bytes of ARM code (256 instructions). x86 is around 15% smaller (871.25 bytes) and with the longer 4.25 byte instruction average, x86 should have around 205 instructions. If ARM is generating 19.3% more uops than instructions, we have about 305 uops. x86 with just 4.7% more has 215 uops (the difference here is way outside any margins of error here).
If both are doing the same work, x86 uops must be in the range of 30% more complex. Given the limits of what an ALU can accomplish, we can say with certainty that x86 uops are doing SOMETHING that isn't the RISC they claim to be doing. Perhaps one could claim that x86 is doing some more sophisticated instructions in hardware, but that's a claim that would need to be substantiated (I don't know what ISA instructions you have that give a 15% advantage being done in hardware, but aren't already in the ARM ISA and I don't see ARM refusing to add circuitry for current instructions to the ALU if it could reduce uops by 15% either).
8. https://en.wikipedia.org/wiki/Peephole_optimization
The final optimization stage is basically heuristic find & replace. There could in theory be a mathematically provable "best instruction selection", but finding it would require trying every possible combination which isn't possible as long as P=NP holds true.
My favorite absurdity of x86 (though hardly the only one) is padding. You want to align function calls at cacheline boundaries, but that means padding the previous cache line with NOPs. Those NOPs translate into uops though. Instead, you take your basic, short instruction and pad it with useless bytes. Add a couple useless bytes to a bunch of instructions and you now have the right length to push the function over to the cache boundary without adding any NOPs.
But the issues go deeper. When do you use a REX prefix? You may want it so you can use 16 registers, but it also increases code size. REX2 with APX is going to increase this issue further where you must juggle when to use 8, 16, or 32 registers and when you should prefer the long REX2 because it has 3-register instructions. All kinds of weird tradeoffs exist throughout the system. Because the compilers optimize for the CPU and the CPU optimizes for the compiler, you can wind up in very weird places.
In an ISA like ARM, there isn't any code density weirdness to consider. In fact, there's very little weirdness at all. Write it the intuitive way and you're pretty much guaranteed to get good performance. Total time to work on the compiler is a zero-sum game given the limited number of experts. If you have to deal with these kinds of heuristic headaches, there's something else you can't be working on.
One of these has to be true (or both true): 1. ARM is inherently more efficient than x86 CPUs in most tasks 2. Nuvia and Apple are better CPU designers than AMD and Intel Here are results from Notebookcheck: Cinebench R24 ST perf/watt * M3: 12.7 points/watt * X Elite: 9.3 points/watt * AMD HX 370: 3.74 points/watt * AMD 8845HS: 3.1 points/watt * Intel 155H: 3.1 points/watt In ST, Apple is 3.4x more efficient than Zen…
I would guess it's more to do with coming from desktop CPU design to mobile vs. phones to laptops.
Earlier quoted context omitted.
Stop demanding paper thin laptops. My work Dell rarely turns on its fan unless an AV scan is in progress and even then it's rather tolerable. It isn't a fashionable thickness so has plenty of internal volume for heat distribution.
MacBook Air is thin and fanless, so it can be done.
Earlier quoted context omitted.
MacBook Air is thin and fanless, so it can be done.
The cheapest MacBook Air is $1000, and it's more like $1500+ if you want a reasonable amount of RAM and storage. There are similarly expensive Windows laptops available that are fanless.
Earlier quoted context omitted.
ARM doesn't need the variable-length instruction decoding though, which on x86 essentially means that the decoder has to attempt to decode at every single byte offset for the start of the pipeline, wasting computation. Indeed pretty much any architecture can benefit from some form of op cache, but less of a need for it means its size can be reduced (and savings spent in more useful ways), and you'll still need actual…
x86 processors simply run a instruction length predictor the same way they do it for branch prediction. That turns the problem into something that can be tuned. Instead of having to decode the instruction at every byte offset, you can simply decide to optimize for the 99% case with a slow path for rare combinations.
One of these has to be true (or both true): 1. ARM is inherently more efficient than x86 CPUs in most tasks 2. Nuvia and Apple are better CPU designers than AMD and Intel Here are results from Notebookcheck: Cinebench R24 ST perf/watt * M3: 12.7 points/watt * X Elite: 9.3 points/watt * AMD HX 370: 3.74 points/watt * AMD 8845HS: 3.1 points/watt * Intel 155H: 3.1 points/watt In ST, Apple is 3.4x more efficient than Zen…
> 2. Nuvia and Apple are better CPU designers than AMD and Intel
The third possibility is that they just pick a different point on the efficiency curve. You can double power consumption in exchange for a few percent higher performance, double it again for an even smaller increase.
The max turbo on the i9 14900KS is 253 W. The power efficiency is bad. But it generally outperforms the M3, despite being on a significantly worse process node, because that's the trade off.
AMD is only on a slightly worse process node and doesn't have to do anything so aggressive, but they'll also sell you whatever you want. The 8845HS and 8840U are basically the same chip, but former has around double the TDP. In exchange for that you get ~2% more single thread performance and ~15% more multi-thread performance. Whereas the performance per watt for the 8840U is nearly that of the M3, and the remaining difference is basically the process node.
One of these has to be true (or both true): 1. ARM is inherently more efficient than x86 CPUs in most tasks 2. Nuvia and Apple are better CPU designers than AMD and Intel Here are results from Notebookcheck: Cinebench R24 ST perf/watt * M3: 12.7 points/watt * X Elite: 9.3 points/watt * AMD HX 370: 3.74 points/watt * AMD 8845HS: 3.1 points/watt * Intel 155H: 3.1 points/watt In ST, Apple is 3.4x more efficient than Zen…
From you link - Intel is topping the performance charts (alongside AMD in SC) - they probably tune power usage agressively to achieve these results. I would guess it's more to do with coming from desktop CPU design to mobile vs. phones to laptops.
Cinebench 2024 ST:
* M3: 142 points
* X Elite: 123 points
* AMD HX 370: 116 points
* AMD 8845HS: 102 points
* Intel 155H: 108 points
Amongst each company's best laptop ST SoCs, no, Intel and AMD are far behind in both ST scores and perf/watt.
If you're referring to desktop speeds, then yes, Intel's 14900k does top the charts in ST Cinebench but it likely uses well over 100w.
I mostly care about laptop SoCs. In the case of the M3, it doesn’t even have a fan.
Earlier quoted context omitted.
Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…
Some notes: 1. Consider M1's 8-wide decoder hit the 5+ GHz clock speeds that Intel Golden Cove's decoder can. More complex logic with more delays is harder to clock up. Of course M1 may be held back by another critical path, but it's interesting that no one has managed to get a 8-wide Arm decoder running at the clock speeds that Zen 3/4 and Golden Cove can. A715's slides say the L1 icache gains uop cache features inc…