Arm Announces ARMv9 Architecture With SVE2

[wizard69]

Apple is pretty good at selling overpriced garbage and making overblown claims.

Err that has changed dramatically with M1. An M1 air makes many $2000 laptops look pathetic. As for the claims about X86 emulation, it is far better than I personally expected. Even so it is driving even more and more apps to transition to ARM native. More ARM native code means more ARM native code that can run on Linux based hardware. If nothing else Apples hardware is making the possibility of ARM based Linux systems an even greater possibility.

[60Hz]

Err that has changed dramatically with M1. An M1 air makes many $2000 laptops look pathetic.

Imagine being this naive and falling for Apple marketing memes.

[PerformanceExpert]

Only by comparison with machines using 12 nm GPUs. Once the machines with 7 nm GPUs come online, GPUs will again rule the day.


No, it's not. It's competitive and wins a decent number of benchmarks, but you really can't call it "fastest". Let's not go though this whole nonsense, yet again.

Once the N2-based servers start shipping, then you'll be able to make that claim. Until then, your agenda will have to cool it.

There is no doubt there will be faster supercomputers in the future, but today Arm is #1 without using GPUs. Remember this was a reply to a comment claiming there exist no fast Arm CPUs.

You can try to downplay it as much as you want, but beating the latest Milan on SPECINT using a 2-year old CPU, only 1/8th of the L3 cache, at 2/3rd of the power and half the price is a huge achievement (Milan ended up slower than I expected). And yes, next generation Arm servers should open up a large performance gap with x86.

[coder]

preaching about the year of the ARM desktop

Huh? Who is preaching that?

Now, it's a fact that this is the year of the ARM Apple desktop, but it's not something I really care about -- merely a point of reference. More relevant is Pi v4, but that launched in 2019. More relevant, still, is the prevalence of Chromebooks in education.

all video games (which is the no1 factor behind a platform's adoption and that is a historical FACT) are still made for x86. Period.

If we were talking about ARM taking over the mainstream desktop anytime soon, you'd have a point. Still, emulation remains a viable path for some, and should enable most games not at the cutting-edge.

Long-term, phone-based gaming and Nintendo Switch should remove any doubts about the potential of ARM as a gaming platform.

So yeah, you can use your arm distro but forget about any proprietary code.

Again, emulation offers a viable path for most.

I can see the waves of billions of users coming on ARM Linux.... NOT.

Android phones have billions of users, and they're ARM Linux. I'm sure Chromebooks have sold in the hundreds of millions, by now. Technically, the ARM-based ones are ARM Linux. Raspberry Pi has sold tens of millions.

And if we go back to just talking about ARM (because somehow your post went from talking about ARM desktops to ARM Linux), you really have to include both MS and Apple.

If you look at the trend lines, they're all moving in the general direction of ARM. The Linux part gets a bump from Chome OS and Android, but we all know Google is moving away from Linux, at some point. Still, Pi has introduced millions more to the Linux world than we could've predicted, and Linux runs the cloud (which I think is what most of us are really focused on).

So, I'd say the future for ARM and Linux both look pretty bright. Furthermore, ARM looks particularly ascendant in the cloud. That's as specific as I'm going to be, however.

[coder]

Apple is pretty good at selling overpriced garbage and making overblown claims.

You can find plenty of independent benchmarks of x86 code running on their M1, in emulation.

And I referenced Apple only to point out the potential of emulation. I do not own any Apple products, nor would I recommend them. Rather than "garbage", my complaints are that they take good (often excellent) tech and nerf the implementation. Worse yet, their whole walled garden thing.

[Almindor]

That's what emulation is for! Apple published pretty good emulation performance of x86 code on their M1 -- I think someone mentioned 75%?

Yes why not, and then another 50% drop for the Proton thing you're already forced to run a game through. Grrrrreat!

[coder]

Yes why not, and then another 50% drop for the Proton thing you're already forced to run a game through. Grrrrreat!

I was replying mostly to the "anything closed-source" part. There's a lot of closed-source software where performance under emulation would be fine. Of course, there will be some that's not.

It's not a 100% solution, but that doesn't mean it should be ignored.

[archsway]

And there's no real case for a big.little configuration, like you have in in a phone SoC. That just adds cost, only to benefit a very small number of users running them off battery power. The main reason other SBCs have a big.little configuration is that they're using existing SoC chips made for things like tablets, whereas the Pi's SoC is now purpose-made by Broadcom specifically for the Pi (the original Pi's SoC was targeted at set-top-boxes).

I thought big.LITTLE was also for getting good performance for both single-core and multi-core workloads—little cores give more performance than big cores for a certain die area, but just having many little cores isn't useful for single-core.

[coder]

I thought big.LITTLE was also for getting good performance for both single-core and multi-core workloads—little cores give more performance than big cores for a certain die area, but just having many little cores isn't useful for single-core.

Well, I'm not sure what you mean about single-core workloads benefiting from big.little, but you're right that if little cores offer more performance-per-area and the SoC designer has extra silicon (and licensing) budget to play with, then it could be an effective way to add a little more multithreaded performance. This seems to be the rationale behind Intel's upcoming Alder Lake's use of little cores.

In the case of the Pi, I think they squeezed in everything they could. If they had any further area to play with, it sounds to me like it would've gone to the GPU, which is clearly its weak spot. Together, its A72 cores and clock speed are already a huge jump over v3's A53 cores.

[Neuro-Chef]

I'm really excited. They need ATX motherboards and socketed cpus pronto!

And a sane, standardized way of booting that crap, maybe..
Honestly, ARM performance is not the problem. Lack of driver support for end user devices and the need for device-specific OS images and/or ridiculous "flashing" processes is where it sucks against x86. So hard that even Windows 10 gives you more freedom of choice than Android, even LineageOS..