Yes Apple is allowed to do things others can'tnope. the OEM i am selling it to has no alternative source.

Yes Apple is allowed to do things others can'tnope. the OEM i am selling it to has no alternative source.
Microsoft screwed this up a long time ago; Windows doesn't support multi-architecture binaries at all. This has been a pain point for a long time even on x86, since Microsoft has to support both 32- and 64-bit x86 applications.Developers apparently can’t even ship universal binaries for Windows?
A lot of what's behind the recent PC user interest in Linux is that Microsoft has been ratcheting Windows-as-adware up to an almost intolerable degree for home users.This video also touches on my previous thread about enshittification where developers and power users really are looking elsewhere like Linux (and maybe macOS). Sadly I’m not sure how viable Linux will be for users but if this video is any indication at least some fraction of people seem really unhappy with MS and that doesn’t have anything to do with x86. While Apple’s superior battery life is a reason why some people switched, more appears to be rotten in the state of Redmond than Intel/AMD chips.
Developers apparently can’t even ship universal binaries for Windows?
So IMO figuring out how performant an architecture in MT scenarios needs some sort of normalization to rationalize the results or you can wind up with absurdities like comparing the efficiency of down clocked threadrippers to base M processors.
AMD has traditionally shied away from direct performance comparisons with Apple’s M series processors. However, Asus presented its new AMD-powered Zenbook S 16 at the event and shared some of its own benchmarks to highlight the Ryzen AI 9 HX 370’s performance against a competing Apple MacBook Air 15 with an M3 processor. Asus provided sparse test config info in the slide, so we’ll have to take these benchmarks with more than the usual amount of salt.
Asus claims substantial leads over the MacBook Air 15, with wins ranging from a 20% advantage in the Geekbench OpenCL CPU score benchmark to a whopping 118% lead in the UL Procyon benchmark. Other notable wins include a 60% advantage in Cinebench (certainly the multi-threaded benchmark) and a 20% lead in the Geekbench CPU score.
No info on battery life. The Tom’s article doesn’t mention it and the Asus website says “Zenbook S 16 has the day-long stamina you need, and more." Whatever that means.Case in point:
With respect to the CPU benchmarks, the Ryzen AI 9 HX 370 is a 4/8c 12-core, 24 thread processor being compared to a 4P/4E 8-core, 8-thread processor. It’s also a “default” 28W TDP processor which can be set as high as 54W.
So showing off that they beat the M3 in multithreaded tests … I mean … yeah?Even if performance is comparable at around 20W … only okay? (the M3 is also on N3 vs N4P which isn’t as big a difference in performance and power as one might’ve hoped, but still worth noting).
The iGPU, the 890M, is very nice though again way outside the weight class of the MacBook - with still decent power consumption I might add. I’m looking forwards to AMD’s entrance into the even larger APUs later - as well as hopefully Nvidia’s.
Overall these look good, I just wish Asus marketing was as smart as AMD’s and shied away from direct comparisons that aren’t really in its favor. Then again, it probably works. So maybe it’s “smart” after all.
Microsoft screwed this up a long time ago; Windows doesn't support multi-architecture binaries at all. This has been a pain point for a long time even on x86, since Microsoft has to support both 32- and 64-bit x86 applications.
Ah but the OEM you are trying to sell your chip to might if you double the cost of producing the chip - either it becomes lower profit for you, the OEM, or lower volume because the end-user doesn't want to pay that much even if it means better battery life and quieter fans.
That's multithreaded efficiency and yes they are much, much closer there. Sorry for being unclear, I was referring to ST efficiency when referring to Oryon having greater >2x efficiency compared to AMD. You were saying how "The 7745HX has about 12% more ST than the 7840HS according to Geekbench." Which might match the Snapdragon in terms of performance though the processor here is only a few percent higher than the 8845HS/7840HS recorded in Notebookcheck and still slower than the (higher) Snapdragon. As you said, it really depends on how the OEM has set its power and thermals and even single threaded is a pain. I mean if you check the chart below the X1P-64-100 (108 pts) got massively higher efficiency than the 80-100 (123 pts) and the 78-100 (108 pts) despite being a lower binned processor and the 64 and 78 scoring the same with the same clockspeed!
BTW how do you resize your picture? When I look on the phone mine is fine, but on the computer screen mine is absolutely massive and yours looks normal - I just took a screen shot and pasted it in. Edit: actually yours look small on the phone, huh, either way how did you resize?
True. And even with Apple, only the latter three are a clean, generalized approach. 68K/PPC fat binaries for classic MacOS were slightly hack-ish. They kept 68K executable code in the same format in resource forks, where it always had been. PPC was added in by using the data fork (normally unused in classic MacOS 68K apps) to store a PEF format executable.In fairness, only a handful of platforms have ever really used FAT binaries. Apple's the only one I'm aware of that uses it consistently (68K/PPC, PPC/Intel, 32/64Bit, Intel/ARM).
I remember that, and also remember much of the resistance to the idea being kneejerk "well why should we do that when everything's compiled for your CPU by your distro". (Sigh.)Someone tried to introduce FatELF and had some fun with that, but the end result is that it never took off and multi-arch Linux installs look surprisingly similar to Windows multi-arch installs. Only with better folder names.
True. And even with Apple, only the latter three are a clean, generalized approach. 68K/PPC fat binaries for classic MacOS were slightly hack-ish. They kept 68K executable code in the same format in resource forks, where it always had been. PPC was added in by using the data fork (normally unused in classic MacOS 68K apps) to store a PEF format executable.
By contrast, the 'universal' scheme in Mac OS X onwards is just NeXT's Mach-O binary format. Mach-O headers can describe an arbitrary number of code segments and architectures stored in one file - you can make quad (or more) architecture binaries if you like.
I had forgotten these details about the evolution of Classic's PPC support, thanks! Now that you've nudged my brain cells I do remember them trying to modernize that and other things. Stuff like the nanokernel... iirc we never got to take full advantage of its features before end of the road for Classic.But really, PEF was the full evolution of how code fragments were stored on Classic MacOS, and supported 68k. Much like how Mach-O replaced PEF. And yet, because there's all the legacy stuff you have to support, the old executable formats were still supported for quite a while.
EDIT: Interestingly, like Mach-O, PEF does support arbitrary numbers of code segments in a single file. But it only ever supported 32-bit PPC and 68k as architectures.
NeXT even had their own 68K to PowerPC transition (hardware and software) mostly ready to go, but it didn't make it out the door before NeXT's dismal revenues forced them to abandon making hardware.Which in fairness was needed because NeXT supported a couple architectures itself. And yeah, well aware just how heavily MacOS X took from NeXTStep to deliver a modern OS.
Yeah I was just exaggerating to make the point. I agree that it’s the total SOC size that matters not just the CPU when it comes to cost and I should add that supposedly the Qualcomm chips are indeed cheaper. However, the other part of the balancing act is that CPUs are expected to take on a number of different workloads with different levels of multi threading and which workloads it should focus on depends heavily on the device class. This stands in stark contrast with GPUs where cost and power limits may apply limits to core counts, but for the workloads themselves, more cores will always simply be better. For the CPU, targeting one set of workloads like heavily multi threaded can be counterproductive to single threaded and lightly multithreaded tasks. As John Poole said in his posts about why he changed GB6's multithreaded scoring system, relying solely on infinitely scalable multithreaded benchmarks users were getting suckered into not only buying systems with power they didn't need but even worse were actually slower at some of their most common tasks than "lower-tier" systems they could've bought instead. And that's on HEDT systems never mind processors destined for "thin and lights"! Even if the negative consequences don't come into play, at the very least, users of such devices will either not benefit from high multithreaded capabilities or find heavy throttling and low battery life when they do try to make use of their MT capabilities in such systems. Thus, there is a penalty to be paid for not developing a chip targeted for the right device. This isn't to say that a chip shouldn't be the best it can be but what is best can be heavily context dependent. This is why I was no more impressed with Qualcomm/MS's marketing about multithreaded workload claims than I am with ASUS's for the upcoming AMD chips (AMD did not make those claims themselves).In fairness, only a handful of platforms have ever really used FAT binaries. Apple's the only one I'm aware of that uses it consistently (68K/PPC, PPC/Intel, 32/64Bit, Intel/ARM).
Someone tried to introduce FatELF and had some fun with that, but the end result is that it never took off and multi-arch Linux installs look surprisingly similar to Windows multi-arch installs. Only with better folder names.
When talking about CPU cores on modern dies, double die area on a core isn't going to lead to double the die area of the chip. With all the integration going on with Intel, AMD, Apple, etc, there's a lot more going on these days. The CPU cores and cache on a base M3 is what, 1/6th of the die (rough estimate from annotated die shots)? Doubling that is around 16% more die area. But this is all us kinda exaggerating the point, though. The result is that a larger die area will increase costs, but that's all part of the balancing act here.
That's more interesting, but they are measuring system draw which itself is fraught with issues because you are measuring more than just the CPU cores. Is this result because boost clocks? Because of differences in the graphics feeding the external display? Does Ryzen and Intel have a high base load even when the cores are asleep? That last one is something I have seen before. My i7 Mac mini can get under 10W when idle, yet I had a Ryzen 5600 desktop that drew 30W just sitting at the desktop doing nothing. Because these figures are using system measurements, it's harder to make claims about the cores themselves. It's certainly a statement that you can get more battery from a Qualcomm system in this specific scenario though, and that Apple systems are consistently good across the board.
Using the WYSIWYG editor, you can select and set a fixed size on images.
No info on battery life. The Tom’s article doesn’t mention it and the Asus website says “Zenbook S 16 has the day-long stamina you need, and more." Whatever that means.
Yeah, this was around the time I was starting to try to get my head wrapped around the Inside Macintosh books. I had a physical copy of the PPC Architecture book among a smattering of others found at swap meets and the like. Never really played much with Multiprocessing Services which promised partial preemptive multitasking, although I think I remember reading up on it.I had forgotten these details about the evolution of Classic's PPC support, thanks! Now that you've nudged my brain cells I do remember them trying to modernize that and other things. Stuff like the nanokernel... iirc we never got to take full advantage of its features before end of the road for Classic.
Yuuup. And then you had all sorts of stuff just sitting there for you to hook into with an INIT or two. At one point I did hook the heap manager (why is this even possible?) with a custom INIT while I was in middle school. Mostly just crashed the Finder, but I was able to prove to myself that it was possible to hook the heap manager and write a custom implementation if you knew what you were doing. At least at the time, I didn’t.Classic MacOS had so much technical debt. Cramming a GUI as sophisticated as 1984 Macintosh into 64K ROM, 128K RAM, and a 400K boot floppy created lots of design compromises that were unfortunate in the long term. (So much so that sometimes "long term" meant maybe two or three years in the future.)
Hard to say. But I think such a beast would look a lot more like say, Windows 98 or XP, than MacOS X.I do wonder how different things would be today if Apple had good and effective leadership in the early 1990s. If they'd directed the resources wasted on things like Taligent and OpenDoc towards less glamorous incremental improvement of Mac OS, would they have been successful enough to not even need to go looking for a different OS by 1996?
With no memory protection, if someone outside Apple wanted to hook anything badly enough, they absolutely could. So maybe Apple was just going with the flow, there!Yuuup. And then you had all sorts of stuff just sitting there for you to hook into with an INIT or two. At one point I did hook the heap manager (why is this even possible?)
For sure. I don't think that alt-history version of Apple would have been doing the right thing for the long term, for what it's worth.Hard to say. But I think such a beast would look a lot more like say, Windows 98 or XP, than MacOS X.
With no memory protection, if someone outside Apple wanted to hook anything badly enough, they absolutely could. So maybe Apple was just going with the flow, there!
For sure. I don't think that alt-history version of Apple would have been doing the right thing for the long term, for what it's worth.
Come to think of it, Copland was sort of that beast, but iirc extremely poor execution (terrible performance, lots of bugs) doomed it.
I should make it clear that I'm comapring *single threaded* GB 6.2 and CB R24 results - it gets more complicated for MT.A qualifying statement that I made in my bubble chart post, it should also be noted that in GB 6.2, AMD does much, much better relative to its ARM rivals as an average across the GB subtests than it does in CB R24. AMD are almost certainly still drawing a hell of a lot more power than the ARM-based cores to attain those scores still (probably even worse relative to CB R24 given the bursty nature of the GB workload means a proportionally higher time spent at max boost) but at least the performance deficit is gone and they actually beat some Qualcomm models and nearly match the M2 Pro, while the higher end Qualcomm supersedes both in this test though - just a side note in contrast to CB R23, Apple does incredibly well in CB R24 so yeah Maxxon fixed whatever that problem was, at least for Apple chips. So 2-3 fold differences in power efficiency may be on the high end for benchmarks, but there is still a very substantial gap in ST performance and efficiency between the best ARM (well M2, but still) and the currently best x86 cores.
Long video mostly on how terrible the Windows-Snapdragon experience has been for developers and generally just how bad Windows has gotten in general and MS’s inability to execute, especially on ARM for the past decade. Apparently engineers at MS and Qualcomm are working crunch time to try to solve these issues but some things are just impossible to fix quickly like the 2023 DevKit being largely unhelpful for the porting process and the 2024 DevKit that is more representative of the hardware and drivers isn’t out and won’t be for awhile. MS is very good on support on some issues but on the Qualcomm-MS border like drivers and software developers aren’t always sure who is actually responsible and no one seems to be.
It’s interesting some of these complaints are things I’d heard about Apple and gaming over the years so it was actually odd to hear Apple being lauded from a game developer’s perspective during the interview portion as how to do a transition right. Developers apparently can’t even ship universal binaries for Windows?
This video also touches on my previous thread about enshittification where developers and power users really are looking elsewhere like Linux (and maybe macOS). Sadly I’m not sure how viable Linux will be for most users outside of SteamOS but if this video is any indication at least some fraction of people seem really unhappy with MS and that doesn’t have anything to do with x86. While Apple’s superior battery life is a reason why some people switched, more appears to be rotten in the state of Redmond than Intel/AMD chips.
There are some aspects of the video I’m not as sold on (like I’d say its performance and perf/watt is a bit better than Wendell gives it credit for). I might also criticize it for being long winded and repetitious but considering my own writing I’d be a little hypocritical. Overall though some interesting points and again shows that building these devices is more than just CPU architecture and Qualcomm needs serious improvement and so does MS for Windows on ARM despite 10 years of trying.
all sizes in mm^2 | CPU core | All CPUs + L2 | L3 | CPU + L2 + L3 | Die |
Snapdragon Elite | 2.55 | 48.7 (36MB) | 5.09 (6MB) | 53.79 | 169.6 |
AMD Strix Point | 3.18 Z5 / 1.97 Z5c | 42.6 (8MB) | 15.86 (16MB + 8MB) | 58.5 | 225.6 |
Apple M4* | 3.00 P / 0.82 E | 27 (16MB + 4MB) | 5.86 (8MB?) | 32.86 | 165.9 |
all sizes in mm^2 | "CPU Size" |
Snapdragon Elite | 48.7 |
AMD Strix Point | 58.5 |
Apple M4* | 27 |
L1 cache per core (instruction + data) | |
Snapdragon Elite | 192+96 KiB |
AMD Strix Point | 32+48 KiB |
Apple M3 | 192+128 KiB P / 128+64 KiB E |
Another thing that has occurred to me looking at this chart comparing the Qualcomm Elite to the M2 Pro is I once estimated that the Qualcomm Elite was missing 20% of its multicore performance in CB R24 based on how 12 M2 P-cores should behave. However, here we see that for the same ST CB R24 performance the Elite 80 is ... 20% less efficient than the M2 Pro's P-core. If that's true at lower clocks as well (i.e. in a multithreaded scenario), then that alone could explain the discrepancy. That's a big if, but it's plausible.A revisualization of Notebookcheck's Cinebench R24 performance and efficiency data.
View attachment 31532
Details: This is only results from one benchmark, Cinebench, which has gone from being one Apple's worst performing benchmarks in R23 to one of its best in R24. As I am interested in getting as close as possible to the efficiency of the chip itself, power measurements above subtract idle power which NotebookCheck does not do when calculating the efficiency of the device. With the release of Lunar Lake, an N3B chip, I've added M3, Apple's corollary to Lunar Lake, and estimated M3 Pro's efficiency based on its power usage in R23 and the base M3 CPU's power/performance in R23/R24 (NotebookCheck did not have power data for R24 for the M3 Pro). I feel it is maybe overestimating M3 Pro's efficiency a little, but not by enough to matter given the gulf between it and every other chip. The M3 was in the Air, given that Cinebench is an endurance benchmark, its score and power usage will both likely be higher in the 14" MacBook Pro. I did also have the Snapdragon X1E-84-100 but removed it since it was clutter and didn't add much. The Ultra 7 258 is one of the upper level Lunar Lake chips, but not the top bin - the 288 might improve efficiency/performance somewhat by having better silicon, but the effect will be small relative to the patterns we see.
So what do we see? First off, Lunar Lake has great single core performance and efficiency ... for an x86 chip - helped perhaps by being on a slightly better node, N3B, than the M2 Pro (N5P), HX 370 (N4), and Snapdragon (N4). Despite this advantage, the Snapdragons on N4 and M2 Pro on N5P are still superior in ST performance and efficiency. The Intel 7 288V might increase performance to match or slightly beat the Elite 84 (not pictured), but it would be at the cost of even more power. That said, the efficiency and performance improvements here are enough to make x86 potentially competitive with this first generation of Snapdragons - at least enough that with compatibility issues, Intel can claim wins over Qualcomm and begin to lessen its appeal.
However, this has come at a cost of MT performance. The prevailing narrative is that without SMT2/HT, Intel struggles to compete against AMD and Qualcomm. And to certain extent that's true, but with only 4 P-cores and 4 E-cores in a design optimized for low power settings, it was never going to compete anyway. The review mentions it gets great battery and decent performance on "everyday" tasks in stark contrast to full tilt performance represented by Cinebench R24 and that after all this for thin and lights. The closest non-Apple Lunar Lake analog is the 8c/8T Snapdragon Plus 42 whose ST performance is a little lower than the 258V, but with much, much greater efficiency and whose MT performance and efficiency is much better than the Lunar Lake chip. However, the Snapdragon Plus 42 has a significantly cut down GPU which was already the weakest part of the processor. I'm not saying it can't provide compelling product, especially if priced well, but given the compatibility issues it's tougher sell for Qualcomm that it would've been last year. As for AMD, there is no current analog to the Lunar Lake in AMD's lineup. Sure, a down clocked HX 370 gets fantastic performance/efficiency at 18W ... but that's to be expected from a 12c/24T design which would frankly be cramped inside thin and lights - its not really meant for that kind of device. It's a Mx Pro level chip at heart and should be compared to the upcoming Intel Arrow Lake mobile processors. AMD's smaller Kraken Point is supposedly coming out next year with a more similar CPU but again is rumored to cut the GPU and according to the notebookcheck review, the Intel iGPU in Lunar Lake is already competitive with if not better than the AMD iGPU in the larger Strix Point. It's fascinating how AMD and Qualcomm both designed more workload-oriented CPU-heavy designs while Intel has basically designed Lunar Lake to be like the base M3, more well rounded.
But that brings us to the M3 and the comparisons here are pretty ugly for all of its competitors. Again, Apple tends to do very well in CB R24, so we shouldn't extrapolate from this one benchmark that it will be quite this superior to AMD, Intel, and Qualcomm in every benchmark. With that caveat aside ... damn. The ST performance and efficiency are out of this world and simply blow the other N3B chip, the Lunar Lake 258V, away with both a large performance gap and an even larger efficiency gap, nearly 3x. Even the M2 Pro and Snapdragons are just not that close to it. Sure in MT a down clocked Strix Point can match the base M3's performance profile at 18W, but that is a massive CPU by comparison and the comparable Apple chip to the HX 370, the M3 Pro, is leagues better than anything else in this chart, including the HX 370. I have to admit: while Apple adopted the 6 E-core design for the base M4, if the M4 Pro doesn't have its own bespoke SOC design and is a chop of the Max, then, depending on how Apple structures the upcoming M4 Max/Pro SOC, it'll be a shame to see Apple lose a product at this performance/efficiency point. The M3 Pro is rather unique. Also, its 6+6 design really highlights how improved the E-cores (and P-cores) were moving from the M2 to the M3, especially in this workload.
Meanwhile the two chips of comparable CPU design to the base M3, the Plus 42 and the 258V, are simply not a match for the base M3 in MT requiring double or more power to match its performance or otherwise offering significantly reduced performance at the same power level. Intel claimed to match/beat the M3 in a variety of MT tasks in its marketing material, but aside from specially compiled SPEC benchmarks, you can see how much power it takes for it to actually do that. Basically Apple can offer a high level of performance (for the form factor) in a fan-less design and its competitors, including the N3B Lunar Lake, simply cannot. Also like Lunar Lake, Apple also went for a balanced design here opting for powerful-for-its-class iGPUs to be paired with its CPUs (though obviously some of these chips, especially the Strix Point can also be paired with mobile dGPUs). There is a point to be made about the base MacBook Pro 14"'s price which is quite expensive, has a fan, and is still the base M3 with a low base memory/storage option - but even so, as we can see above, the base Apple chip is not without its merits at that price point/form factor. To reference @casperes1996, now that both Intel and Apple are on N3B ... I guess we figured out who orders pizza the best.
Oh and ... this is the performance/efficiency gulf of the newest generation of AMD, Intel, and Qualcomm processors with the M3 ... with the M4 Macs about to come out.
References:
![]()
Qualcomm Snapdragon X Elite Analysis - More efficient than AMD & Intel, but Apple stays ahead
Notebookcheck analysis of the new Qualcomm Snapdragon X Elite ARM processor X1E-78-100 and X1E-80-100.www.notebookcheck.net
![]()
AMD Zen 5 Strix Point CPU analysis - Ryzen AI 9 HX 370 versus Intel Core Ultra, Apple M3 and Qualcomm Snapdragon X Elite
Notebookcheck takes a look at the new AMD Zen 5 Ryzen AI 9 HX 370 processor and compares it with the Intel Core Ultra, Apple M3 Pro and Qualcomm Snapdragon X Elite.www.notebookcheck.net
![]()
Intel Lunar Lake CPU analysis - The Core Ultra 7 258V's multi-core performance is disappointing, but its everyday efficiency is good
Notebookcheck CPU analysis of the new Intel Lunar Lake Core Ultra 7 258V as well as the Core Ultra 256V in comparison with the Snapdragon X Elite, AMD Zen 5 & Apple M3.www.notebookcheck.net
![]()
Apple MacBook Air 13 M3 review - A lot faster and with Wi-Fi 6E
We tested the new MacBook Air M3 with a faster 10-core graphics card, Wi-Fi 6E and 16 GB RAM.www.notebookcheck.net
![]()
Apple MacBook Air 15 M3 review - Apple’s large everyday MacBook gets a power up
Notebookcheck reviews the new Apple MacBook Air 15 with the M3 SoC, 16 GB of RAM and Wi-Fi 6E.www.notebookcheck.net
![]()
Apple MacBook Pro 16 2023 M3 Pro review - Efficiency before performance
NotebookCheck tests the new MacBook Pro 16 with the M3 Pro SoC in the basic version with 18 GB of RAM and a 512 GB SSD.www.notebookcheck.net
![]()
Apple MacBook Pro 14 2023 M3 Pro review - Improved runtimes and better performance
Notebookcheck has tested the MacBook Pro 14 with the 11-core M3 Pro, 18 GB RAM and a 512-GB SSD which costs 2,499 Euro.www.notebookcheck.net
![]()
AMD adds GFX1152 "Kraken Point" APU with RDNA3.5 graphics to open-source Linux drivers - VideoCardz.com
Kraken Point already in the works by AMD A new GFX ID has been spotted. AMD has just announced its Strix Point silicon at Computex, its first Zen5 APU. This is just the beginning for the next-gen APU series from AMD, as the company is also developing its Strix Halo and Kraken Point silicons...videocardz.com
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.