Hints on improving performance
#1
So I have upgraded my trusty Asus Chromebook Flip C100P, now about five years old and running a hacked-together Debian system, with a PBP. After installing Armbian on it and doing some test builds, I can confirm that a build which on the C100P was taking 1m15 is now, on the PBP, taking... 1m30.

Er, oops.

The C100P has a Rockchip RK3288C 1.8GHz quad core. If I'd done my research properly, I'd have known that the Pinebook Pro has a RK3399 with 2x1.8GHz and 4x1.5GHz cores; they both have 4GB of RAM. Apparently having the extra two cores doesn't make up for not having four high-speed cores.

Any suggestions on if there's anything to do to speed things up?

- using arm32 binaries instead of arm64 binaries might help due to reducing memory bandwidth (pointers are half the size). The C100P is all arm32.
- the build uses twice the system time on the PBP than the C100P. On the PBP I'm using f2fs on the internal eMMC. On the C100P I'm using ext4... but the PBP's eMMC is way faster, so unless f2fs is vastly less efficient than ext4 that shouldn't make a difference, surely?
- I don't have accelerated graphics yet, so it could just be spending all its time updating the xterm... but building from the console produces the same numbers.
- I haven't found hard numbers for the clock speed yet. The two fast cores seem to max out at 1800MHz. Will they go faster?
  Reply
#2
...as a quick addendum, I've converted my Armbian system from arm64 to armhf; the build now takes about 90% of the time it used to, which isn't fantastic but which is definitely worth having. Actually doing the conversion is laborious and error-prone, though, so I wouldn't recommend it. 

For actual Debian you download a firmware binary containing uboot and the kernel, and then a generic arm64 partition containing the userland; there's only a PBP firmware for arm64. It might be possible to combine the arm64 firmware with the armhf userland (the kernel should be size-agnostic).
  Reply
#3
- Partition alignment, though I'm not sure if it's relevant to your benchmark: https://forum.pine64.org/showthread.php?tid=12290
- Overclocking: PBP seems to work good for most people at 2.0GHz/1.6GHz. There are reports of stable operation at 2.2GHz/1.8GHz. There's a dtsi file in this thread, I'm using without the highest frequencies: https://forum.pine64.org/showthread.php?tid=13506
  Reply
#4
Partition alignment: checked, I'm on a multiple of 8kB. (Start block 557056.) Still, worth a check, and it would have explained the oddly high system time I'm seeing during compiles.

Overclocking: hadn't actually thought about doing that. It looks like from the thread that it's a good idea to improve the cooling first. However, it might be feasible to _just_ overclock the low-power cluster --- if I can get all six cores running at 1.8GHz, that would be a very nice performance boost, and may not generate too much extra heat. I'll see how doable it is.

Thanks!
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Possible battery and performance improvement xehartnort 4 6,396 11-09-2020, 12:26 AM
Last Post: rimaille
  Manjaro w/ Panfrost Drivers vs stock Debian Video Performance decisivedove 15 19,494 03-25-2020, 12:04 AM
Last Post: decisivedove
  gvim performance in Debian sirspate 1 2,775 01-17-2020, 08:34 AM
Last Post: sirspate

Forum Jump:


Users browsing this thread: 1 Guest(s)