Linux Benchmarks – Intel J3455 Apollo Lake vs Z3735F Bay Trail vs RK3399 and Other ARM Platforms

Since I’ve just installed Ubuntu 17.10 on MeLE PCG35 Apo, I decided I should also run some benchmarks comparing with other ARM and x86 Linux platforms I’ve tested in the past.I was particularly interested to compare the performance of Intel Apollo Lake processors (Celeron J3455 in this case) against higher end ARM processors like Rockchip RK3399 (2x A72, 4x A53) since systems have a similar price (~$150+), as well as against the older Bay Trail processor to see the progress achieved over the last 2 to 3 years.

To do so, I used Phoronix Benchmark Suite against Videostrong VS-RK3399 results (RK3399 development board):


The benchmark first issued a warning about “powersave” governor, but I still went ahead, and once completed I change it to “performance” governor:


…and ran the tests again. All results are available on OpenBenchmarking.

Let’s address the governor results first. cpufreq-info reports that powersave governor can also switch between 800 MHz and 2.30 GHz (turbo freq).


As we’ll see from the results below pitting “MeLE PCG35 Apo – Ubuntu 17.10” (with powersave) and “MeLE PCG35 Apo- Ubuntu 17.10 Performance” that the governor settings did not matter one bit on the results, at least for the six benchmarks I ran.

Note that “MeUbuntu 14.04.3” represents MeLE PCG02U TV stick running Ubuntu 14.04.3. Every platform runs a different OS and kernel, so keep in mind the results may differ slightly (up or down) with different version. But as we’ll see the differences in performance are large enough that it likely does not matter that much.
John the Ripper password cracker, a multi-threaded benchmark, shows the Apollo Lake processor is clearly ahead of Rockchip RK3399 hexa-core processor, and the fastest ARM platform, Banana Pi M3, is equipped with an Allwinner A83T octa-core Cortex A7 processor @ 2.0 GHz. The Bay Trail system is over  twice as slow as the Apollo Lake one, also note the larg-ish standard deviation (+/- 83.72) due to some cooling problem in the small form factor.

C-Ray is another multi-threaded benchmark, and here Rockchip RK3399 SoC does fairly well, but still but quite as well as the Celeron J3455.

Smallpt, yet another multi-threaded benchmark, does not really change the order with MeLE PCG35 Apo well ahead.

Himeno, a linear solver of pressure Poisson, must be using some x86 specific instructions or optimizations, as Intel platforms are well ahead, with Celeron J3455 about 2.5x faster than Rockchip RK3399 board.

OpenSSL is the domain of Intel platforms likely benefiting from Advanced Encryption Standard instruction set (AES-NI). Performance improvement between Bay Trail and Apollo Lake is also impressive here. You’d need 10 Raspberry Pi 3 to match MeLE PCG35 Apo in this particular test.


Intel is normally better with SIMD accelerated multimedia application, and FLAC audio encoding (single threaded) confirms that.

I was expecting a close fight between Rockchip RK3399 and Celeron J3455, but RK3399 only has two fast Cortex A72 cores against four x86 cores in the Intel Apollo Lake SoC.

 

68
Leave a Reply

avatar
68 Comment threads
0 Thread replies
11 Followers
 
Most reacted comment
Hottest comment thread
19 Comment authors
vamrsAnonymousdogs breathnobitakunDanand Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
tkaiser
Guest
tkaiser

Two small remarks:

1) On Intel systems with intel_pstate driver running (Sandy Bridge or above and obviously a somewhat recent kernel) powersave and performance are expected to give similar results in synthetic benchmarks (since ramping up CPU clockspeeds fast enough). But on other platforms depending on kernel version powersave vs performance can result in huge performance differences (since powersave can lead to the CPU cores remaining on lowest allowed clockspeed all the time while performance chooses the maximum as on Intel)

2) OpenSSL performance and AES-NI:if we’re talking about AES here then ARMv8 SoCs with AES crypto extensions (like RK3399 that is missing above — why?) should be able to compete. At least when we (Armbian community) did some tests a while ago single threaded Banana Pi M3 ‘performance’ at 1.8 GHz (Cortex-A7) was ~30 times lower compared to a Cortex-A53 at 1.3 GHz with ARMv8 crypto extensions enabled.

willy
Guest
willy

For now I’ve been quite disappointed by RK3399’s performance. I managed to make my build farm run on the H96max at 1.8 GHz (A72) + 1.4 GHz (A53), and at 1.8 GHz, the A72 shows slightly lower performance than the RK3288 on the MiQi (ie 16.2 sec instead of 16.0 for a build). And that’s the best I can take out of it, it’s in 32-bit (armv7t or armv8l). In 64-bit (armv8), it’s about 10-15% slower for the same task. It was said that the A72’s architecture was very close to the A17, the former with 3-decode and 5-issue, the latter with 2-decode and 5-issue, but I suspect we’re caping out on the ALU after the instructions are decoded so the A72 isn’t faster in the end. By the way the test using JtR above shows the 4-core MiQi 35% faster than the 6-core RK3399, so that tends to confirm that there’s definitely a corner case where it doesn’t shine unfortunately.

blu
Guest
blu

@willy
Those settop boxes traditionally have notoriously bad thermal design, and a 28nm A72 can get really hot at near-2GHz — have you monitored the throttling?

Manuel
Guest
Manuel

Why not add a comparative about power consumption? It would be interesting…

Thanks.

theguyuk
Guest
theguyuk

Unless it is like for like hardware the results have no place in the real world.

Most TV boxes watch TV and comparing a £30 less board against a £130 + Intel J3455 Apollo Lake. Is like racing a child’s peddle bike against a F1 Racer. Funny but no value.

How about benchmarking a Xbox One against a Intel J3455 Apollo Lake? It would have just as much real world use.

willy
Guest
willy

@blu
Yes absolutely, and it’s really at 1.8 GHz while running such tests, and doesn’t throttle. BTW the advertised 1.5 and 2.0 GHz frequencies are not even part of the frequencies list at all, that’s the beauty of “up to”, it probably means that it can go “up to 2.0 GHz if you hack your DTB”.

Honestly the perf is not bad at all and it heats less than the 3288 at the same performance level, it just doesn’t have enough cores to compete with it. The RK3288 has 4 strong cores, but the 3399 has only two, and the 4 remaining A53 are just jokes compared to them. Basically you have less than an odroid C2 sharing the cache and RAM bandwidth with the two A72. It’s fine to run SSH or probably to run background music on a tablet but that’s almost all, as they’re less than half of the performance of the large ones.

The A75 is said to be a real performer. We’ll see when it’s available. For now I’m sticking to the A17.

bob
Guest
bob

ARM is not power efficient, it’s just cheap in some TV box :

50$ A53 x4 cpu burn = 5Watt
200$ intel I3 5005U cpu burn = 15-20W
Intel is 10x more powerfull in benchmark, so 3X more efficient benchmark pt / watt.
Conclusion expensive Arm is a no go

tkaiser
Guest
tkaiser

@willy
I don’t get it. Your workload scales horizontally? And 2 x A72 are as fast as 4 x A17?

theguyuk
Guest
theguyuk

@bob
The real fact is most Arm SoC spend most of the time not running at the claimed top speed, they can only run very sort bursts.

Even over designed cooler cannot help.

blu
Guest
blu

@bob
There are no quad-core A53 that a 5005U would be 10x as powerful — the average IPC difference between Broadwell and A53 is approx 2-2.5 in favor of the former. There might be isolated cases where AVX2-centric scenarios can produce 10x difference, but how common are they?

btw, 410c is a severely underclocked SBC — its normal ‘stock-cooling’ clock is ~600MHz IIRC.

bob
Guest
bob

@theguyuk
Right about idle/low use cpu need, for that i don’t understand strategy of arm don’t provide hw encoder/decoder driver for a good power efficiency…it’s a shame for their business

And maybe we miss a compilation souce code benchmarck, because i don’t think my little H3 compile 10X slower than my intel cpu…

Jonathan
Guest
Jonathan

What are the RAM speeds and configurations on these boxes? I suspect that may tell as much or more of the story, especially if the benchmark is blowing out the icache on the ARMs.

tkaiser
Guest
tkaiser

@Jonathan
The Phoronix test suite as well as the results on openbenchmarking.org should be considered useless garbage especially when trying to compare different platforms in the way it’s done here. Most of the ‘benchmarks’ use questionable or no optimization settings at build time so results vary a lot with the OS used and the platform it’s running on (compiler shipped and default settings).

I’ve seen some of these ‘benchmarks’ performing 3 times faster on the same hardware just by exchanging the OS and thereby default compiler and settings (switching from GCC 4.x to 6.x for example).

RooTer
Guest
RooTer

@theguyuk
when thinking about (relatively) low power server I actually do think whenever should I go with arm and x86 and such benchmark did made sense for me.
You can argue like other commenters the metric used was not the best, but the idea itself? no. Look at the scores, they are clearly comparable, especially if you think about the price involved for the performance.

tkaiser
Guest
tkaiser

RooTer :
@theguyuk
when thinking about (relatively) low power server I actually do think whenever should I go with arm and x86 and such benchmark did made sense for me.

Which kind of server task(s) could be represented by the collection of synthetic benchmarks above? Really curious 🙂

Eversor
Guest
Eversor

@bob
That may be true for these cheap implementations of A53 cores. Have a look at Nvidia Jetson TX2 benchmarks. Phoronix did some a good while back. Same is true for Apple’s cores.

m][sko
Guest
m][sko

My results for Hikey 960
https://pastebin.com/twarU4eC

tkaiser
Guest
tkaiser

@m][sko
Can you please provide output from

blu
Guest
blu

@cnxsoft
Those benchmarks are extremely sensitive to compiler version and flags. One wrong flag and/or compiler version can make all the difference. It’s essential when doing synthetic benchmarking to know very well what a given compiler produces from the sources (e.g. ‘Hey, it’s not generating AES instructions!’, ‘Hey, it produced this snafu in the inner-most loop!’, etc)

raul
Guest
raul

Arm boards for the general use case have lost their initial promise. Lack of support from Arm, lack of proper software support from vendors, and the throttling and performance has left the promise in tatters.

And the cost of higher performing boards, even the 3399, takes one into low power lower priced Intel platforms at which point its game over as the software support on Intel just cannot be compared.

But for boards like the Pi or Odroid with better software support, at least things like a low power HTPC makes sense. And if the SOC provider decides to provide support, sometimes even a NAS or router can become possible. But on the whole the ecosystem showed early promise but years later its not really gone anywhere,

willmore
Guest
willmore

@raul
I would say that there are vendors who don’t suffer the problems you mention. ODROUD from Hard Kernel for one provides boards without cooling problems. They support their boards with software.

tkaiser
Guest
tkaiser

blu :
Those benchmarks are extremely sensitive to compiler version and flags. One wrong flag and/or compiler version can make all the difference.

And that’s the main reason no one with a brain in his head should use this terrible Phoronix crap. I used Jean-Luc’s last results to rely on and tested on a ROCK64: https://openbenchmarking.org/result/1710279-TY-1710254TY63

According to the Phoronix results ROCK64 shows just 41% OpenSSL performance compared to the octa core Banana Pi M3 and less than 9 percent compared to the Apollo Lake box (obviously the latter making use of AES-NI here). So obviously the Phoronix ‘benchmark’ uses weird compiler flags and makes no use of ARMv8 crypto extensions. Let’s have a closer look and compare the openssl binary Phoronix built from sources with the one the distro contains:

So Phoronix managed to build the binary that strangely that it performs 2.4 times lower than the distro package every real-world task will use. But that’s still not talking about ARMv8 crypto extensions, so let’s have a look too (full command output for both tests — check especially build options!):

Hey, the Ubuntu package that every real-world task on this device will use is just 4 times faster with really small chunks of data and up to 20 times with 8K data blocks. Srsly? Why do we use a ‘benchmark’ suite that is well known since years to only produce numbers without meaning especially when trying to compare different architectures?

@cnxsoft
In case you have the Apollo Lake box still running with Ubuntu… care to repeat just those 4 OpenSSL runs (one time using the distro’s openssl binary and one time the one Phoronix built. I’m especially interested in the build options reported since I’m wondering why AES-NI is used on Intel for the sign/verify benchmark)

tkaiser
Guest
tkaiser

@cnxsoft
Thank you. So on x64 we’re talking about:

With both tests the PTS binary scores even better than Ubuntu’s (but on Intel totally different compiler flags are used and those make the real difference) while on ARM the PTS binaries score 2.4 to 20 times lower than the Ubuntu distro package. So when switching from stupid passive benchmarking mode to active benchmarking an interesting approach would be to analyze compiler flags above, then rebuild then openssl binary and only stop when results with active ARMv8 crypto extensions outperform the AES-NI numbers.

At least it should be obvious that this Phoronix crap is not an option to compare performance of different architectures since it ignores everything that’s important and is only able to provide a bunch of numbers without any meaning.

blu
Guest
blu

@tkaiser
Nice catch. Yes, that’s part of what I was talking about — in this particular case what phoronix has produced is literally apples to shotshells.

theguyuk
Guest
theguyuk

I know lots will think I am nuts for suggesting it, but if you want TV boxes and ARM SBC to improve, people need to be encouraged to play more 3D games on them.

Just look how demanding 3D games have pushed Game Console and Gaming PC hardware. The same market can push ARM hardware.

Does the average office really need a i7, i5 to write letters etc, no.

Network gear is a different market same as financial data, Movie editing etc

willy
Guest
willy

@tkaiser
No Thomas, I meant 2*A72 are exactly as fast as 2*A17, or about half as fast as 4*A17. Yes the build workload scales reasonably well (provided the memory bandwidth is there and the number of files to build is high enough and these files are about the same size). So for this workload, the RK3288 is almost twice as fast as the RK3399 just because it has twice the number of really usable cores.

willy
Guest
willy

@bob
Power efficiency doesn’t compare like this because it decreases with peak performance. You need to compare the power drawn by a device capable of achieving a given peak performance. For example, my RK3288, while less power efficient than my Atom 8350, is significantly faster (15-20%). These two are the only ones in this thermal envelope capable of delivering more or less comparable performance. If I want higher performance on x86, I have to seek a significantly larger design (a much faster one) which will eat more power than the RK3288. It might be a bit more power efficient but the reality is that this efficiency isn’t interesting anymore due to extra cooling solutions.

Also the price per task is important in certain environments, just like the price per peak MIPS in other ones. In my case, for a build farm, I have to find a sweet spot between the power envelope, the price and the performance. With a very high price I can find a high frequency core i7 in a small thermal envelope being 3 times faster than my RK3288 but it will cost 20 times the price and will need more cooling.

theguyuk
Guest
theguyuk

I always understood that the main trick Intel use, is to do more things in memory, and have as much of the data as you can, as close to the CPU cores as possible.

Bigger faster cache and faster memory?

willy
Guest
willy

@theguyuk
That’s true for high end CPUs, when the cache algorithm are very advanced, allowing almost instant access to any memory location. But having compared memory performance between a few Atoms and the RK3288 in dual-channel configuration shows a significant difference in favor of the latter on in-cache and RAM patterns.

One feature helping x86 CPUs is the trace cache replacing the instruction cache. The principle is to store decoded and fused instructions, saving a few pipeline stages for hot code paths. This also allows some old CISC instructions (eg: “rep movs” for memcpy()) to be expanded to very efficient sequences that even possibly give hints to the cache about what lines to prefetch next, and when to flush the written ones, which is hardly possible using more RISC-like instruction sets.

The branch prediction on modern x86 is very efficient as well, inheriting from certain history mechanisms that once made the Alpha shine. These are typically the stuff that you observe on high performance calculations, crypto and such stuff.

wzyy2
Guest
wzyy2

RK3399 is more like Celeron N series, since Celeron J series usually have a higher power consumption.

tkaiser
Guest
tkaiser

@blu
Well, almost all of those Phoronix ‘benchmarks’ are totally broken since how they’re built and executed is not with providing useful numbers in mind but only focusing on ‘portability/compatibility’ so that PTS users being tricked into believing they would do serious benchmarking get all those tests compiled on their hosts regardless of platform, OS and environment.

Isn’t it really ‘funny’ when I’m interested in encryption performance of an inexpensive ARM thingie and compare with a way more expensive Intel box that Phoronix is telling me the ARM thing would be 11 times slower since the ‘test suite’ only produces BS numbers while using OpenSSL’s own benchmark mode avoiding ‘PTS crippled’ binaries ARMv8 crypto extensions seem to outperform AES-NI:

Whether/how these synthetic benchmarks relate with real-world encryption workloads like VPN endpoints/gateways or full disk encryption is another story — but if I’m told the ARM platform would be 11 times slower than the Intel box (while the official benchmark with normal openssl binaries shows quite the opposite)… who would start to even look into details?

While I fully understand that clueless people prefering data over information and like staring at nice looking graphs made of numbers without meaning truly love the Phoronix test suite I don’t understand why serious blogs like this here rely on the useless garbage numbers this tool creates, especially in situations where the PTS fails most: comparing different CPU architectures.

blu
Guest
blu

@willy
Re x86 i-cache — Atoms, at least up to Silvermont, don’t have either uop cache or trace cache (latter was something found in Netburst; former appeared in SNB). The only i-cache optimisation employed by Atoms (read: Silvermonts) is op boundary marks in the i-cache, and thus Atoms are often decode-bound (one of the reasons the Cortexes fair so well against them).

tkaiser
Guest
tkaiser

@cnxsoft
Yes, PTS is using $some defaults in ‘fire and forget’ mode. Sometimes build settings are hard encoded in the makefile, sometimes relying on what the environment defines (so if for example EXTRAOPTFLAGS=’-O3′ in /etc/profile some ‘benchmarks’ will show magnitudes better scores later, eg. the infamous Smallpt stuff) and sometimes just using what the operating system’s default compiler does for whatever reasons.

Please think about again: what PTS reports as ‘OpenSSL’ performance is RK3328 being 11 times slower than the J3455. While with another benchmark and when using a sanely built openssl binary the ARM SoC easily outperforms the Intel Celeron. Sorry, but this is not serious benchmarking. This is just what the PTS is well known for: a collection of numbers without meaning.

And this does not only apply to architecture comparisons (eg. ARM vs. Intel) but also to ‘benchmarks’ comparing membes of the same architecture. Your comparison above of Apollo Lake vs. Bay Trail is more importantly a comparison of Ubuntu 14.04 with 17.10 –> GCC 4.8.4 vs. GCC 7.2 — it is well known how different some of the Phoronix ‘benchmarks’ score depending on GCC version. Publishing such numbers as above definitely does not help getting an idea about ‘hardware performance’. Not with the way Phoronix creates numbers.

Danand
Guest

If you are interested: This is how it looks on a ODROID XU4 ( Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPU ) on a Ubuntu 16.04.3 LTS – Kernel 4.13.0

# openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 14966032 aes-128-cbc’s in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 4189907 aes-128-cbc’s in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 1104424 aes-128-cbc’s in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 279763 aes-128-cbc’s in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 35038 aes-128-cbc’s in 3.00s
OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,–noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
The ‘numbers’ are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 79818.84k 89384.68k 94244.18k 95492.44k 95677.10k

# openssl speed rsa4096 -multi 4
OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,–noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
sign verify sign/s verify/s
rsa 4096 bits 0.014487s 0.000225s 69.0 4438.8

Since it’s a 8 Core system, I also add the relevant 8 thread result:

# openssl speed rsa4096 -multi 8

sign verify sign/s verify/s
rsa 4096 bits 0.009657s 0.000149s 103.6 6698.3

nobitakun
Guest
nobitakun

I’m sorry but talking about efficiency comparing two different fabs is nonsense, each platform is designed for what they are, everything said.

tkaiser
Guest
tkaiser

Danand :
This is how it looks on a ODROID XU4

Same numbers as in the referenced link in my first comment above (we tried to collect numbers from A7, A9, A15, A17, A53 — with and without ARMv8 crypto stuff — and A72. Currently A17 and A72 still missing).

With RSA signing the Exynos doesn’t look that bad but when it comes to AES encryption the SoC is far behind compared to those SoCs with ARMv8 crypto extensions, both considering ‘raw performance’ and especially ‘performance per Watt’. An ODROID XU4/HC1 doing AES stuff on the CPU cores compared to an ARMv8 SoC with crypto extensions enabled is ~40 times as inefficient if we keep consumption increase also in mind (details in the aforementioned link to Armbian forum):

blu
Guest
blu

@tkaiser
Let me know if and what A72 benchmarking you need – I have one macchiatobin idling here.

tkaiser
Guest
tkaiser

@blu
Would be great to get full output from

Compiler and version the binaries were built with are important of course. And if you can results from github.com/ssvb/tinymembench would also be great.

willy
Guest
willy

@tkaiser
On H96-Max, I get this on the 2 [email protected] GHz :

# openssl version -a
OpenSSL 1.0.2k 26 Jan 2017
built on: reproducible build, date unspecified
platform: linux-aarch64
options: bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) idea(int) blowfish(ptr)
compiler: aarch64-gcc47l_glibc218-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
OPENSSLDIR: “/usr/share/openssl”
(built on linaro gcc-4.7.4, not rebuilt since).

# taskset -c 4,5 openssl speed rsa4096 -multi 2
sign verify sign/s verify/s
rsa 4096 bits 0.019186s 0.000257s 52.1 3887.3

And this on the 4 A53 cores at 1.4 GHz :
# taskset -c 0-3 openssl speed rsa4096 -multi 4
sign verify sign/s verify/s
rsa 4096 bits 0.022229s 0.000310s 45.0 3229.1

For AES, the numbers are pretty good :
A72:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 465434.04k 938648.81k 1221223.85k 1300021.93k 1349861.38k

A53:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 170812.96k 464463.87k 783981.14k 982121.81k 1059921.92k

On the MiQi (at 1.8 GHz as well) :
# openssl speed rsa4096 -multi 4
rsa 4096 bits 0.016024s 0.000230s 62.4 4342.0
# openssl speed rsa4096 -multi 2
rsa 4096 bits 0.031990s 0.000463s 31.3 2159.8

Here the 64-bit architecture definitely helps!

blu
Guest
blu

Model: MACCHIATOBin-8040
Clock: CPU 1300 [MHz]
DDR 800 [MHz]
FABRIC 800 [MHz]
MSS 200 [MHz]

macchiato:~$ ./gov.sh # columns: core governor clock
0 performance 1300000
1 performance 1300000
2 performance 1300000
3 performance 1300000

tinymembench: https://pastebin.com/bg1Wha41
openssl: https://pastebin.com/WRnVa07L
7z: https://pastebin.com/Z6RFZLkh

dogs breath
Guest
dogs breath

bench mark we want to see is huawei fastest versus apple latest

tkaiser
Guest
tkaiser

@blu
Thank you! This is DDR4, right? As a quick reference Jean-Luc’s tinymembench numbers for RK3399 from few weeks ago. And the 7-zip numbers are the only ‘generic CPU’ benchmark resuilts I need for my use cases (server stuff).

A72 with ARMv8 crypto extensions performs really impressive, this time also with very small chunks of data (the A53 implementation suffers here somewhat).

@willy
I put your AES encryption numbers and the Celeron results together:

When running on the A72 cores RK3399 outperforms J3455 always and is already 2 times faster with 128 byte chunks. Really nice to see these crypto extensions working so well with AES. Now curious how PCIe performance with this SoC looks like.

blu
Guest
blu

@tkaiser
Yep, DDR4 at the lowest rate (1600) — board and DIMM are capable of 2400, but I keep mine at the lowest setting for minimal active cooling (side-mounted 80mm silent fan).

On an unrelated note, Teres-A64 acquired! ; ]

Anonymous
Guest
Anonymous

@tkaiser

Maybe file a bug against PTS instead of just complaining on a random article on another site?

PTS is mostly used/developed on x86_64 so they probably aren’t even aware it doesn’t work properly (much slower than distro defaults) on arm.