The test is derived from the STREAM benchmark which is widely used in testing memory bandwidth on servers and workstations.

The app is simple (and quick) to run. Just choose the number of threads, press "Run" and within about 10 seconds it will give you memory bandwidth estimate in MB/s. You can try running it with different number of threads. The UI gives you option to run it with 1, 2, 4 or 8 threads.

Results are unfortunately not very consistent from one run to next, but should give you a rough estimate of the memory bandwidth offered by your system. Post your results, or any feedback you may have, here.

On my Snapdragon S3 dual-core system, the achieved peak was 1.8GB/s. This was using 4 or 8 threads.

Last edited by codedivine on Thu Sep 27, 2012 10:11 pm, edited 3 times in total.

Thanks Neely Oh and Good News Everyone! I have pushed v1.1 to the market that adds an "auto mode". It will test all the configs for you and display the result of the one with the best copy bandwidth. I figured the easier it is to use, the better chance it will have to be adopted.

Of course, you still have the option of manually testing the threads and for that I have also added an option to test 5 threads.

It is strange that your results profile differs from mine given that mine is also S3 dual-core @ 1.5GHz. On 2 threads, I get almost the same performance as 1 thread. Hmm, maybe it has a different memory module?

Let's see, your Galaxy S2X would have the APQ8060 while my Galaxy Note has the MSM8660.

[edit]Huh, no they don't differ. Both are specified as Single-channel 333 MHz ISM/266 MHz LPDDR2. Perhaps it's the OS or memory chip after all. Which Android were you running? I'm on a JellyBean build (3.0 kernel).

In any case, on my Note, the memory bench consistently maxes out at 2 cores.

I am running stock 4.0.4 with TouchWiz. Hmm I will take a deeper look into the data being generated again. Wondering if my timer has a resolution issue. The times that we are measuring are in the 10-30ms ranges in this case. I do many iterations and calculate using an average but wondering if the timer is not accurate. The other thing to think about is how I do memory allocation in the benchmark and whether I can make that more repeatable. I probably cannot increase the problem size or the memory allocations will be so large that some phones might run out of memory.

Overall, I do expect this benchmark to show variations amongst runs, that's just the nature of it. But should work harder to reduce the variations.

1. I think this version should reduce variability a little bit. Lets see how that goes.2. I am also now reporting average time of the kernels in addition to bandwidth achieved. This is standard practice for STREAM related benchmarks.

Btw, to give you an idea of how the situation compares to desktops, I compiled a version of my benchmark as a command line app in Linux (same kernel code in C, just removed Android UI bits and replaced with C command line). I got about 9 GB/s peak on my Phenom II X4 desktop system which theoretically can provide 17 GB/s.

ChronoReverse wrote:Well the theoretical peak for the Scorpion is 2.7GB/s for a single channel so we're not getting even close to peak =)But we seem to be getting similar utilization rates.

Yes. You will not reach theoretical, even on desktops or servers. From the STREAM website: "The STREAM benchmark measures "real world" bandwidth sustainable from ordinary user programs -- not the theoretical "peak bandwidth" provided by most vendors."

STREAM is popular precisely because it sees through the vendor BS

Now, about the utilization we are seeing, I think we *might* be able to get better utilization if i tested larger problem sizes. Unfortunately, I cannot increase the problem size too much on a smartphone due to RAM restrictions, particularly if I want to be compatible with the many models out there. Hmm, maybe I will provide problem size as a setting to the user (in the future), so that at least the users with enough RAM can test larger problem sizes.

That is little odd. Another user reported about 2.2 GB/s on the Nexus 7. Anyway, I have published a new version (v1.2) which should be relatively more stable. Still waiting for it to appear in the market. Apparently it takes Google 3-4 hours to update app listings. I recommend using the Auto-mode.

derFunkenstein wrote:OK I totally must have been looking at something else when I said it was similar, because I do see 2.3GB in your post.

This is with the latest official build. Is the other using a custom ROM? I was also using AUto threads. 4 threads is not significantly different, and actually a little lower.

Actually I just checked it again, apparently the person just said "Tegra 3" and did not specify his device. I had somehow assumed it to be a Nexus 7.Possibly some other device. But either way, wait till tomorow morning perhaps. I expect the v1.2 to go live in the Play store (I have hit the publish button a while back) in a few hours.The new version should be relatively more stable. You can retest with it.

Looking over these numbers, I think Android itself is doing too much processing under the hood, and it's not letting you assign task/thread priority. That would be very important for a benchmark. SetCPU does not appear to be working correctly on Nexus 7.

Something odd I'm noticing: peak MB/s never exceeds the device clockspeed. Maybe there's some clock-limiting going on at around 1MB/MHz? That would explain the similarly equipped phone with the faster 2core CPU outscoring the tablet with quad.