Question Anyone using ARM CPUs/SOCs?

[whm1974]

I've been looking at Pine64.org products, mainly the upcoming Pinebook Pro and PineTAB, also about reading the ROXK64 Pro as well. Awhile back I was considering getting Raspberry Pi 3B+ for getting into SBCs, I really not sure what I could use for it for. And yes a low cost notebook, even ARM based ones will be far more useful for.

Other then my cheap smartphone, I have no experience with non-x86 systems. So how much usability with reasonable performance I can expect out ARM SOCs such at the Rockchip RK3399 Hexa-Core such as the Pinebook Pro and ROCK64 Pro uses

While I intend to buy the Pinebook Pro, I am wondering about ARM SOCs and ARM based PCs in general using Linux.

 

[soresu]

Non trivial ARM64 software needs to become available. Adobe is going some way towards ARM migration with full featured Photoshop on iOS and Premiere Rush, but Autodesk have no significant ARM software at all apart from Sketchbook. And thats only DCC software, there is very little high end games being ported to ARM, mainly due to space restrictions in mobile platforms with the slow rollout of 256 GB+ solutions. PS3/XB360 era games have long since been attainable on ARM SOCs but very few of them have been ported due to those space restrictions.

As for Linux and Android apps on Chromebooks, Google shot themselves in the foot there. Mainline Linux software is predominantly x86 and Android apps are predominantly ARM, meaning with Chrome you either get great Linux support with an x86 CPU, or great Android support with an ARM SOC. I'm still confused why so few Chromebooks have ARM SOCs when their performance is often favourably compared to Intel based counterparts.

 

[soresu]

It might also be worth noting that SHIELD TV failed as an independent games console due to lack of interest porting games to ARM, and even cash flush nVidia balked at doing continuous ports themselves, as evidenced by the promised Crysis 3 port that never materialised. Even now, Half Life 2 remains a SHIELD exclusive after years.
With any luck, the new EPIC store may alter the status quo in games development for Android.

 

[Shivansps]

And Windows is running Windows apps - who would have guessed that. Its just that x64 Windows running x86 and x64 Windows apps and ARM Windows is running ARM32, ARM64 and x86 Windows apps. Thats all to it. There is no inherent restriction whatsoever - contrary to Windows RT, which was running only ARM32 UWP.

In you argument you fail to realize, that most user only use a fraction of the available apps. As they become available under native AArch64 execution or running reasonable under emulation Windows ARM devices certainly are an option. Apps i am using 90% of the time are already native AArch64 - some of them i just compiled. You have to realize that re-compilation is an easy task for those who are familiar with it - it is not more complicated than under Linux.

If your betting that x64 CPUs will eventually achieve the efficiency - and thus the performance under certain power budget - of ARM CPUs you are up for a big disappointment. Either the Windows ecosystem can adapt to new architectures or its deemed to vanish. This holds in particular now, since alternative architectures do not have a technology disadvantage compared to Intel anymore. Intel/AMD had it much too easy to get away with its crappy x64 ISA in the past.

Windows cant adapt, UWP failed multiples times already, this is why there is x86 emulation in the first place, and it will be x64 as well.

This is like the 678th thread ive participated about how ARM is much better than x86 and x86 is doomed in the past 10 years, it is always "next year you will see", the only thing im saying here is if ARM wants to take on Windows, they to be competitive with X86 cpus thats it, once that happens you will realise as a horde of ARM notebooks is hard to ignore. Right now they are slower, the devices with them cost a lot, they lack x64 support and the mayor advantage is a GPU i cant even use as games are x64 now. Simple, dont try to tell me or anyone else what apps i should be using, before buying a Windows 10 S ARM or a Windows 10 ARM with x86 support i would rather get a Chromebook. You just cant beat Android + Linux ecosystem with the crappy UWP.

 

[DrMrLordX]

As for Linux and Android apps on Chromebooks, Google shot themselves in the foot there. Mainline Linux software is predominantly x86 and Android apps are predominantly ARM, meaning with Chrome you either get great Linux support with an x86 CPU, or great Android support with an ARM SOC. I'm still confused why so few Chromebooks have ARM SOCs when their performance is often favourably compared to Intel based counterparts.

I don't see that as being a big disadvantage. As Chromebooks proliferate, you'll get more development targeting ChromeOS specifically, based on which hardware becomes dominant in the platform. Right now it's cheap x86 chips dominating the space. That could easily change.

 

[Shivansps]

I don't see that as being a big disadvantage. As Chromebooks proliferate, you'll get more development targeting ChromeOS specifically, based on which hardware becomes dominant in the platform. Right now it's cheap x86 chips dominating the space. That could easily change.

Software matters a lot more than the platform it is running on. Google move of allowing android apps is brillant. This is why i would not use a Windows 10 S regardless of the platform.

 

[whm1974]

Software matters a lot more than the platform it is running on. Google move of allowing android apps is brillant. This is why i would not use a Windows 10 S regardless of the platform.

Yeah many many platforms failed due to lack of software or said software was hard to find. Remember WinNT was on MIPS and PowerPC workstations and were DOA due to lack of applications.

 

[DrMrLordX]

Software matters a lot more than the platform it is running on. Google move of allowing android apps is brillant. This is why i would not use a Windows 10 S regardless of the platform.

Point being, ChromeOS is an either/or proposition. If you want one for cheap Linux you get an x86 one, if you want it for cheap Android-on-something-better-than-a-tablet then you get an ARM one. Demand from the consumer will define which hardware variations become dominant in the ChromeOS ecosystem.

 

[Thala]

This is like the 678th thread ive participated about how ARM is much better than x86 and x86 is doomed in the past 10 years, it is always "next year you will see"

I have no influence on what strange messages you are trying to believe -wherever you heard them the 678th time the past 10 years. How about just sticking to my argument when replying to my posts?

Right now they are slower, the devices with them cost a lot, they lack x64 support and the mayor advantage is a GPU i cant even use as games are x64 now.

Either you are blind or just uninformed. Evidence shows, that ARM devices are faster than x64 counterparts under the same power budget - that is the very definition of higher power efficiency. Of course you already showed your ignorance early in this thread by using benchmarks, where the ARM devices ran x86 code under emulation - and trying to sell this as prove of your statements. Meanwhile we have Cortex A76 devices on the marked and ARM is going to release Cortex A77 in 1H2019 - not to mention Apple A12.

 

[DrMrLordX]

Well battery life is more concerned nowadays.

I don't see what that password generator has to do with the topic at hand.

 

[soresu]

Thala, bear in mind SoC implementation of any new high end ARM core lags at least 5-6 months behind its announcement, which is has been May the past 2 years, with the earliest implementation being Huawei/HiSilicon Kirin in october or november, next earliest being Snapdragon in late Q1 to early Q2 the following year.

Having said this, I do wonder if any non-Server implementations of Ares, Zeus and Poseidon may make it into flagship devices. I've still little idea of what they will bring, though A65-AE would seem to suggest SMT is forthcoming at the least, and possibly SVE or a new high end client side SIMD instruction set. The old research paper detailing ARGON came to mind when the new HELIUM SIMD launched with ARMv8.1-M, at this point NEON seems long in the tooth and SVE seems to be aimed at HPC wins more than anything else.

 

[Shivansps]

Either you are blind or just uninformed. Evidence shows, that ARM devices are faster than x64 counterparts under the same power budget - that is the very definition of higher power efficiency. Of course you already showed your ignorance early in this thread by using benchmarks, where the ARM devices ran x86 code under emulation - and trying to sell this as prove of your statements. Meanwhile we have Cortex A76 devices on the marked and ARM is going to release Cortex A77 in 1H2019 - not to mention Apple A12.

Ok i see you refuse to understand why Windows is Windows. If you dont understand why someone uses Windows instead of Linux, MAC, or Android thats no my problem.

Im going to ask you a simple question then. Why ARM presence in desktop and notebooks is nearly non-existant? There is always market for a power efficient SoC. AMD sold AM1 cpus and the only thing they were good for is power efficiency. OK by AMD own words they were a failure, but they existed and archived far more than ARM did so far.

 

[soresu]

Interestingly, some Wine developers just blew past Microsoft and beat them to running x64 apps on ARM64, link here.

The performance is limited by QEMU x86-ARM binary translation, but hopefully some console emulator types can swoop in and make some improvements there, I've no idea if Google have invested anything in this area for the sake of their Android emulator.

 

[Nothingness]

Interestingly, some Wine developers just blew past Microsoft and beat them to running x64 apps on ARM64, link here.

The performance is limited by QEMU x86-ARM binary translation

Microsoft x86 32bit->ARM translator performance is about 1/2 of native, while QEMU is more like 1/4. MS has the advantage of using a targeted JIT while QEMU is portable, and that's why Wine devs got a working emulator faster than MS

, but hopefully some console emulator types can swoop in and make some improvements there, I've no idea if Google have invested anything in this area for the sake of their Android emulator.

Android is using QEMU and get dev done through Linaro as far as I know. I don't think they are very concerned by speed.

 

[whm1974]

Ok i see you refuse to understand why Windows is Windows. If you dont understand why someone uses Windows instead of Linux, MAC, or Android thats no my problem.

Im going to ask you a simple question then. Why ARM presence in desktop and notebooks is nearly non-existant? There is always market for a power efficient SoC. AMD sold AM1 cpus and the only thing they were good for is power efficiency. OK by AMD own words they were a failure, but they existed and archived far more than ARM did so far.

If ARM wants to get into the PC Market, then they need to push for a Common Reference Platform with standard Firmware just like x86/x86-64 PCs have.

Right now ARM is a good mess as far as OS support goes.

 

[Thala]

If ARM wants to get into the PC Market, then they need to push for a Common Reference Platform with standard Firmware just like x86/x86-64 PCs have.

Right now ARM is a good mess as far as OS support goes.

Now thats not entirely true. Windows for example needs an UEFI, which among other things support device enumeration and some base drivers. The availability of UEFI was the key of installing Windows on Raspberry Pi, a device where Windows were never supposed to run. Likewise with a proper UEFI you can also install Windows (ARM version) on QEMU.
Keep in mind we are talking about a usual binary distribution of Windows, where no special adaptation to HW architecture are compiled via source code modifications.

 

[soresu]

The new ARM Helios (Neoverse E1/Cortex A65-AE) core sounds interesting for lower end systems assuming it ever makes it there. Even without SMT you get 1.4x A53 in Integer IPC (1.8x with SMT), and 2x A53 in FP IPC (2.4x with SMT). All of this drawing 183 mW per core at 2.5 GHz.

Probably wont benefit high end phones massively, excepting management of power sucking background apps - however, assuming it has a lower license cost vs A76, it could make a compelling main core for Rasberry Pi 4.

Also, with recent improvements to web layout engines like Servo targetting high parallelism, I could see this level of efficiency working well for the lower end phone market.

 

[Shivansps]

The new ARM Helios (Neoverse E1/Cortex A65-AE) core sounds interesting for lower end systems assuming it ever makes it there. Even without SMT you get 1.4x A53 in Integer IPC (1.8x with SMT), and 2x A53 in FP IPC (2.4x with SMT). All of this drawing 183 mW per core at 2.5 GHz.

Probably wont benefit high end phones massively, excepting management of power sucking background apps - however, assuming it has a lower license cost vs A76, it could make a compelling main core for Rasberry Pi 4.

Also, with recent improvements to web layout engines like Servo targetting high parallelism, I could see this level of efficiency working well for the lower end phone market.

RPI has 3 MAIN issues right now

1) too little ram
2) I/O Bottleneck
3) GPU is crap (in case you want to do any gaming on it)

None of those are related to the CPU cores that are kinda good compared to everything else.

Not sure what they are going to do with RPI 4... but increasing CPU speed with those limitations....

 

[soresu]

Further improvements to the nascent Panfrost driver may help the problem of low GPU performance by at least opening up the market for open source mobile GPU beyond Broadcom..

Link here.

 

[soresu]

Yet more improvements to the Panfrost driver - seems to be picking up steam.

Link here.

 

[Shivansps]

Now there are finaly both USB, SD and Ethernet drivers for RPI / Windows 10 ARM

Its slow but faster that i expected running off a slow SD card and only 1GB of ram... the bad thing is the basic Microsoft Display driver is not providing software DX9 or DirectDraw as it should, so i cant run any game on it. The funny part of the day is that Windows was trying to install the 32-bit Onedrive...

 

[Thala]

the bad thing is the basic Microsoft Display driver is not providing software DX9 or DirectDraw as it should

The framebuffer display driver supports Direct3D via Reference or WARP driver options (both using SW rendering). Not sure where you got from that it does not? So you should be able to run Direct3d games both native (ARM64) or via emulation (x86).
I do imagine this to be very slow though.

 

[Shivansps]

The framebuffer display driver supports Direct3D via Reference or WARP driver options (both using SW rendering). Not sure where you got from that it does not? So you should be able to run Direct3d games both native (ARM64) or via emulation (x86).
I do imagine this to be very slow though.

It does not, they give a error about no D3D or DirectDraw Support. What is kinda strange because thats not what dxdiag says. At least DirectDraw games should run.

 

[Thala]

It does not, they give a error about no D3D or DirectDraw Support. What is kinda strange because thats not what dxdiag says. At least DirectDraw games should run.

Which game does give an error? I did test with SNES9x (native ARM64) using 3d3 driver and it does initialize and run.

 

[DrMrLordX]

Damn, MS has some work to do there.

 

[Shivansps]

Which game does give an error? I did test with SNES9x (native ARM64) using 3d3 driver and it does initialize and run.

Old 32 bit games, like Age 1& Age 2 (No DirectDraw Support), Freelancer and Populus 3 (No D3D support).

Damn, MS has some work to do there.

Well... 1GB of ram is not really enoght to run W10 and a SD or USB 2.0 is not really a good way to run Windows at all. But it does kinda work with very fast SD cards. I expect RPI4 to actually be able to run W10 ARM ok, just dont expect very high performance out of A55 cores that i would expect to be present on RPI4.