Linux 4.19 Kernel Benchmarks On The Raspberry Pi

[QwertyChouskie]

cortex a53 are in-order.

Honestly what i find strange is that there is still no complete 64 bit support, that would give it quite a boost in performance.

You can run Ubuntu 18.04 LTS arm64 on the RPi3 with the Ubuntu arm64 kernel using U-boot. You can also do the same with the 3B+ so long as you use the Ubuntu 18.04.2 image, which (should) include kernel 4.18. I have a 3B+ running Ubuntu 18.04 arm64 and it works fine, though sometimes I wonder if it's actually slower than Raspbian despite being command line only (no XOrg running).

http://cdimage.ubuntu.com/releases/18.04.2/release/ubuntu-18.04.2-server-arm64.iso

[willmore]

Honestly what i find strange is that there is still no complete 64 bit support, that would give it quite a boost in performance.

There's a few reasons that I've heard. For one, they only have 1GB of memory. Since I've run 64bit versions of Linux on other ARMv8 chips with only 1GB, I never considered that much of an excuse. Also, they have 512MB boards running 32bit Linux, so those boards should be under even more memory pressure. If they can run a 32bit OS in 512MB, they can run a 64bit on in 1GB.

The other big reason is that the processor that runs the Rpi--the VideoCore IV--can only address 1GB of memory. That means there will be no 'compatable' RPI board with >1GB of memory ever. There are other Broadcom chips with newer video cores that can support >1GB, but they won't be 100% compatable with existing RPI software. From their messaging, the Foundation seems very reluctant to make that leap.

I agree that going 64 bit on the A53 can provide huge improvements i performance, but they're only in very specific areas, so maybe they don't see the benefit? After all, they're not even optimizing their distro for the newer cores. That alone would pay off huge benefits. When it comes down to it, you don't use an RPI (or Raspbian) if you're looking for performance.

[Raka555]

I might not remember correctly, but wasn't it just the ARM implementations with out-of-order execution which were impacted by Spectre?

Cortex-A8 is in-order while Cortex-A9 and above is out-of-order and with that in mind RPi 3 should need to have Spectre mitigations while RPi 1 and 2 shouldn't?
Someone who knows more than me about this, please correct me because this doesn't make up so I'm obviously misunderstanding something.

EDIT: Found the answer on wikipedia https://en.wikipedia.org/wiki/Spectr...bility)#Impact

Since the RPI is Cortex-A53 and not vulnerable, why do they have to take a hit I wonder ...

[Raka555]

cortex a53 are in-order.

Honestly what i find strange is that there is still no complete 64 bit support, that would give it quite a boost in performance.

I am glad its is still 32-bit since the PI does not have more than 2G RAM.

Going 64bit will effectively 1/2 your D-cache size and do more or less the same for main memory, depending on use case, since 64bit word takes 2x the space of 32bit word.

Are there any CPU instructions/registers added in 64bit mode on ARM?

Basically you always want 32bit mode.
The only reason to have 64bit is if you want to address more memory directly.
32bit PAE can also address more memory, but slightly slower and with a 2G per process restriction.

The other reason you might want 64bit any way is if they added lots of CPU instructions/registers in 64bit mode (like on AMD64).
That is why x32 arch exits. It is 32bit on x64 with new instructions/registers available in 32bit mode. (All specInt etc benchmarks are x32 these days, because for the same instruction/register set, 32bit is almost always faster than 64bit)

So if you jump on the 64bit band-wagon just for the hell of it, you will in general be on a slower wagon

Michael This might be something you would be interested in testing on the RPI

[stevea]

Orange pi boards are cheaper and beyond rasperry pi boards. Used laptops cost the same as orange/rasperry pi systems. Android tv boxes can run Debian and they include cases and power units. For embedded development arduino and mbed boards suit better.

No one sane would even think of designing a used laptop into an embedded design. No hot spares, no direct replacements, unmountable, lunking-big KB display that generally have no use in embedded (embedded generally means no HMI) , and whopping big PSU - no reliable specs. You must be trolling!

If you need to add drivers to the kernel (most often true for embedded) then you should anticipate massive headaches with Allwinner. The MALI vid is a pre-eminent nightmare (thanks to ARM Ltd IMO). Allwinner regularly violates GPL including proprietary code in the kernel in direct violation of GPL; NVRAM, Vid, HDMI setup . My general experience (30+ years in embedded) is that Chinese vendors have absolutely no compunction about openly violating GPL and delivering functional kernels that cannot be re-built. Neither Rpi3*, nor OrangePi* have full schematics, power specs nor thermal specs- ALL are required for any competent embedded design.

Yeah save $5 and lose 100 consulting hours. You must be ignorant.
Post on some topic you understand.

[stevea]

I am glad its is still 32-bit since the PI does not have more than 2G RAM.

Going 64bit will effectively 1/2 your D-cache size and do more or less the same for main memory, depending on use case, since 64bit word takes 2x the space of 32bit word.

Are there any CPU instructions/registers added in 64bit mode on ARM?

Basically you always want 32bit mode.
The only reason to have 64bit is if you want to address more memory directly.
32bit PAE can also address more memory, but slightly slower and with a 2G per process restriction.

The other reason you might want 64bit any way is if they added lots of CPU instructions/registers in 64bit mode (like on AMD64).
That is why x32 arch exits. It is 32bit on x64 with new instructions/registers available in 32bit mode. (All specInt etc benchmarks are x32 these days, because for the same instruction/register set, 32bit is almost always faster than 64bit)

So if you jump on the 64bit band-wagon just for the hell of it, you will in general be on a slower wagon

Michael This might be something you would be interested in testing on the RPI

Raka555 - first, I must say I agree broadly with your reasoning and suggest everyone read and SERIOUSLY CONSIDER your very intelligent post before my comments.
Despite MY misgivings abt 64bit, memory/binary size in small systems - the early x86_64 binaries were indeed almost 2x the size, but as compilers/linkers improved the foot-print factor shrunk to about ~1.35x. The instruction space is marginally worse, and the data/address space is indeed almost 2x (but depends on some constant extension instructions for x86..). I've never performed the equivalent tests on ARM, but any serious embedded implementor should before they decide. MY impression is that Raka555 is right; the ARM instruction set isn't very memory space efficient at 64bit, and that limited memory in small system dictate 32bit.

[tuxd3v]

I might not remember correctly, but wasn't it just the ARM implementations with out-of-order execution which were impacted by Spectre?

Cortex-A8 is in-order while Cortex-A9 and above is out-of-order and with that in mind RPi 3 should need to have Spectre mitigations while RPi 1 and 2 shouldn't?
Someone who knows more than me about this, please correct me because this doesn't make up so I'm obviously misunderstanding something.

EDIT: Found the answer on wikipedia https://en.wikipedia.org/wiki/Spectr...bility)#Impact

Well, I guess that are there more than what they are telling us...

Cortex-A7 is not there,
BUT cortex A9 is, and cortex A8 is there..

Cortex A9 is a Big core, so its out of order i think..!?

But cortex A7, and A8, implement the Armv7-A also..
So why they are not putting there cortex a7, if cortex a8 is affected?

Is cortex A8 out of order?

Also,
If is Cortex R7 , which is Armv7-A affected, why its not there the cortex a-7?
Both implement Armv7-A...

For what I understand Cortex-A53, and maybe Cortex a35, are not affected,
BUT ...cortex A57,
Which is an improved version of cortex A53 is affected...

[t.s.]

My Amlogic S912 TVbox can run latest mainline kernels. The Amlogic meson project is for Amlogic Socs.
http://linux-meson.com/doku.php

Brand and model? Did the hardware (GPU, Wifi, LAN, etc) works well? And did it include RTC battery? Still searching tv box that have rtc with workable wifi and lan, and with close to or have mainline kernel.

[Licaon]

Linux myrpi1 4.14.98+ #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l GNU/Linux

When exactly will 4.19 come?

Regarding 64bit support, I do seem to have +100Mb RAM used on a RPi3+ vs RPi1/256Mb on the exact same server setup (exact is relative, same daemons, Debian Buster vs Raspbian).