This video has a comparison of several boards of interest to me, and a surprising result. It isn’t a direct hardware comparison, as the boards are running different OS versions; but as the author points out, these are the OS releases most available and most likely to be used on each board.
He compares the Tinker Board, Rasperry Pi 3 B+, R. Pi Zero W, Rock64, RockPro64, and the Odroid XU4. While I’m not interested in the Tinker Board (another reviewer called it “broken by design” as there is a huge volts drop over the micro-usb power spigot when you attach anything to the board…); I do have both a Pi M3, and Odroid XU4, plus I’m looking at the Arm A53 / A72 type Hexa Core and similar boards as the best alternative to the Odroid. So I’ve lusted after the RockPro64. (Which is why I was looking).
From comments on the video:
Published on Sep 9, 2018
Odroid-XU4, Rock64, RockPro64, Tinker Board S, Raspberry Pi 3 B+ and Raspberry Pi Zero W ARM SBC group test. Video includes specification comparison tables, boot test, Sysbench CPU test, and GIMP complex filter test.
The test image used in the GIMP test can be downloaded here: https : //www .explainingcomputers.com/i…
It is surprising how well the Rock64 boards do in his benchmarks. I need to learn more about the RockChip offerings. They have several. Some are used in the Libre Boards, and there’s an Orange Pi using another chip.
Lists some various uses / chips. It will take a bit to figure out which of these is a what and their comparative speeds.
The point out the Pine64 is similar / the same as the Rock64 ( I think they are made by the same company). Using the RK3328. (quad core A53 – 64 bit data path! I think at 1.6 GHz)
The RockPro64 uses an RK3399 (Hexa core that has A72 & A53 in 6 (2+4) config. ) I don’t know the GHz. In general it does look like the overhead of swapping core types slows things down more than desirable…
The Tinker Board uses an RK3228 (quad core A17 32 bit 1.8 GHz. )
Firefly-Rk3288 (no surprise) uses the RK3288 (quad core A17 32 bit 1.8 GHz. )
Libre Board ROC-RK3328-CC uses the RK3328 (quad core A53 1.5 GHz – 64 bit data path!)
Orange Pi RK3399 uses the RK3399 (that has A72 & A53 in 6 (2+4) config. )
Radxa Rock uses the RK3188 (quad core A9 1.6 GHz.)
With each core type ( A9 A17 A53 A72) of different word lengths, data path width, and “computes per GHz”, figuring out the Bang / Buck on those guys is a bit complicated. While benchmarks work best, it can be pricey to buy them all to find out ;-) So some theoretical comparison will need doing instead. The compariative performance of the Cores is generally known, so that can be computed, then it’s down to what the memory and connections on the board lets it do. I think I’ll leave that for tomorrow ;-) Along with finding prices ;-)
Just as an FYI, the Odroid XU4 has a 4 + 4 with 4 of the cores slower A7 and 4 the faster A15 cores – but all 32 bit v7 instruction set and 32 bit data path. In my watching the boards CPU monitor, it rarely uses the A7 cores when there’s any real work to do; so anything of about the same performance as 4 x A15 @ 1.8 GHz ought to match it most of the time but without the cost and complexity of an octo-core board. But to compare a A15 to an A17 or A53 means “some math required”… then there’s that issue of the data path width and memory performance… (why folks benchmark…)
But: The big takeaway for me was that the Rock64 was surprisingly high performance, though just why was a bit unclear. In theory the RockPro64 has a lot more “juice” with much more silicon available, but something is holding it back. Scheduler not up to the task maybe? Ore overhead of swapping CPU types eating up too much performance? Or is it that Ubuntu is a resource hog in comparison to Debian? Who knows… It could just be that the OS was compiled with NEON float (uses the GPU as a math processor).
So I guess this posting mostly amounts to a big “I’ll be digging here!” on those chips and GHz and who’s a what for how many $$…
The Pi M3 is almost fast enough for a daily driver, but between needing to fiddle the clock to get it to run full speed, the “usual” heat sinks being too small, and the communications paths on board being limiting; well, it is just slow enough to be annoying after an hour or two.
The XU4 is a wonderful experience. The speed is a joy and I’m happy with it. Except software is a bit of a PITA. Not a lot of folks doing ports for it, and those that are done often put it last or late on the list of QA – so often some bits are not tested or working right out of the box… Then it substantially never uses all 8 cores as they are in a “Big/little” arrangement and mostly you just use the fast 4 or are not doing enough to matter what core is being used.
So I’m thinking something with 4 faster cores and better data path design would likely be A Fine Desktop. That’s the idea anyway. 4 cores at about 1.8 GHz ought to do it (A53 or better). It’s not a big itch to scratch, just a minor annoyance. Then again, with boards costing less than 1 tank of gas (and sometimes 1/2 tank…) it’s not an expensive itch to scratch either…
Given that the OS types were not characterized as to how math was set up (software float, hardware float – coprocessor, hardware float GPU / vector) that alone is a great big open issue that could account for the Rock64 beating the RockPro64. It is one of the reasons I’m thinking I need to “roll my own” OS. So I can set the math type. It can be a BIG win. Using NEON can give order of magnitude speed ups on some problems, at the cost of a small precision loss that drops you from I.E.E.E. compliance. Unimportant to things like graphics and general use; but sometimes not acceptable for Engineering Design work or hard core Science where using double precision is common and every bit matters.
Many Linux distributions, especially early ones or for unusual boards, will just set soft float since it always works and then they don’t need to deal with just which math coprocessor is in use or how to program for it. A rude thing to do, but it is done. Let’s you ship on time by skipping work that most folks will not know was skipped. Also the same software can run on more hardware types then.
So finding a straight hardware comparison benchmark with the same software is likely to be in order.
I’ve looked into a “roll your own” OS before, enough to see how to set the flags for soft vs hard vs NEON floating point math. (Or a different vector math – not all video cores use NEON and I’m not yet familiar with which GPU cores are NEON vs other instructions).
It is one of THE big things worth playing with, to convert the General Purpose releases that are usually Soft Float into Performance releases fitted to your particular hardware.
IF I had to bet, I’d bet that the Debian release on the Rock64 was compiled with some kind of hard float, and the Raspberry Pi was done with soft float. Very few folks use NEON as it means sometimes your video cores are not fully available for drawing pretty pictures and doing movies… it’s mostly a hard core science geek thing to use it; and even then you must know what precision is needed for your work and is the math coprocessor the better choice.
So I’d say that computing primes benefits from 64 bit math, and that most of the loss of speed in the Pi and Odroid are from the 32 bit OS on the Pi and the hardware 32 bit on the Odroid; perhaps also levered a bit by hardware 64 bit math vs software math. But it would need testing to know; and it might be compiler flags in the build.
So there you have it. A “hot board” but with the question of “Is it the board, or the OS build?” Then there’s just a lot of leg work to compare chips, speeds, bucks, and builds.
Even with that, though, the Rockchip boards are looking good.