FAH on mobile devices [Android 4.4+ Only for now]

[AakashPatel]

Hello, I was just thinking and randomly had this idea.

Current day mobile phones' have CPU clock speeds reaching 1GHz like the Nexus One or HD2 and even faster speeds are immanent.

I was thinking if it would be logical to have an app similar to FAH on desktops but on higher end mobile phones. Android currently even has an NDK for coding in C/C++. The application could sit in the background inactive while the phone is being used and on battery power, and when the phone is on the charger and inactive the application starts to do computations, so not to affect the user, like when charging overnight.

I would personally love to start developing this myself, but thought I would get some insight on the subject before diving in.

Cheers,
Aakash Patel

(Sorry for any typos, I typed this on my phone in bed at 1am )

[bruce]

FAH is not suitable for mobile devices. When FAH runs on a computer, it typically uses 100% of the processing time for many hours at at time. For laptop computers, this depletes the batteries very quickly and FAH has a feature that allows it to disable itself when running on batteries. Unlike mobile devices, many laptops spend many hours per day plugged in.

Also, mobile devices generally do not support the floating point operations that FAH needs, so 1GHz is a meaningless number.

[hj47]

We really need a sticky about FAH's [non]application on mobile/embedded devices.

Too many of these threads keep popping up

[AakashPatel]

I see, well sorry for any repost. Seemed like an OK idea at 1am last night

[bruce]

We really need a sticky about FAH's [non]application on mobile/embedded devices.

I'll set this as a sticky, but I wouldn't call "mobile/embedded devices" but rather a combination of several issues. First, it's all battery powered devices. Second, it's the actual limitation of the computer chip in the device. Third, it's the real cost associated with developing a FAH application for a different platform compared to the actual quantity and speed of the results that the platform would produce.

[hj47]

I'll set this as a sticky

Thank you!

First, it's all battery powered devices.

Not quite, we've had a few requests in regards to routers and printers

[MESeidel]

Android currently even has an NDK for coding in C/C++.

Like others mentioned the Chip in a Cel Phone is differnt (somewhat limited).
To be more precise it is a complete different architecture.
Those CPUs are ARM based and can not run x86 Code that is used in PCs.

ARM is very energy saving but is very simple.
X86 (with additions like SSE or AMD64) is complex.
To use it's full potential special command sets like those of different SSE versions need to be used optimal.

When you write software (in C/C++ or whatever language) a compiler than translates this Software to run on the target platform.
The compiler also tries to take best use of the chips command set (again: SSE).
An x86 compiler will most certainly generate different versions with SSE (version x) and without (or lower version) integration.
This is needed to run the Software on older non SSE CPUs (in theory back to intel 486 systems).
But it will not compile the software to run on ARM or any other architecture.
Think Apple: they switched to intel based CPUs and now you can't run MAC OS 9 on a intel based Mac.
You also can not install old Software (for OS 9 and older) because it is compiled to run on the old architecture.

Now your question could be why the same code can't be compiled to ARM.
That is because a modern application uses many external ressources.
For example when you code a media player software.
You "only" do the core logic.
You don't care about file system works (open file, browse folders, save file, ...) or the output to the speakers or the generation of the window (buttons, list boxes, menu bar, actual all graphical elements), ....
Because someone did that already and you can use the compiled classes of those people.
And that is the problem: Those classes are compiled and only available on your base system.
If you copy over a Windows application to Windows Mobile device it will crash right after start because the resources it needs aren't there.
Similar problem have modern apps on Windows 2000, they will stop (with function xxx in dll yyy is missing), because the needed resources aren't supplied anymore.

It would be possible to create a F@H client for ARM based Mobile Phones, no question.
But that would mean everything had to be done from scratch for this platform alone!
Like a new client line besides CPU/SMP, MAC, GPU and PS3 (I forgot more?).
The potential user base AND the potential performance is to small to invest much resources therefore...

[Sidicas]

This reminds me of the old "Can you make folding@home run on my wii?" threads...

The performance simply isn't there...

These ARM chips as stated above take simplified instruction sets... But they're also very advanced when it comes to power management where their power usage scales almost perfectly with the amount of work they're doing (much better than Intel, AMD, nvidia, ATI chips that use staggered power management)..

Regardless, If you ran your ARM chip at 100% usage constantly, your battery would be dead in no time.. Even at 100% usage, due to the simplified instruction sets, it's not really doing much.. The chip specs might sound fast, but compared to the massive x86 instruction sets, it's like baby language that takes 4x as much instructions to do the same kind of operations.

Add to it the fact that the overwhelming majority of phones on the market have just barely enough horsepower in them to take calls while running ONE tiny simple application.. Folding@home on these mobile devices is just not going to happen..

What you should consider is perhaps some of the Atom netbooks that are out there that run x86 instruction sets.. You can run the regular single-CPU console client on those, no problem... But even still, you probably should only run it when you're plugged into the wall or you can kiss your 4 hours of battery life goodbye.

Really, these ARM chips were designed from the ground up for one thing, and that is power efficiency.. You start running your ARM chip at 100% usage all the time, and you throw away the whole point of running an ARM chip in your device.. You might as well be running an Intel Atom or something similar.. These devices have ARM chips in them for the simple reason that they will spend most of their time at <1% usage, waiting for a phone call to come in... It's really the wrong kind of chip design for running something like folding@home in many ways..

The ARM chips have Pros and Cons... By running folding@home on an ARM chip, you're killing off all the Pros (high power efficiency at reduced utilization) and are still stuck with all the Cons (simplified instruction sets, low overall performance, etc).. I highly doubt your phone would still be usable as a phone if you had folding@home running on it.. You'd likely be recharging it every few hours and have to stop your folding whenever you make/receive calls simply because the phone also doesn't have enough RAM for it all..

[bruce]

What you should consider is perhaps some of the Atom netbooks that are out there that run x86 instruction sets.. You can run the regular single-CPU console client on those, no problem... But even still, you probably should only run it when you're plugged into the wall or you can kiss your 4 hours of battery life goodbye.

Depending on which Atom chip you have and which battery you have, you'll get different results. My experience is that it's a not-too-powerful performer on the classic client but I also expected poor battery life and it lasted longer than I expected. Consider that a not-too-powerful performer is still better than zero and I can still surf at the internet cafe or compose documents on an airplane, which is why I got the netbook in the first place.

[theteofscuba]

it isn't battery efficient but if you want to leave your cell phone folding over night while its on the charger, I see no problem. minimal resources would demand minimal work units, though.

[bruce]

If the Pande Group decided to port FAH to other devices, it wouldn't be mobile devices. The computer chip in them is designed to do specific tasks on very limited power. There is no reason why it would even have the ability to perform floating point operations which are the bulk of what FAH needs.

Assuming they decided to make the investment in the port to a new platform, and assuming such a port was successful, you might expect 5 PPD so overnight you might get 2 points. Certainly it's not a wise use of any scientific project. A phone is simply the wrong tool for the job.

[divery4eyes]

/sarcasm

Ahh come on people, you mean to tell me that all these Ipods and Ipads out there cant fold???
Just imagine the increase in foldage if there was a client.

/end sarcasm

[Radek]

Don't dismiss ARM too quickly. ARM instructions set has its pluses. What counts the most is architecture implementation thought. So far ARM CPUs were focused on low power, low performance devices. But it's changing and ARM is going up scale too. There are quadcore@2.5GHz Cortex A15 and nVidia own "Denver project" in works. Both supposed to compete in desktop and server space. If Atoms can finish workunits on time then those newer ARMs should do (possibly way) better.

[theteofscuba]

also, you may have heard that Microsoft Windows 8 will be supported on ARM.

[7im]

I think mobile folding was dismissed at the appropriate speed. The power (processing wise) and the power (battery life) is not conducive to folding.

If at some time in the future this changes, they will certainly revisit this option. Until then, consider it a no go, and a dead topic.