Rockchip RK3368 TV boxes are now shipping, and I’ve just reviewed Beelink i68, so it’s a good time to compare the latest octa-core Cortex A53 processor with its predecessor, RK3288, featuring four ARM Cortex A17 cores, as well as a Mali-T764 GPU.
To compare both processors, I’ve used Antutu 5.x, Vellamo 3.x and 3DMark Ice Storm Extreme benchmarks results for Beelink i68 (RK3368) and Tronsmart Orion R28 (RK3288). The ratio divides the scores, and a ratio greater than 1 indicates RK3368 outperforms RK3288.
| Rockchip RK3288 | Rockchip RK3368 | Ratio | |
| CPU | Quad core Cortex A17 @ 1.8 GHz |
Octa core Cortex A53 @ 1.2GHz |
|
| GPU | ARM Mali-T764 | PowerVR G6110 | |
| Antutu 5.x | |||
| Overall | 36865 | 34171 | 0.93 |
| Multitask | 5753 | 4041 | 0.70 |
| Runtime | 1976 | 2949 | 1.49 |
| RAM Ops | 2475 | 2346 | 0.95 |
| RAM Speed | 3153 | 2601 | 0.82 |
| CPU Integer (multi-thread) | 2433 | 2973 | 1.22 |
| CPU float-point (multi-thread) | 3565 | 2930 | 0.82 |
| CPU Integer (single thread) | 1432 | 1536 | 1.07 |
| CPU float-point (single thread) | 1893 | 1492 | 0.79 |
| 2D Graphics(1920×1080) | 1443 | 1617 | 1.12 |
| 3DGraphics (1920×1080) | 11071 | 10115 | 0.91 |
| Vellamo 3.x | |||
| Metal | 1294 | 773 | 0.60 |
| Multicore | 2002 | 1288 | 0.64 |
| Browser | 2539 | 1796 | 0.71 |
| 3DMark – Ice Storm Extreme | 7513 | 4248 | 0.57 |
RK3288 has better performance in most tests, with a notable exception being the runtime benchmark where RK3368 is about 50% faster than RK3288. The explanation might be that Beelink i68 runs Android 5.1 with ART, while Orion R28 ran Android 4.4 with Dalvik. The integer performance is however confusing as in theory a single core Cortex A53 core @ 1.2 GHz is supposed to achieve 2760 DMIPS (2.3 DMIPS/MHz), while a single core Cortex A17 core @ 1.8 GHz should deliver a much high value between 5400 to 7200 DMIPS depending on where you look on the net, while Antutu results show RK3368 is faster than RK3288 for integer performance both for multi-thread (not surprising 8 cores vs 4 cores), and single thread. So I wonder if Antutu results may have been tweaked on RK3368 a little bit, especially considering Vellamo results show 30 to 40% less performance. Graphics performance in Antutu is about the same for both processors, but in 3DMark the graphics score is much better for RK3288.
Even though I don’t feel I can fully trust Antutu benchmarks, results show that RK3368 is roughly equivalent to RK3288 at best, but in many cases it should perform slower. It might be interesting to run the benchmarks again in RK3288, once a stable Android 5.1 firmware is released.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I think the only way to get results you can trust with these is put Ubuntu or some other Linux distro on them and run the phoronix test suite… I’m sure that they’re not rigged to cheat on that 😀
While my 3288 box(UT3) scores about 38000+ on 4.4, it returns a verified score of 45300+ on a 5.1 Alpha. That certainly sets it further apart from the 3368. But of course, benches only tell part of the story. Based on intitial impressions, I think 5.1 is going to be very good for the RK3288. But only time will tell.
Thanks for the article.
Regards.
BTW I read that the 3368 boxes thus far, are running 32 bit F/W. If so, maybe future optimization will yield higher results with the 3368.
I’d like to know how many of its cores are running and at what load, when Kodi is playing UHD video.
@R.D.
It depends. When using hardware video decoding, I think only one or two cores are used, but when using software decode, all eight cores are pretty much maxed out at 100%. This happens for H.265 and VP9 in Kodi 14.2.
Why compare the two when they are different beasts?
The RK3368 is not intended to be a replacement for the RK3288.
It was originally muted to be for the Chinese lower cost market.
Real world usage is far more important anyway that a bunch of simulation tests that only give you a part of the story.
As for Antutu, I’m amazed at how much people judge a product based upon the score.
@PhilS
Benches are like MPG estimates on new car stickers, they are a relative indicator at best. Real-world performance is always more accurate than simulation, in determining an apperatus’ suitability for a certain task.
@PhilS
> “The RK3368 is not intended to be a replacement for the RK3288. It was originally muted to be for the Chinese lower cost market.”
What is the benefit of having a 64-bits CPU for low-end devices with less than 3 GBytes of RAM and without any way to extend it ? (I see only downsides, e.g. more cache-miss because pointers are 2x larger, etc…)
RK3368 is supposed to support 1.5 GHz clock. Why were these tests run with a 1.2 GHz clock?
@Curmudgeon
According to Geekbuying, the RK3368 in Tronsmart Orion R68 Meta is clocked up to 1.6 GHz.
@Curmudgeon
I’ve also seen specs on other website clearly stated the CPU is clocked at 1.5 or 1.6 GHz, but the firmware on Beelink i68 only runs up to 1.2 GHz according to CPU-Z and Antutu.
It’s not the first time this happens though.
@cnxsoft
it will be good if you take a more professional approach to your tests, and texts…
J.
@JotaMG
What ‘s the problem with the tests? All benchmarks have the same major versions, and I’ve explained RK3368 runs Android 5.1, while RK3288 runs Android 4.4.
@cnxsoft
I too think a test like this must be done with the same version of operating-system on both boxes. And it would also be better to compare two boxes which are both clocked at the recommended maximum Mhz from the SoC manufacturer.
You need to compare Granny Smith Apples with Granny Smith Apples, not Granny Smith Apples with Golden Delishious Apples for it to be a fair comparision.
@Harley
And where is Android 5.1 firmware for RK3288? There’s none except Ugoos beta version.
So if today, somebody pressed the buy button somewhere, they’ll get an Android 5.1 RK3368 box, or an Android 4.4 RK3288 box. I’ve explained the differences between Android 4.4 and Android 5.x in the test, and people should read this as a caveat. If people just read the table, and don’t read the associated text, that’s not my problem…
AFAIK, the datasheet or TRM for RK3368 has not been released, so I find it funny that people read some CPU frequency on retail websites and it becomes the SoC manufacturer’s rated frequency, while I’m testing an actual device with firmware set to 1.2 GHz, and not some clocked-to-fantasy frequency.
By the way, I’m still waiting for my Allwinner A10 @ 1.5 GHz, Rockchip Rk3188 @ 1.8 GHz. and so on..
@cnxsoft
If could install any version of Linux on them , maybe even Android somehow ( with chroot ? ) that would make for an interesting test ( even if graphics probably won’t work ).
@Marius Cirsta
That’s kind of my take on this. Having said this, it should be a push. The architectures are differing- just because you’ve got 64-bits…doesn’t mean you’re faster. For single-thread stuff, the RK3288 should mop up the floor with the 3368 because it’s using the LITTLE version of the 64-bit core (shallower pipeline) coupled with a lower clock speed. For multithread stuff, if you’re using 4 or less threads, it should be pasting the RK3368 because it’s got four threads with the deeper pipelines. Up past that, the extra four cores should even it out to being almost faster everywhere if not a slight edge because of the 8 cores being available. What CNX is reporting is…slightly at odds with my understanding of how this should’ve rattled out.
@Nobody of Import
One guys working for Linaro left some comments about the integer performance @ https://plus.google.com/u/0/+OlofJohansson/posts/F17fz5iDA9L
@ade
The size of pointers doesn’t play a big part of possible (instruction) cache miss. most of pointer are relatives one in asm code. You could have at max an absolute pointer by object. The most important is the size of the instructions themselves.
In this field ARM does a good job on ARMv7 32 bits architecture with the thumb mode, where instruction can be 16 or 32 bits wide. i’m not sure it was really used. In the case of the ARMv8 64 bit architecture, there is two modes, a mode where values are 32bits wide and a mode where valures a 64 bits wide (see ARMv8 Instruction Set Overview, p10, 3.1 Distinguishing 32-bit and 64-bit Instructions), so the cash miss should be about the same. You can use 32 bits (4GB wide) indexes in most of cases and in few cases 64 bits adressing.
The main advantage of Cortex-A53 here is on the energy side. They are the evolution of Cortex-A7 (lower consumption part), they have about the same (10~40% less computing power depending on cases after this test) at the most computing situation, in 95% of the case, they will use far less energy, typically, that’s what you want with a phone.
There is no more Jazelle hardware bytecode decoder) in Cortex-A53, so metal can be used for more usefull things (good news), and as recent version of Android (that is the most java oriented OS) are more native code oriented, now, probably nobody will care. Perhaps This module could be usefull for Vulkan/SPIR-V, but I’m not sure that jazelle was able to manage LLVM bytecode at all.
Time to re-run these tests with Android 5.1 ROM from Neomode in freaktabs. That will be a better comparison where the OS is almost the same.
Run the Cpu-z CPU ID app on your device and check to see if you actually have an RK3066 Cpu instead of the RK3368 your device is supposed to have.
@Robert
CPU-Z does not know about RK3368, so it will always show RK3066. The app actually wrongly reports most recent SoCs used in TV boxes.