Every AMD and Intel APU has had unified memory for many generations, as have mobile devices. It's sad how many people Apple's marketing has misled about something that's been standard in the industry for ages.
4,396 karma · joined November 11, 2015
Dynamic clock speeds are exactly why you need to do this testing under full load. No you're probably not getting the same power draw on each chip, but at least you're eliminating the frequency scaling algorithms from the equation. This is why it's so hard to evaluate core efficiency (let alone what effect the ISA has).
What you can do however is compare chips with wildly different performance and power characteristics. A chip that is using significantly more power to do significantly less work is less efficient than a chip using less power to do more.
> To go back to your original argument, you're claiming that x86 ISA is more efficient than ARM because a certain AMD chip beat certain M1/snapdragon chips at 50w.
I never claimed x86 is more efficient than ARM. I did claim the latest AMD cores are more efficient than M1 and snapdragon elite X, while still having worse battery life.
> You can't draw that conclusion because the two chips may be designed to have peak efficiency at different power levels, even if the maximum power draw is the same. Likely the Snapdragon/M1 have better efficiency at 10W with reduced clock speed even if the CPU is not idling.
Firstly this is pretty silly: All chips get more efficient at lower clock speed. Maximum efficiency is at at whatever the lowest clockspeed you can go, which is primarily determined by how the chip is manufactured. Which brings me to my second point: What does any of this have to do with the ISA?
> Not to mention -- who even cares about ISA efficiency? What matters is the result for the product I can buy.
If you don't care about ISA efficiency why are you here‽ That's what this discussion is about! If you don't care about this just leave.
And to answer your question: We care about ISA efficiency because we care about the efficiency of our chips. If ARM was twice as efficient then we should be pushing to kill x86, backwards compatibility be damned. In actuality the reason ARM-based laptops have better efficiency has nothing/little to do with the ISA, so instead of asking AMD/intel to release an ARM-based chips we should be pushing them to optimize battery usage.
My guess is ARM64 is a few percent more efficient, something AMD has claimed in the past. They're now saying it would be identical, which is probably not far from the truth.
The simple fact of the matter is that the ISA is only a small part of how long your battery lasts. If you're gaming or rendering or compiling it's going to matter a lot, and Apple battery life is pretty comparable in these scenarios. If you're reading, writing, browsing or watching then your cores are going to be mostly idle, so the only thing the ISA influences won't even have a current running through it.
To further hammer the point home, let me reduce do a reductio ad absurdum: The chip is still "in use" when its asleep. Sleeping your laptop is a typical usecase. Therefore how much power is used while sleeping is a good measure of ISA efficiency. This is of course absurd because the CPU cores are entirely turned off when sleeping, they could draw 1kW with potato performance and nothing in this measurement would change.
Do not conflate battery life with core efficiency. If you want to measure how efficient a CPU core is you do so under full load. The latest AMD under full load uses the same power as M1 and is faster, thus it has better performance per watt. Snapdragon Elite eats 50W under load, significantly worse than AMD. Yet both M1 and Snapdragon beat AMD on battery life tests, because battery life is mainly measured using activities where the CPU is idle the vast majority of the time. And of course the ISA is entirely irrelevant when the CPU isn't being used to begin with.
> The same goes for GPUs, where Apple's M1 GPU completely smoked an RTX3090 in performance-per-watt, offering 320W of RTX 3090 performance in a 110W envelope
That chart is Apple propaganda. In Geekbench 5 the RTX 3090 is 2.5x faster, in blender 3.1 it is 5x faster. See https://9to5mac.com/2022/03/31/m1-ultra-gpu-comparison-with-... and https://techjourneyman.com/blog/m1-ultra-vs-nvidia-rtx-3090/
Cool, now compare M1 to AI 340. The AI 340 has slightly better single core and better multi-core. If battery life was all about race to idle like you claim then the AI 340 should be better than the M1.
See also Snapdragon X Elite, which is significantly slower than the AI 340, uses more power under load, so in total has much less efficient cores, and yet still beats the AI 340 on battery life.
> Perfect example is trying to get to the bottom of why your windows laptop won't go to sleep and cooks itself in your backpack
Same thing happens in Apple land: https://news.ycombinator.com/item?id=44745897. My Framework 16 hasn't had this issue, although the battery does deplete slowly due to shitty modern standby.
If all that's true then why does Snapdragon have better battery life? As I said in my comment the great battery life comes from when the CPU isn't being used. It's everything else around it. That's where AMD is still significantly behind.
If you fully load the CPU and calculate how much energy a AI340 needs to perform a fixed workload and compare that to a M1 you'll probably find similar results, but that only matters for your battery life if you're doing things like blender renders, big compiles or gaming.
Take for example this battery life gaming benchmark for an M1 Air: https://www.youtube.com/watch?v=jYSMfRKsmOU. 2.5 hours is about what you'd expect from an x86 laptop, possibly even worse than the fw13 you're comparing here. But turn down the settings so that the M1 CPU and GPU are mostly idle, and bam you get 10+ hours.
Another example would be a ~5 year old mobile qualcomm chip. It's a worse process node than an AMD AI340, much much slower and significantly worse performance per watt, and yet it barely gets hot and sips power.
All that to say: M1 is pretty fast, but the reason the battery life is better has to do with everything other than the CPU cores. That's what AMD and Intel are missing.
> If I open too many tabs in Chrome I can feel the bottom of the laptop getting hot, open a YouTube video and the fans will often spin up.
It's a fairly common issue on Linux to be missing hardware acceleration, especially for video decoding. I've had to enable gpu video decoding on my fw16 and haven't noticed the fans on youtube.
* 9 malloc debugging variables were removed, though their symbols actually remain for backwards compatibility they just don't do anything. * vtimes was removed, but the symbol remains for backwards compatibility
Those were the only changelog entries listing removals. None of them cause linking issues. The 9 that did break backwards compatibility are a set of debug tools that don't work for alternate memory allocators and the functionality can be brought back with libc_malloc_debug.so.
Maybe the changelog's incomplete, but this actually seem pretty tame to me.
It's not 3x, but it's most certainly above 1.3x. Average for compilation seems to be around 1.7-1.8x.
As does Valorant and virtually every other first person shooter. The cheats aren't people flying around or nocliping, it's wallhacks and aim assists/bots.
> To work around this limitation, we decided to stop using Direct2D and switch to rasterizing glyphs using DirectWrite instead.
Licenses are perpetual. It is not a subscription. Don't like the work we've done? You can continue to use that version of Sublime Text until the end of time.
> there has been exactly one release with new features (May 2025)
August 2024 we added kinetic scroll and xdg-activation support for Wayland; we also added the ability to configure image extensions and allow dynamically switching between the hex-editor and image view.
November 2023 we added native font dialog support for switching fonts.
August 2023 we added webp and proper support for running as administrator on all platforms.
November 2022 we added syntax-based code folding and operating system recent file integration
December 2021 we added GB18030 support.
I'll stop there. Those are just the largest, most user facing new features, not any of the new settings, new APIs or improvements that I'd argue are new features.
You can read the full changelogs here: https://www.sublimetext.com/download
> Speaking of releases, they're also usually 6-12 months apart.
We do stable releases infrequently, because they're stable. If you want more frequent releases you can switch to the development releases. You can see from the build number how many builds we've done of ST4 since the release: it's around 150.
That's correct, but it could be the day after you buy the license is when ST3 stops receiving any updates and we dedicate all work to ST4. With a ST4 license you're always getting 3 years of updates, ST3 it was anywhere from 3 to zero (not counting the beta period, ST3 only got 3 years of updates).
> Although if my 3 years elapses right before ST4 introduces first-class LSP support and an official Debugger, I may be very peeved. :)
I think we can all sympathize with some buyer's remorse. Unfortunately the line needs to be drawn somewhere. Maybe you can take solace in that we probably can't put multiple huge features in a single update, at least not a dev release. :)
Thanks. I guess I'm just not really seeing how that is any different to what we did before? You'd buy a ST3 license with no knowledge of what improvements would be made to ST3.
As in using DirectWrite or GDI on Windows; or Core Text on macOS. As opposed to shipping your own glyph rasterizer.
> Nor was I happy about the new 3-year-of-updates license model that ST4 adopted.
I'm curious what you don't like about this model? The most common complaint with regards to updates was the long waiting period between major versions, which we've now eliminated, and without changing the perpetual nature of our licenses.
This is true until it isn't. A modern-ish CPU at 1080p 60hz it'll be fine. At 4k 120hz even the fastest CPU on the market won't keep up. And then there's 8k.
> they're likely doing it for things like animations and very high quality font renderin
Since they're using native render functions this probably isn't the case.