Live data from Hacker News

Apple's M4 has reportedly adopted the ARMv9 architecture

wccftech.com

191–200 of 250 posts

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#191
post #41
post #23

It seems that M4 was overhyped. Almost of all of the performance improvements, in Geekbench for example, comes from new instructions that most apps won't use, and even if they do they might end up using the faster GPU/NPU for those tasks. https://twitter.com/toniievych/status/1788596920627118248

I truly never understood why Apple deprecated Bitcode. It was a super great idea because it allowed recompilation on the App Store to take advantage of new instructions.

Autovectorization doesn't work without extreme levels of handholding, so the optimization idea was basically a myth.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#192

Earlier quoted context omitted.

And, in modern desktop software, code is a tiny bit of the total size of the application - visual elements tend to occupy a lot more space than code.

In games, perhaps. In basically nothing else though. And I have 0 games on my M1, yet my apps folder is 23 GB. Docker, Edge, and SketchUp all 2+ GB, despite not having almost any UI to speak of. (Edit to remove iMovie from the list, as it has GB's of "Transitions" and "Titles" that I really should just delete)

No, in pretty much everything.

All three examples you gave have substantial UI and other bundled assets. For example, the Docker Desktop app is about 2GB on my computer, yet included assets make up at least 1.2GB, and a further 600MB is a bundle containing the UI, which itself is about 100MB of binaries.

If you actually open those bundles (as they're called on macos) and take a look inside, you'll see that they don't even contain all of their assets, anyways, often linking to frameworks contained in ~/Library

This is a very layperson explanation, btw, but I assure you that "in modern desktop software, code is a tiny bit of the total size of the application" is a very true statement.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#193
post #181

Earlier quoted context omitted.

What is the percentage gain of using masked instructions on any benchmark/task of your choice? It can be negative on weird kernels that do lots of vector cmp since even ARM decided the cost of more than one write port in the predicate register file wasn't worth it, or if the masking adds lots of unnecessary and possibly false dependencies on the destination registers. > This is only true if we ignore more complex ins…

I think it's somewhat unfair to ask for real world examples when there really aren't many people writing optimized SVE code right now. Probably because there are hardly any devices with the extension. I think the transition from AVX2 to AVX512 is comparable in that it provided not only larger vectors, but also a much nicer ISA. There were certainly a few projects that benefited significantly from that move. simdjson…

This.

AVX512 is all around a nice addition as JIT-based runtimes like .NET (8+) can use it for most common operations: text search, zeroing, copying, floating point conversion, more efficient forms of V256 idioms with AVX512VL (select-like patterns replaced with vpternlog).

SVE2 will follow the same route.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#194
post #101

Earlier quoted context omitted.

Besides maybe battery life (which is a huge win), anything you'd benefit from the M's? I only had a 2008 macbook so I'm curious.

I can definitely say there's a downside. I sometimes take the bus home, but it can get chilly at night. Previously, I would fire up a little python script that saturate all the cores, to warm my lap. My old Intel was plenty warm to keep me from getting too uncomfortable. I can't even feel my M2 through my pants, and sticking it into my shirt makes me look like an idiot.

They make battery powered hand warmers for that, but it could make you infertile, or I guess set your pants on fire.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#195
post #10

Earlier quoted context omitted.

These machines are great. I still use my 2015 rMBP as a secondary. It's a little slow now but a couple years ago I was still running Solidworks (in Bootcamp) on it with minimal issues.

My wife is still using her 2012 MBP. We maxed out RAM and gave it an SSD in 2016. She uses it for video editing and music production. The thing look like new. Completely ridiculous. Only downside: no OSX updates since I don’t know when.

OCLP is your friend.

https://dortania.github.io/OpenCore-Legacy-Patcher/

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#196
post #181

Earlier quoted context omitted.

What is the percentage gain of using masked instructions on any benchmark/task of your choice? It can be negative on weird kernels that do lots of vector cmp since even ARM decided the cost of more than one write port in the predicate register file wasn't worth it, or if the masking adds lots of unnecessary and possibly false dependencies on the destination registers. > This is only true if we ignore more complex ins…

I think it's somewhat unfair to ask for real world examples when there really aren't many people writing optimized SVE code right now. Probably because there are hardly any devices with the extension. I think the transition from AVX2 to AVX512 is comparable in that it provided not only larger vectors, but also a much nicer ISA. There were certainly a few projects that benefited significantly from that move. simdjson…

CPUs with SVE have been generally available for two years now. SME and AVX-512 got benchmarks written showing them off before the CPUs were even available. Seems fair to me.

simdjson specifically benefitted from Intel's hardware decision to implement a 512b permute from 2x 512b registers with a throughput of 1/cycle. That's area-expensive, which is (probably) why ARM has historically skimped on tbl performance, only changing as of the Cortex-X4.

Anyway simdjson is an argument for 256b/512b vector permute, not 128b SVE.

Having written a lot of NEON and investigated SVE... I disagree that SVE is a nicer ISA. The set of what's 2-operand destructive, what instructions have maskable forms vs. needing movprfx that's only fused on A64FX, and dealing the intrinsics issues that come from sizeless types are all unneeded headaches. Plus I prefer NEON's variable shift to SVE's variable shifts.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#197
post #138

Earlier quoted context omitted.

Does anyone have insight into why arm CPU vendors seem so hesitant about implementing SVE2? ~They seem~ *Apple seems to have no issue with SSVE2 or SME. Edit: Only Apple has implemented SSVE and SME I think.

What is the measurable benefit to implementing 128b SVE2? Like, ARM has CPUs that implement that, and it's not even disabled on some chips. So there must be benchmarks somewhere showing how worthwhile it is. And implementing 256b SVE has different issues depending on how you do it. 4x256b vector ALUs are more power hungry than generally useful. 2x256b is only beneficial over 4x128b if you're limited by decode width,…

I'd say that the theoretical ability to gang units together would be appealing.

If you have four 128-bit packed SIMD, you must execute 4 different instructions at once or the others go to waste. With SVE, you could (in theory) use all 4 as a single, very wide vector for common operations if there weren't a lot of instructions competing for execution ports. You could even dynamically allocate them based on expected vector size or amount of vector instructions coming down the pipeline.

Additionally, adding two 2048-bit vectors using NEON (128-bit packed SIMD) would require 16 add instructions while SVE would require just one. That's a massive code size reduction which matters for I-cache and the frontend throughput.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#198
post #156

Earlier quoted context omitted.

From what I’ve read previously, Apple has a special licensing deal already as they were part of founding Arm, although I don’t know if there’s any details on exactly how that works.

That seems like something people just made up, seeing as Apple didn't use ARM for something like a decade or two after that. However, Apple basically commissioned ARMv8 in the first place to develop the A/M chips, so that presumably helps.

> Apple didn't use ARM for something like a decade or two after that.

They used the ARM610 in the Newton in 1993 (ARM was founded in late 1990) and then an 8 year gap to the iPod in 2001 (ARM7TDMI which are ARM designs.) Their first in-house ARM design (I believe) is the iPhone 4 in 2010.

They definitely didn't "architect/design ARM" for nearly a couple of decades after founding ARM, yeah, but they did use them.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#199
post #156

Earlier quoted context omitted.

From what I’ve read previously, Apple has a special licensing deal already as they were part of founding Arm, although I don’t know if there’s any details on exactly how that works.

That seems like something people just made up, seeing as Apple didn't use ARM for something like a decade or two after that. However, Apple basically commissioned ARMv8 in the first place to develop the A/M chips, so that presumably helps.

Apple cofounded ARM for use in the Newton product line; they released new Newton products from 1993-97 and discontinued them in 1998. They then used ARM again for the iPod, released in 2001.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#200
post #170
post #127

Earlier quoted context omitted.

ARMv9 is just ARMv8.5 with 4 extra extensions. It's not a complete overhaul like the ARMv7 to ARMv8 change was. It's more comparable to x86 chips with AVX-512 and chips without AVX-512. 99% of your code is the same, but the compiler will generate SSE, AVX, and AVX-512 variants and choose the correct one based on the CPU.

Are there any extensions that ARMv9 is required to have? I'm looking through the reference manuals and those 4 extra extensions are all marked as "OPTIONAL" for ARMv9.

I believe it requires the ARMv8.5 instruction sets (but maybe some of those are optional too?)
Post reply on HN