• Locked Locked
  • Replies 3 replies
  • Subscribers 119 subscribers
  • Views 2796 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Two SOCs speed comparison

Dmitry Golubovsky
Note: This was originally posted on 31st August 2011 at http://forums.arm.com

Hi,

I am new to ARM hardware, but trying to understand the speed difference between the two SOCs working at the same CPU frequency, yielding times different results.

Given these two devices:

1. OLPC XO 1.75, using Marvell Armada 610 SOC @ 800MHz, running Fedora Linux

2. Android tablet Pandigital Novel using Samsung S3C6410 @ 800 MHz., running Android 2.0

The same benchmark (Squeak Smalltalk tinyBenchmark [1]) was run on both, using the same Squeak VM interpreter code (well, maybe compiler versions and flags were slightly different, but this was GCC anyway).

Marvell yielded 45,000,000 bytecodes/sec; 1,600,000 sends/sec

while Samsung only 15,000,000/500,000 that is, three times slower.

See [2], [3] where this was discussed

Datasheet search shows that Samsung is ARMv6 [4], and Marvell is ARMv7 [5]

Is it the core version difference that results in such speed difference, or is that possibly the tablet firmware that throttles the CPU down?

I am the current developer of Squeak/Cog VM port to Android, and I collected information about the same benchmark that people ran on various Android devices [6].

It looks like another 800MHz device (Eken M009, VIA core) comes close to Pandigital, and all 1GHz devices show consistently higher speeds, yet this is below the OLPC results.

Thanks for any ideas.

-------------------------------------
[1] http://wiki.squeak.org/squeak/768
[2] http://lists.squeakf...ust/009262.html
[3] http://lists.squeakf...ust/009264.html
[4] http://pdadb.net/ind...samsung_s3c6410
[5] http://pdadb.net/ind...vell_armada_610
[6] http://code.google.c...i/TinyBenchmark
  • Note: This was originally posted on 1st September 2011 at http://forums.arm.com

    I'm not sure, but that could be due to the DDR3 of the OLPC !
    LPDRAM is not very fast on mobile.

    You should try a bench that only do some computation in a small amount of memory to see of the problem come's from the CPU.
  • Arm Employee Badge
    Note: This was originally posted on 1st September 2011 at http://forums.arm.com

    The important thing to know about ARM is that there is really no such thing as a "typical" ARM platform.

    The ARMv6 and ARMv7 part of the naming just describes the logical instruction set architecture exposed to applications by the processor. Each actual processor design can implement the logical instruction set however it chooses, so you may find one ARMv6 processor which is optimized for speed which runs faster than an ARMv7 optimized for power efficiency, or visa versa. In general new architectures add new instructions which can make software run faster (ARMv7 adds the NEON SIMD vector instructions, for example), so some performance gains for specific algorithms would be expected.

    Each processor design then takes the logical architecture and designs a "micro architecture" which is the design for the implementation of the RTL of the processor core. There are many possible microarchiecture choices which can be traded off to vary performance, power, silicon area.  Taking just a few of the cores designed by ARM for example the ARM11 processor (ARMv6) is a single issue core, so can only issue one instruction per clock cycle, the Cortex-A8 (ARMv7) can issue two, and in good circumstances the Cortex-A9 (ARMv7) can issue three. At the same clock frequency these cores will have totally different performance ...

    On top of this microarchitecture choice each physical chip design then takes the logical core of choice (from ARM or one of ARM's architecture licensees who can design their own), and configures the possible clock frequency, L1 and L2 cache sizes and speeds, memory bus widths, bus clock, memory latencies, etc. Each end platform design then takes the chip and bolts on some DDR memory, and different vendors may choose different priorities of speed / power / cost.

    As you have seen, just looking a the CPU MHz is a really poor indication of performance because it is a very multi-dimensional problem space. You are doing the right kind of thing already - look at benchmarks for the types of applications you want to run on the processor, and that should help select a SoC with the characteristics you are looking for.

    Cheers,
    Iso
  • Note: This was originally posted on 1st September 2011 at http://forums.arm.com

    The biggest factors here are that the Samsung SoC has a scalar CPU with no 16/16KB L1 cache and no L2 cache, while the Marvell CPU is super-scalar with 32/32KB L1 cache and 256KB L2 cache. If I had to guess, the L2 cache is the single biggest contributor. On OMAP3530 I've seen a huge difference in performance between L2 disabled and enabled.

    Also, are you sure the Samsung SoC is running at 800MHz? The features documentation lists it as being capable of 533 or 667MHz.

    Software environment could have an impact too, but if you say you compiled the Android port with GCC I'm guessing this is native C/C++ and not Java. If it were Java code the difference in VM would make a huge difference; I've seen current JVMs beat current Dalvik by a wide margin.