Quick'n dirty OMAP5432 vs TX2 compilation time test

[Linux-SWAT]

Hi,

I ran a linux-4.11-rc4 omap2plus_defconfig compilation on each board, using all cores.

SlackwareARM-current armhf, gcc version 5.4.0 .

OMAP5432 has 2 x 32bit CPU, 1.5GHz, sources on mSATA.
TX2 has 6 x 64bit CPU (2 x Denver custom cores + 4 x A-57), 2GHz, sources on eMMC.

Note: I don't know yet the TX2 power mode, cpu-freq reports max freq for each CPU.
Funnily, the CPU order is 0: A-57, 1: Denver, 2: Denver, 3: A-57, 4: A-57.

Multithread test :

OMAP5432, time make -j3:
real 50m23.971s
user 85m0.370s
sys 11m0.250s

TX2, time make -j7:
real 13m8.161s
user 59m46.012s
sys 3m11.764s

Now you can slap these results in the face of the people who say that OMAP5432 is outdated.

--EDIT:

A more accurate 1:1 bench :

OMAP5432, one A-15 # time taskset 0x1 make -j1
real 92m17.345s
user 78m8.160s
sys 9m54.720s

TX2, one A-57 # time taskset 0x1 make -j1
real 52m26.339s
user 48m31.200s
sys 2m3.852s

TX2, one Denver # time taskset 0x2 make -j1
real 63m43.535s
user 58m31.592s
sys 3m22.508s

In terms of ol' wild west 1:1, the A-57 is clearly ahead.

--EDIT 2:

TX2, time make -j1
real 81m2.049s
user 79m14.060s
sys 4m55.548s

 

[fusion_power]

Who is TX2?
Me as a non-dev-but-end-customer prefer tests in displaying hard, brutal, pure ingame FPS Performance. You could chose an 3DMark or FPS Shooter or something like that pls. I'm curious.

 

[Kev2442]

Damn, I wish the next CPU board would be Tegra X2-based, but I'm afraid of the power consumption.

 

[Linux-SWAT]

Who is TX2?
Me as a non-dev-but-end-customer prefer tests in displaying hard, brutal, pure ingame FPS Performance. You could chose an 3DMark or FPS Shooter or something like that pls. I'm curious.

I can't test 3D for now.
But it will be unfair for the OMAP5432 because there's a bleeding edge Nvidia GPU inside the TX2. It would be more interesting to test a newer SGX.

 

[levi]

So it looks like the OMAP5 spent 96 minutes of CPU time to compile, while the TX2 took only 63 minutes - combined with the fact you ran the TX2 compile on more than twice the number of concurrent processes (because the CPU ships with more cores) meant it completed in about a quarter of the time. I'm not sure this is a brilliant demonstration of how powerful the OMAP5 is, although if you had a way of monitoring current consumption while you did this, it might score better at perf/W.

 

[Exophase]

I don't think the TX2 Jetson board will run anywhere close to 2GHz for all six processors at the same time. It'd be good to have some monitoring of this to get an idea, I guess? According to nVidia (https://devblogs.nvidia.com/parallelforall/jetson-tx2-delivers-twice-intelligence-edge/) if you run it in "Max-P" mode you get either 4x A57 @ 2GHz, 2x Denver @ 2GHz, or all six cores at 1.4GHz.

Also not so sure that -j3 and -j7 are the best batch sizes for either board respectively. I usually use 2x core count, but the use of eMMC (relatively low latency file access) and nVidia's heterogeneous cores complicate things. Guess it'd be interesting to see how things look for different batch sizes. OMAP5 is getting a nearly 2x throughput boost while TX2 is getting fairly close to 4x. I suspect that the Denver cores aren't being used at all.

Damn, I wish the next CPU board would be Tegra X2-based, but I'm afraid of the power consumption.

I'm put off by the use of Cortex-A57 instead of A72 or A73 in 2017 but the Switch shows these SoCs have enough room to scale down. And OMAP5 isn't exactly an efficiency king itself. I have little doubt that Tegra X2 can offer significantly better CPU performance at the same power consumption limits that would be necessary for the OMAP5 in Pyra.

 

[Linux-SWAT]

So it looks like the OMAP5 spent 96 minutes of CPU time to compile, while the TX2 took only 63 minutes - combined with the fact you ran the TX2 compile on more than twice the number of concurrent processes (because the CPU ships with more cores) meant it completed in about a quarter of the time. I'm not sure this is a brilliant demonstration of how powerful the OMAP5 is, although if you had a way of monitoring current consumption while you did this, it might score better at perf/W.

The correct interpretation is :
OMAP, 50mn with 2 cores -> 100mn with one.
TX2, 13mn with 6 cores -> 78mn with one.
So it means one TX2 is core is only 1.28 time more "powerful".
[doublepost=1491085321,1491084940][/doublepost]@Exophase, I'm 100% positive the 6 core were used.
But indeed, I forgot to check the power mode.

Optimal -j n is reached with number of cores + 1, I also used cores x 2 a while ago but it's worthless.

 

[vcoleiro1]

Correct me if I'm wrong, but arn't you guys saying the same thing, but just looking at different angles

I think levi was looking at the overall performace difference of the TX2 SOC while Linux-Swat is focusing on a per core performance difference.

IF all 6 cores are being used in the test for the TX2. Doesn't that mean that the overall CPU performance metric could be seen as

TX2) 6 x 1.28 ie 7.68
Omap5) 2 x 1 ie 2.

ie 7.68 vs 2 ie TX2 is 3.84 times the performance of the Omap5

then of course there is the unknown GPU perfomance difference

I don''t know, it's early in the morning here, perhaps I interpreted something incorrectly

 

[Linux-SWAT]

I look at the real time and get a core:core comparison.
It's not scientific, only clock-based, which anyway is what the end user sees.

I'd also add that the LPDDR4 oh the TX2 has a 58.4 GB/s bandwidth, but it should not have much influence on this bench.

--Edit, cpufreq reports all 6 cores at 2.04 GHz.

 

[levi]

I looked at real time+sys time, as presumably those system calls are servicing stuff your code needed from the kernel to do the compilation. real+sys is the real per core run time I believe.

Edit: Sorry, I should say real+sys is the real CPU time aggregated across all cores. Not sure where my head was at when I wrote the above.

 

[sepulep]

The correct interpretation is :
OMAP, 50mn with 2 cores -> 100mn with one.
TX2, 13mn with 6 cores -> 78mn with one.
So it means one TX2 is core is only 1.28 time more "powerful".
[doublepost=1491085321,1491084940][/doublepost]@Exophase, I'm 100% positive the 6 core were used.
But indeed, I forgot to check the power mode.

Optimal -j n is reached with number of cores + 1, I also used cores x 2 a while ago but it's worthless.

the 1.28 is not surprising, since it also has 33% higher clock - so it doesn't speak bad of the omap design...it would be interesting to know the power usage though (the figure of merit is perf/watt)
I think the -j n+1 might skew things a bit (its 50% more processes than cores for the omap, while only 16% more for TX2)

 

[klapse]

Hooray!

 

[Exophase]

I really doubt that 2GHz Cortex-A57 would beat 1.5GHz Cortex-A15 by only 28% unless there's some other major non-CPU bottleneck, or the former is using 64-bit mode in an application that heavily penalizes it.

Without knowing that frequency doesn't go down with higher core usage and without knowing that the core balancing is the same I don't think it's reasonable to make a single threaded performance comparison by looking at the total CPU time. Especially since TX2 is a heterogeneous architecture where the Denver cores could be faster (or slower?) than the A57 cores. It'd be much better to just compare results at -j1 for this.

 

[Linux-SWAT]

I updated the first post with a 1:1 bench.

 

[Grench]

OK - so now we have a pretty accurate reading on net performance.

So - what happens with performance per watt? Performance per cost?

By TX2, do you mean this?
https://devblogs.nvidia.com/parallelforall/jetson-tx2-delivers-twice-intelligence-edge/

That says it is a 7.5W part. Using a single core, though, can we measure performance per watt? Estimate it?

It also says it is a $399 module. BUT that module is a pretty complex item with more components. Can we get to performance per price unit between the two?

 

[Exophase]

I updated the first post with a 1:1 bench.

Thanks, that's pretty informative. Especially the Cortex-A57 vs Denver comparison.

The prevailing justification I've heard for the 4+2 A57/Denver arrangement on TX2 is that the Denver cores are useful for low threaded taskes and the A57 cores for high threaded tasks. This makes sense considering how much larger the Denver cores are. But it appears that for some tasks, even ones as important as GCC, A57 is faster on a per-core basis. This doesn't really surprise me. Denver is very wide, has some novel features (like read ahead) and very sophisticated software to optimize the code it's executing, but it still hits some fundamental limits by being in-order.

Also worth pointing out that on the old TK1-64 where Denver was first introduced it could run at up to 2.5GHz, or at least it was advertised to, while here two process advancements later it appears limited to 2GHz and I don't think they really improved it. Maybe it's not as power efficient as nVidia would have us believe.

OK - so now we have a pretty accurate reading on net performance.

So - what happens with performance per watt? Performance per cost?

By TX2, do you mean this?
https://devblogs.nvidia.com/parallelforall/jetson-tx2-delivers-twice-intelligence-edge/

That says it is a 7.5W part. Using a single core, though, can we measure performance per watt? Estimate it?

It also says it is a $399 module. BUT that module is a pretty complex item with more components. Can we get to performance per price unit between the two?

nVidia's claims aren't terribly clear and I'd really like to see some third party investigation here too. These days PMICs often have current gauges that you can use to read power draw, likely even down to separate voltage rails. But I have no idea how much of this is easily reported to user space in Linux.

I think to really get a good comparison between Pyra and Jetson TX2 you'd want to get full curves for how much power the whole SoC + RAM + PMIC uses when running an intensive benchmark (with the same assembly code on both platforms!) at many different clock speeds. Some measurements when the thing is at idle and asleep would also be very useful.

EDIT: ! take that back, the Denver 2 cores on TX2 can run at up to 2.4GHz. Is that what they were running at for this test?

EDIT2: Phoronix reports some power consumption numbers for TX2, I guess they're provided at least to the granularity of CPU power + GPU power: https://www.phoronix.com/scan.php?page=article&item=jetson-tegra-x2&num=2

 

[Linux-SWAT]

I ran a xboard chess game CPU vs CPU, only the two Denver are used.

# make -j1 doesn't seem to prefer a CPU, but peeks one Denver from time to time.

All CPUs have : 346 MHz - 2.04 GHz.
I can't use the power control userspace from nVidia as I kicked Ubuntu ARM 64, right away after being sure the board booted, for Slackware ARM 32.
That said it may only be scripts so I guess I must check.

Didn't use machine learning stuff for now.
I use nVidia 64bit kernel as it's not mainstream yet.

$ lscpu

Spoiler

Architecture: aarch64
Byte Order: Little Endian
CPU(s): 6
On-line CPU(s) list: 0-5
Thread(s) per core: 1
Core(s) per socket: 3
Socket(s): 2
Model: 3
Model name: ARMv8 Processor rev 3 (v8l)
CPU max MHz: 2035.2000
CPU min MHz: 345.6000
BogoMIPS: 62.50
L1d cache: 32K
L1i cache: 48K
L2 cache: 2048K
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32

$ cat /proc/cpuinfo

Spoiler

processor : 0
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

processor : 1
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x4e
CPU architecture: 8
CPU variant : 0x0
CPU part : 0x003
CPU revision : 0
MTS version : 37620520

processor : 2
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x4e
CPU architecture: 8
CPU variant : 0x0
CPU part : 0x003
CPU revision : 0
MTS version : 37620520

processor : 3
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

processor : 4
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

processor : 5
model name : ARMv8 Processor rev 3 (v8l)
BogoMIPS : 62.50
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 3

$ cpufreq-info

Spoiler

analyzing CPU 0:
driver: tegra_cpufreq
CPUs which run at the same hardware frequency: 0 3 4 5
CPUs which need to have their frequency coordinated by software: 0 3 4 5
maximum transition latency: 300 us.
hardware limits: 346 MHz - 2.04 GHz
available frequency steps: 346 MHz, 499 MHz, 653 MHz, 806 MHz, 960 MHz, 1.11 GHz, 1.27 GHz, 1.42 GHz, 1.57 GHz, 1.73 GHz, 1.88 GHz, 2.04 GHz
available cpufreq governors: interactive, conservative, ondemand, userspace, powersave, schedutil, performance
current policy: frequency should be within 346 MHz and 2.04 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.11 GHz.
cpufreq stats: 346 MHz:39.37%, 499 MHz:6.03%, 653 MHz:7.16%, 806 MHz:8.07%, 960 MHz:6.85%, 1.11 GHz:4.12%, 1.27 GHz:4.06%, 1.42 GHz:3.25%, 1.57 GHz:3.21%, 1.73 GHz:2.94%, 1.88 GHz:3.17%, 2.04 GHz:11.74% (1496)

analyzing CPU 1:
driver: tegra_cpufreq
CPUs which run at the same hardware frequency: 1 2
CPUs which need to have their frequency coordinated by software: 1 2
maximum transition latency: 300 us.
hardware limits: 346 MHz - 2.04 GHz
available frequency steps: 346 MHz, 499 MHz, 653 MHz, 806 MHz, 960 MHz, 1.11 GHz, 1.27 GHz, 1.42 GHz, 1.57 GHz, 1.73 GHz, 1.88 GHz, 2.04 GHz
available cpufreq governors: interactive, conservative, ondemand, userspace, powersave, schedutil, performance
current policy: frequency should be within 346 MHz and 2.04 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 806 MHz.
cpufreq stats: 346 MHz:14.89%, 499 MHz:3.87%, 653 MHz:3.27%, 806 MHz:2.67%, 960 MHz:3.72%, 1.11 GHz:3.52%, 1.27 GHz:3.25%, 1.42 GHz:2.86%, 1.57 GHz:2.99%, 1.73 GHz:2.69%, 1.88 GHz:3.31%, 2.04 GHz:52.96% (1146)

analyzing CPU 2:
driver: tegra_cpufreq
CPUs which run at the same hardware frequency: 1 2
CPUs which need to have their frequency coordinated by software: 1 2
maximum transition latency: 300 us.
hardware limits: 346 MHz - 2.04 GHz
available frequency steps: 346 MHz, 499 MHz, 653 MHz, 806 MHz, 960 MHz, 1.11 GHz, 1.27 GHz, 1.42 GHz, 1.57 GHz, 1.73 GHz, 1.88 GHz, 2.04 GHz
available cpufreq governors: interactive, conservative, ondemand, userspace, powersave, schedutil, performance
current policy: frequency should be within 346 MHz and 2.04 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 806 MHz.
cpufreq stats: 346 MHz:14.89%, 499 MHz:3.87%, 653 MHz:3.27%, 806 MHz:2.67%, 960 MHz:3.72%, 1.11 GHz:3.52%, 1.27 GHz:3.25%, 1.42 GHz:2.86%, 1.57 GHz:2.99%, 1.73 GHz:2.69%, 1.88 GHz:3.31%, 2.04 GHz:52.96% (1146)

analyzing CPU 3:
driver: tegra_cpufreq
CPUs which run at the same hardware frequency: 0 3 4 5
CPUs which need to have their frequency coordinated by software: 0 3 4 5
maximum transition latency: 300 us.
hardware limits: 346 MHz - 2.04 GHz
available frequency steps: 346 MHz, 499 MHz, 653 MHz, 806 MHz, 960 MHz, 1.11 GHz, 1.27 GHz, 1.42 GHz, 1.57 GHz, 1.73 GHz, 1.88 GHz, 2.04 GHz
available cpufreq governors: interactive, conservative, ondemand, userspace, powersave, schedutil, performance
current policy: frequency should be within 346 MHz and 2.04 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.11 GHz.
cpufreq stats: 346 MHz:39.37%, 499 MHz:6.03%, 653 MHz:7.16%, 806 MHz:8.07%, 960 MHz:6.85%, 1.11 GHz:4.12%, 1.27 GHz:4.06%, 1.42 GHz:3.25%, 1.57 GHz:3.21%, 1.73 GHz:2.94%, 1.88 GHz:3.17%, 2.04 GHz:11.74% (1496)

analyzing CPU 4:
driver: tegra_cpufreq
CPUs which run at the same hardware frequency: 0 3 4 5
CPUs which need to have their frequency coordinated by software: 0 3 4 5
maximum transition latency: 300 us.
hardware limits: 346 MHz - 2.04 GHz
available frequency steps: 346 MHz, 499 MHz, 653 MHz, 806 MHz, 960 MHz, 1.11 GHz, 1.27 GHz, 1.42 GHz, 1.57 GHz, 1.73 GHz, 1.88 GHz, 2.04 GHz
available cpufreq governors: interactive, conservative, ondemand, userspace, powersave, schedutil, performance
current policy: frequency should be within 346 MHz and 2.04 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.11 GHz.
cpufreq stats: 346 MHz:39.37%, 499 MHz:6.03%, 653 MHz:7.16%, 806 MHz:8.07%, 960 MHz:6.85%, 1.11 GHz:4.12%, 1.27 GHz:4.06%, 1.42 GHz:3.25%, 1.57 GHz:3.21%, 1.73 GHz:2.94%, 1.88 GHz:3.17%, 2.04 GHz:11.74% (1496)

analyzing CPU 5:
driver: tegra_cpufreq
CPUs which run at the same hardware frequency: 0 3 4 5
CPUs which need to have their frequency coordinated by software: 0 3 4 5
maximum transition latency: 300 us.
hardware limits: 346 MHz - 2.04 GHz
available frequency steps: 346 MHz, 499 MHz, 653 MHz, 806 MHz, 960 MHz, 1.11 GHz, 1.27 GHz, 1.42 GHz, 1.57 GHz, 1.73 GHz, 1.88 GHz, 2.04 GHz
available cpufreq governors: interactive, conservative, ondemand, userspace, powersave, schedutil, performance
current policy: frequency should be within 346 MHz and 2.04 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.11 GHz.
cpufreq stats: 346 MHz:39.37%, 499 MHz:6.03%, 653 MHz:7.16%, 806 MHz:8.07%, 960 MHz:6.85%, 1.11 GHz:4.12%, 1.27 GHz:4.06%, 1.42 GHz:3.25%, 1.57 GHz:3.21%, 1.73 GHz:2.94%, 1.88 GHz:3.17%, 2.04 GHz:11.74% (1496)

I don't know how to bench power.
[doublepost=1491367085,1491361877][/doublepost]TX2, time make -j1
real 81m2.049s
user 79m14.060s
sys 4m55.548s

 

[Exophase]

Phoronix says they got the power readings from somewhere in the sysfs. Sorry, I know that's not really that helpful.

 

[0x14f]

I don't know how to bench power.

For a very quick and dirty test could device of this type be of help maybe?


EDIT: adblock will block board's built-in amazon widget.

 

[Grench]

I wonder how much different the TX2 above would be from a Renesas H3. They're both A-57 quad cores plus other stuff. I poked around a bit and I haven't figured out what industry Nvidia is targeting with the TX2. Everything seems to just say, 'embedded,' which is a pretty broad statement anymore.

There are quite a few of these ARM based SoC systems appearing lately for non-phone applications with very robust video and audio capabilities. The way that cars have become computing platforms with multiple display screens, piles of cameras, expectations of high end multimedia support, connected moving hotspots, driver assist and more, has resulted in some very interesting SoC options coming from places that we might not ordinarily notice.

https://pyra-handheld.com/boards/threads/linux-on-arm-automotive-infotainment-socs.80145/

Automotive and embedded SoCs may be a good option to look into someday for Pyra board options. Having their SoC used in something like the Pyra could appear to them as business expansion instead of competition (automotive vs handheld markets).