I am trying to estimate speed differences when creating code on my desktop PC that will be ported to Android phones. I don't need to be exact, but a good estimation will help stop me from creating code that is dismally slow on an Android phone. I want to support down to the Android G1 so I am using it as my "baseline".

Here is how I am currently performing my calculations using Dhrystone MIPS using an old Pentium 4 for comparison that will be the test unit for quick speed tests. According to this document, a G1 using a Qualcomm MSM72xx ARM CPU is about 1 MIPS per Mhz:


Web searches turned up user comments indicating that the G1's CPU comes stock running at around 350 Mhz and not at the 523 Mhz shown in the chip's specs so I am assigning a MIPS rating of 350 MIPS for the G1, rightly or wrongly.

This Wikipedia page shows the Pentium 4 Extreme edition rated at about 9700 MIPS:


This makes the Pentium 4 approximately 27 times faster than the G1. Given that multiplier, if during one of the time consuming operations my code takes 1 second on the Pentium 4, I would estimate that it would take 27 seconds on a G1.

Is my logic correct? I am hoping it is not because that means I'll have to do some really painful optimizations to the code to make things livable on the G1. If my logic is not correct and there is a better algorithm for this calculation, please let me know.

-- roschler

  • What sort of stuff does your program do? If your program does a lot of integer crunching similar to the benchmark then this is a rough measure of the performance difference you'll see... Anyways, tell us more. – Guy Sirton Jul 13 '11 at 3:26
  • Sounds a lot like premature optimization to me..... – mattnz Jul 13 '11 at 3:40
  • @Guy Sirton - Heavy duty text processing. Lots and lots of string comparisons. – Robert Oschler Jul 13 '11 at 3:57
  • 4
    @mattnz: See my edit below. With embedded systems, there's no such thing as "premature" optimization. – Bob Murphy Jul 13 '11 at 4:08
  • This is almost a year late and probably obvious, but anyway, if you are doing heavy duty text processing, you really should check your algorithms first - use KMP, Aho-Corasick, etc. Also, if you use a hash function, try assessing its properties - it may be slowing down your app. – K.Steff May 18 '12 at 17:09

Yes, your P4 desktop will be hugely faster than a cell phone.

I used to work on a cell phone OS. This was a few years ago, and we were using XScale and OMAP ARM CPUs, and we also had a desktop simulator that ran the same code compiled for x86. I never measured it, but 27x is certainly plausible.

There are a ton of factors involved other than raw CPU clock speed, mostly hardware related. Peripherals, memory, and bus speed and architecture are biggies. Another is how the CPU silicon is constructed; ARM CPUs are typically simpler, and don't have performance-enhancing features found in x86 chips that boost the power requirements and chip die size.

Ultimately, you need to do measurements. And yes, this kind of embedded work often involves "painful optimizations to the code to make things livable" for end users. That's a big reason experienced ARM developers are in huge demand around Silicon Valley right now - if you already have those specialized optimization skills, a lot of folks need that.

I'm going to add a remark about "premature optimization" of smartphone code.

When you're doing any kind of embedded systems work, you need to write your code with optimization in the back of your mind. It's not that all the code you write has to be optimized out of the box, but you need to have a good idea where you're likely to have problems, and not paint yourself into a corner design-wise.

You typically build embedded executables on a desktop and transfer them to the device, so your build/test cycle is at least an order of magnitude greater than on a desktop - seeing the results of the smallest code change can take minutes. Also, the code profiling tools on embedded devices really suck if they even exist.

So you just don't want to leave performance tuning until last on embedded devices. If you do, and you have a deadline, you're in for a lot of all-nighters, and maybe complete project failure. On embedded devices, performance testing is like unit testing: it needs to pass the first time, and you have to keep testing it so performance doesn't regress.

|improve this answer|||||
  • Murhphy - Thanks. The only problem is, to get that kind of "premium" optimization would involve using the Android native SDK (C++) and I believe using that SDK means your code takes a big compatibility hit across individual phone models. Well, at least I know what I'm up against. No wonder the Android game developers are salivating at the thought of GPU help. It would be interesting to see how the smart phone GPUs measure up to their big brothers but that's a whole other topic. – Robert Oschler Jul 13 '11 at 3:56
  • @Robert Oschler: What I said generally applies to Java-based executables, too. But if you have some really compute-intensive things going on, perhaps you can call into native code from Java. I used to do that with JNI back when I did more Java work, and if you limit what you do in native code to no or limited API calls, you may not run into compatibility problems. But you're right, game developers in particular need every ounce of performance they can get, and it's always limited on cell phones. – Bob Murphy Jul 13 '11 at 4:18
  • Thanks for the tips. I'm hoping that the Android JVM is well optimized for string functions but if not, I will be looking at JNI and the native SDK. – Robert Oschler Jul 13 '11 at 4:34

There's a lot more to performance than raw CPU number-crunching power, even on CPU-bound algorithms. The efficiency of the compiler (and the JVM implementation if you're working with Java, which you are likely to be doing on an Android phone,) the amount of memory available and the size of the bus, the size of the processor's caches, etc all factor into it.

If you really want to know how fast code will perform, try testing it with actual code. Write up a time-consuming algorithm (bubble sort on a large data set works well) and compile the exact same code on both platforms, then test the run time. For a more complete picture, try several different algorithms that will exercise different sets of functionality.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.