Raspberry Pi 2: Linaro(ARMv7) vs Raspbian(ARMv6) Benchmarks!

[mikronauts]

Since the release a lot of people (myself included) have been wondering if recompiling Raspbian for ARMv7 would significantly speed it up.

Linero is compiled for ARMv7 … Raspbian is compiled for ARMv6… which is faster?

I re-ran the benchmarks I used for my recent Raspberry Pi 2 Model B Review on Linaro… you read the results for yourself in my latest article:

Raspberry Pi 2: Raspbian vs. Linero (ARMv6 vs ARMv7)
http://www.mikronauts.com/raspberry-pi/ ... -vs-armv7/

[Mennims]

Nice review! Surprised to see I'm the first and so far the only one to like your page. You just saved me from wasting time. Lot's of it. Thank you!

[mimi123]

The memory benchmarks suggests that libcofi_rpi is not enabled( from github.com/simonjhall/, installed as default in Raspbian since ages.)

[ric96]

Wow unexpected!!
Armv6 code is performing better than v7

[EtonMess]

I guess three years of optimisations in Raspbian really do demonstrate that code comes before iron when pursuing performance and efficiency together. It also seems to have proven the idea that by placing people in a resource constrained environment, people will find ways of making things work better, rather than just being lazy and letting the CPU clock speed, any number of hardware tricks take care of performance for you.

When I heard about this Linaro distribution yesterday, there were early reports of it being much quicker than Raspbian. Was that the perceived user interface fluency? It made me wonder if this could put the RP Foundation into a dilemma, and the community into a fork by diverting some of the community away from the established, stable and supported distribution on which most of the projects are based. I know there as always been room for several OSes on Raspberry Pi, but there has always been a clamour for Ubuntu etc., and if another distribution were to become more popular than the established, what then?

[evaskp]

Although Linaro is a bit slower, so I still use it. Then we'll see what comes in the future.
Linaro has no optimization yet, so I think that it is doing very well.

/Krister

[jamesh]

The memory benchmarks suggests that libcofi_rpi is not enabled( from github.com/simonjhall/, installed as default in Raspbian since ages.)

Is that the Armv6 assembler optimised memxxx library? That's targeted at Armv6 specifically, I wonder if there is an equivalent NEON optimised version that can be used?

[mimi123]

The exact cause after analysis is that Linaro uses the powersave governor, which caps the CPU at 600MHz.
Try adding "force_turbo=1" to config.txt or change the governor to something else.

[plugwash]

More generally these benchmarks are worthless because there are way too many other differences between the images which dwarf the change you were trying to measure.

A fair test would be a bare (with no raspberry pi foundation packages) raspbian system VS a bare debian armhf system.

[mikronauts]

Mennims - thank you, and you are welcome

mimi123 - there is always room for more optimization!

ric96 - not too surprising, code optimized for years vs. new port.

EtonMess - optimization helps and I am sure Linaro will get faster.

evaskp - I agree, Linaro will get faster.

jamesh - Good question. I am sure NEON optimized mem*() and str*() would help both Raspbian and Linaro.

mimi123 - benchmarks show that it was running at 900Mhz, and lscpu confirms that.

plugwash:

I agree that micro benchmarks are generally useless, except when they fit your applications profile to a "T".

Having said that, these benchmarks address the ARMv7 compile vs. ARMv6 compile question at least as far as currenly available Debian (Raspbian) and Ubuntu (Linaro) are concerned.

As Linaro is freshly hatched, it will benefit more from further optimization than Raspbian.

That however does not invalidate the fairness of the comparison between the two current images... basically "a bird in hand is worth more than two in the bush".

Regarding bare metal - I managed to find the time to write & report on these results, however I do not have the time to go to bare metal, and optimize for ARMv7.

[ShiftPlusOne]

More generally these benchmarks are worthless because there are way too many other differences between the images which dwarf the change you were trying to measure.

A fair test would be a bare (with no raspberry pi foundation packages) raspbian system VS a bare debian armhf system.

I've done that and the tests for things which don't use neon were identical.

[mikronauts]

I would have expected the potential for dual issue to have at least a bit of a boost, and SysBench 0.4.12 CPU test showed about a 15% increase - could it be using NEON?

More generally these benchmarks are worthless because there are way too many other differences between the images which dwarf the change you were trying to measure.

A fair test would be a bare (with no raspberry pi foundation packages) raspbian system VS a bare debian armhf system.

I've done that and the tests for things which don't use neon were identical.

[jamesh]

I would have expected the potential for dual issue to have at least a bit of a boost, and SysBench 0.4.12 CPU test showed about a 15% increase - could it be using NEON?

More generally these benchmarks are worthless because there are way too many other differences between the images which dwarf the change you were trying to measure.

A fair test would be a bare (with no raspberry pi foundation packages) raspbian system VS a bare debian armhf system.

I've done that and the tests for things which don't use neon were identical.

NEON would give > 15% I think.

What exactly are we comparing here?

[ShiftPlusOne]

I would have expected the potential for dual issue to have at least a bit of a boost, and SysBench 0.4.12 CPU test showed about a 15% increase - could it be using NEON?

More generally these benchmarks are worthless because there are way too many other differences between the images which dwarf the change you were trying to measure.

A fair test would be a bare (with no raspberry pi foundation packages) raspbian system VS a bare debian armhf system.

I've done that and the tests for things which don't use neon were identical.

No idea. I would like to play around with this linaro distro a bit to see what's really different. I saw no difference in sysbench results between raspbian and debian, so this is interesting.

[mikronauts]

SysBench 0.4.12 CPU test running on Raspbian vs. Linaro on the same Raspberry Pi 2 B

I suspect it is not NEON, but possibly the increase may be due to dual issue scheduling.

I wonder if gcc does more optimization (possibly due to ARMv7) under Linaro - this is supported by compiling Emacs taking roughly 20% longer under linaro, from the same source tarball, same configuration (--without-x).

I may play some more with gcc options this weekend, I left it installed on one of my Pi2B's.

I would have expected the potential for dual issue to have at least a bit of a boost, and SysBench 0.4.12 CPU test showed about a 15% increase - could it be using NEON?

NEON would give > 15% I think.

What exactly are we comparing here?

[mikronauts]

Agreed, it is quite interesting. Best guess - gcc is compiled for ARMv7, and attempts dual issue optimizations with -O2 ... mind you, that is only a guess.

I would have expected the potential for dual issue to have at least a bit of a boost, and SysBench 0.4.12 CPU test showed about a 15% increase - could it be using NEON?

]

No idea. I would like to play around with this linaro distro a bit to see what's really different. I saw no difference in sysbench results between raspbian and debian, so this is interesting.

[Heater]

Don't be to enamoured with Linaro.

A couple of years back I was building a Pascal application on Linaro on an ISEE IGEPv2 board: https://www.isee.biz/products/igep-proc ... pv2-dm3730 the performance was terrible until I figured out I had to rebuild the Free Pascal compiler with the right options to take advantage of the particular ARM variant on there.

[mikronauts]

Thanks Heater, good to know.

Trying it out was a quick way for me to run some ARMv7 vs. ARMv6 tests.

Raspbian provides a snappier desktop experience, even though it is compiled for ARMv6, so I am likely to mostly run Raspbian

Don't be to enamoured with Linaro.

A couple of years back I was building a Pascal application on Linaro on an ISEE IGEPv2 board: [/url]https://www.isee.biz/products/igep-proc ... pv2-dm3730[/url] the performance was terrible until I figured out I had to rebuild the Free Pascal compiler with the right options to take advantage of the particular ARM variant on there.

[ssvb]

Is that the Armv6 assembler optimised memxxx library? That's targeted at Armv6 specifically, I wonder if there is an equivalent NEON optimised version that can be used?

This is more about finding optimal memory access pattern and prefetch tuning. NEON does not have much to offer for memcpy by itself. Sure, NEON has much wider 128-bit registers, however ARM instructions LDM/STM (load/store multiple) also can read/write a large chunk of memory at once with just a single instruction. Here is how different memory access methods perform on RPi2, compared to RPi1

Basically, Cortex-A7 now uses automatic hardware prefetching, which is very nice for general purpuse code written in C. All assembly based copy methods provide roughly ~1GB/s speed (which is a good thing, that's how a proper processor should behave). If trying to use the PLD instruction for software prefetch, it is important to hit the beginning of a cache line (incr vs. wrap benchmark numbers show it), just like libcofi_rpi does

Still some of the memcpy implementations might be faster than the others when working with the data in L1/L2 caches.

[markatlnk]

What gcc flags would force the ARMv7 optimizations? I would expect the code not to run on the ARMv6 devices.

[jamesh]

What gcc flags would force the ARMv7 optimizations? I would expect the code not to run on the ARMv6 devices.

See here http://www.raspberrypi.org/forums/viewt ... 33&t=98354