-
-
awl29
-
- Posts: 30
- Joined: Tue Aug 23, 2016 9:32 pm
Fri Sep 16, 2016 11:59 am
by
awl29 » Fri Sep 16, 2016 11:59 am
Hello,
ejolson wrote:
Just out of curiosity, do you have any benchmark results showing whether the Cortex-A53 core is faster or slower in 64-bit mode? As I'm interested in using these boards for teaching numerical methods with a focus on high performance computing and parallel processing, it would be great to know how 64-bit mode compares to the 32-bit mode. My understanding is that the quad-issue quad-core NEON FPU unit is available and performs about the same in either mode, but there may be other considerations.
while you may be right about the fact that there is no basic difference in how Cortex-A53 performs in 32-bit vs. 64-bit mode, the real issue is
inherent support for the ARMv8-A architecture/instruction set in any 64-bit kernel and 64-bit userland apps (Linux distribution), while the instruction set for the existing 32-bits kernel 3.4.y as well as the Linux distributions available for S5P6818 is still
armv7l (32-bit ARMv7 compatibility mode), so neither the current kernel nor userland code can leverage any of the new features of ARMv8 architecture (regardless whether in 32-bit or 64-bit mode).
Compared to the sysbench "cpu-max-prime" results shown here:
http://www.golem.de/news/banana-pi-m3-vs-lemaker-hikey-bastelrechner-mit-bumms-1603-119720-3.htmlperformance of my ARMv8 32-bit NanoPC-T3 pretty much resembles that of ARMv7 32-bit BananaPi M3 (Allwinner A83T SoC, octa-core ARM Cortex-A7 CPU up to 2.0GHz) - especially when taking the lower max CPU clock speed for the NanoPC-T3 compared to BPi-M3 into consideration:
sysbench --num-threads=1 --cpu-max-prime=10000 --test=cpu runBananaPi M3: 159 sec. (single thread), 40 sec. (4 threads), 21 sec. (8 threads)NanoPC-T3: 172 sec. (single thread), 43 sec. (4 threads), 21 sec. (8 threads)Note that in the link given above, for Lemaker Hikey (Kirin 620 SoC with octa core ARM Cortex-A53 64-bit CPU up to 1.2GHz) the respective figures on a 64-bit kernel in ARMv8/aarch64 mode were significantly better:
Lemaker Hikey: 12 sec. (single thread), 3 sec. (4 threads), 2 sec. (8 threads)So these are the impressive gains to be leveraged when the SoC really uses ARMv8 architecture/instruction set rather than ARMv7 compatibility mode.
I don't know (that's why I raised this question in my very first post in this thread) whether it would be feasible to recompile the existing kernel (and subsequently, userland code) in
32-bits ARMv8 (does that exist? which toolchain to use?) for the time being. To the best of my knowledge, the "natural" way to ARMv8 for other SoC vendors typically includes upgrading to a 64-bit kernel...
I hope this clarifies why I definitely think that it is highly important for FriendlyARM to provide real ARMv8 (and then, inherently 64-bit) support as soon as possible.Best,
awl