Rockchip RK3288 vs RK3368 Benchmarks Comparison

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.

RK3288_vs_RK3368To 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.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

24 Replies to “Rockchip RK3288 vs RK3368 Benchmarks Comparison”

  1. 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 😀

  2. 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.

  3. 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.

  4. @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.

  5. 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.

  6. @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.

  7. @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…)

  8. @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.

  9. @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.

  10. @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..

  11. @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 ).

  12. @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.

  13. @Nobody of Import
    One guys working for Linaro left some comments about the integer performance @

    The integer performance is, as noted, odd. One explanation might be that the compiler did a much better job on the 64-bit target, which with all its additional registers would not be a surprise, and if the test includes 64-bit arithmetic, it’s pretty much a given. If the test has a fairly large dataset, differences in cache configuration could also be a factor.

  14. @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.

  15. 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.

  16. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC