Running mobihf on the iPhone

mobihf (https://sites.google.com/site/tovganesh/s60) is a code that I wrote almost a decade ago on my first phone: the Nokia 6600. mobihf was meant to be an educational tool on how to write a basic Hartree-Fock Quantum Chemistry code from scratch, and to me it was a way to experiment on how much can I push the mobile device to do scientific number crunching. At that time the processing power of my mobile was just about 100MHz with just about 10MB of RAM! And now I have this two year old iPhone 5s that has a 1.3GHz 64 bit processor, with about 1GB of RAM.

To test out how things have panned out for my purely Python mobihf (not the C++ integral code that I wrote later), I tried a number of Python interpreters available on the Apple App store.  While Python for iOS (https://itunes.apple.com/us/app/python-2.7-for-ios/id485729872?mt=8) seemed like a good choice, its editor was never able to even load the mobihf script to do anything meaningful. A mail to the developer did not get me any response (as of this writing).

Next up was pythoni (https://itunes.apple.com/in/app/pythoni-run-code-autocomplete/id493505744?mt=8). This is surprisingly well written app with custom keyboard shortcuts and well made editor for editing Python scripts. It is worth buying the pro features in this app if you do a lot of Python programming on the move. So, finally I was able to run the pure Python mobihf code (available from GitHub: https://github.com/tovganesh/myrepo/blob/master/mobihf.py). This code is heavy on numeric computations (evaluations of exponential functions, matrix and vector algebra etc.). Without going into the details of what the code does, I typically run two test cases to see how things are going. These are for two very simple molecules: H2 (hydrogen molecule) and H2O (water molecule) at a basis level called STO-3G. All very basic to the one who knows Quantum Chemistry, and pretty much a jargon to the rest ;-) Since I am using iOS9, I decided to run the job in two modes: once with battery saver on and another without.

As can be observed above, even with battery saver on, there is 50 to 65 times improvements in the timings over the same pure Python. And, to top it the timings also handsomely beat the C++ compiled code on the old phone.

With the battery saver turned off, the performance improves as expected. What is surprising however is that in comparison to when the battery saver is on, the performance improvement is about 60%. That is quite a hit to keep the phone going for longer. I wish we have some radical improvements in the battery technology so that we can keep enjoying our devices at full speed.

The next app was Sketch Python (https://itunes.apple.com/in/app/sketch-python/id984990674?mt=8). There are a number of different Python implementations and each can give you a different performance numbers. So far I have found Sketch Python to be the fastest.

With the battery saver on, Sketch Python performs almost as fast as pythoni with battery saver off. That says a lot about the performance of Sketch Python interpreter, especially in handling Python code with heavy numeric computation.

The performance of Sketch Python to run mobihf increases substantially when battery saver is off, and is probably the best timing that I can get on the A7 processor of iPhone 5s. If you do the math, this is 140-166 times faster than the pure Python code that ran on my Nokia 6600 a decade ago. In comparison to the C++ (native code) running on Nokia 6600, the gains are an order of magnitude times less, but still impressive. I am sure if I port this code over to native, we can do pretty complicated Quantum chemical calculations on the phone. The newer A9 processor in iPhone 6s or the Qualcomm processors (8-core 810 or higher), would be interesting processors to see the current state. But I can say that these mobile processors have reached the performance levels of the most desktop processors for all practical purposes. And this is exactly that I had in mind when I took a look at the ability to run scientific codes on mobile processors (https://sites.google.com/site/tovganesh/s60).

On a different note, the ARM architecture also makes an interesting case for computational codes because of the low power requirement, a topic I briefly touched, but now studied much deeper by Kristopher et.al. (http://pubs.acs.org/doi/abs/10.1021/acs.jctc.5b00713). Alistair Rendell, my postdoc guide, is a co-author in this paper, so it must be real good :)

Note: The experiments above were run 5 times, and the lowest time was taken.

PS: This post has been since mentioned on MacInChem.org (http://www.macinchem.org/blog/files/0c7f90a37910d2ed90402dcddb6cf4e2-1814.php)