Folding Forum

Oh, I'm not really concerned about the mobile aspect as much as I was about supporting ARM in general. Well, I guess we'll have to wait and see if ARM will really make a dent in the market, and then get Pande group to think about it again when that time comes.

Two points:

Continuous computing at 100% performance is murder on battery life. FAH can presently run on an x86 laptop but because battery life is often a severe limitation, there's an option to shut FAH down when running on batteries. My laptop spends 99% of it's time plugged in, so that's not a problem. Suppose the Pande Group makes the "stop FAH when on batteries" a mandatory setting. Just how many ARM devices would you expect would be running plugged in on an average day? Or, putting it another way, how would you feel if FAH ran your batteries down in an hour and you couldn't use your hardware?

What kind of Floating Point speed do the ARM devices you're considering have? (Not measured in MHZ or in MIPS but in GFLOPS) Fundamentally, ARM is a RISC architecture and Floating Point, especially Vector Floating Point, would typically be handled by a coprocessor. Limiting FAH to devices with coprocessor hardware would probably exclude most (or all) mobile devices.

The point is that ARM may be making its way into the Desktop market. nvidia has expressed an interest in producing its own ARM-based cpu, which they are working with Microsoft on. I think its safe to say that nvidia has all the right tools to do this. They got the gpu, the chipset and now the cpu. is there anything I'm missing?

The only thing you're missing is that the topic is specifically about mobile devices, not about whether ARM might migrate to the desktop. Please stay on topic.

It doesn't matter either way. Like GW said, you don't need much of any FPU performance to run Windows, so ARM probably works well for that task. But you need serious FPU stones to do anything good with FAH. ARM doesn't have the FPU power to do it. ARM does MFlop FPU performance, while CPUs do GFlop level performance. And GPUs do calculations at the TFlop level. You do the math.

Like I said, ARM is a non-starter for fah until it gets 1000x better FPU performance. Sorry.

gwildperson wrote:how would you feel if FAH ran your batteries down in an hour and you couldn't use your hardware?

I would cry a river to pande group over something I opted in to knowing full well what I'm doing. there are ways to program an app to limit itself around battery level.


putting the time into a select few mobile devices might not be worth the time because its arguably not as good at returning a good quantity of scientific data compared to the peformance they can get by focusing on other platforms instead. I don't see battery life as the reason for not supporting mobile. The problem with current mobile hardware is that mobile devices are limited in power consumption because of the heat problem with silicon chips. something like ARM will have to learn to process more data per power usage. leaving your mobile device plugged in to the wall when you sleep should make it clear that battery life isn't the real issue.

basically, its cost-Benefit decision of PG's time and effort. PG knows well that if they had the money they can go and buy up support for every computing device out there and though its not as plentiful in results as other hardware, its still science and the science is the best reason to support the mobile devices, and is a noble suggestion. PG has demonstrated that time and effort is the major issue already when they announced they will be dropping the PowerPC client for older macs. They have already stated that they do not have the resources to support so many different hardware with significantly low returns.

maybe in the future when they have nothing better to do.

No amount of cost could make a turtle run any faster. And no amount of limitless battery power would make ARM run FAH any faster. It just doesn't have the FPU performance to do it. There's no use debating any other parts of this discussion until ARM has better FPU power. And that ends the discussion, again.

It appears most people here missed the initial mention of NOT folding while on battery, therefore focusing on the other aspects that prevent a mobile device FAH client from being feasible.

I find this most interesting but wouldn't bother -- the output from folding on mobile devices in mass wouldn't amount to much -- compared to focusing on the further optimization of current clients.

Welcome to FAH, Phantom2487.

(It's nice to have people on the forum who read before posting.!)

Two aspects are important. As you said, the most important is that the FAH depletes all batteries very quickly. The secondary issue is that supporting a new client is an expensive proposition and is extremely unlikely, no matter what that platform is. Everything else is a question about which unsupported platform is better than some other unsupported platform, and it really doesn't matter, because the answer is No.

Copied and pasted from a near-identical thread exactly 1 year ago.

iPad is powered by an Apple custom CPU called A4. It has graphics, and memory controller onboard. It's a 1 GHz chip with 4 cores that are basically ARM Cortex A9. Figure 2.5 MIPS, and 1.5 MFLOPS per core. That's max theoretical performance, so 50-80% of that real-world. Around 7 MIPS and 3.5 MFLOPS would be a reasonable expectation.

As a comparison, a Core i7 920 benches at 81,100 MIPS and 69,180 FLOPS.

You could reasonably expect, with your iPad plugged in 24x7 to get 5-15 PPD.


viewtopic.php?f=6&t=13265

I just found this article about SETI@Home going on Mobile devices.

http://news.cnet.com/8301-27080_3-20041365-245.html

According to the article SETI is not doing number crunching on mobile devices, instead users scroll through images of radio signals and click if they think they see a pattern in the noise.
This is using mobile devices to what they are good at, i.e. something point-and-clicky with graphics that doesn't take too much floating point resources and doesn't run unless the user is interacting with it.

It doesn't really apply to a discussion on porting the FAH client to mobile. But I think this quote from the article is a key point:

Getting individuals involved is key to the project, not just to process data, but to get people emotionally and intellectually invested in the mission and lend a new perspective on the world around us, Tarter said.

Which I take to mean that whether or not the SETI mobile app returns significant amounts of data, they still consider it useful for the marketing potential - if you can get people hooked on looking for aliens, they may sign up with their more powerful computers as well.

Candidates for FAH-related mobile applications could be FAH monitoring and/or protein visualization, or a program that lets users fold proteins "by hand".

But
a) such an app would do something different from FAH client number crunching, and
b) SETI didn't spend resources on this mobile app, it was made by a volunteer who managed to get funding from Adobe.

crunching by hand?. hm. Reminds me of http://fold.it

mephistopheles wrote:But
a) such an app would do something different from FAH client number crunching, and
b) SETI didn't spend resources on this mobile app, it was made by a volunteer who managed to get funding from Adobe.

If anybody has any suggestions for how to get Adobe (or anybody, for that matter) to fund the development of a Mobile app advertising FAH or a 3rd party that wants to develop one, I'm sure they'd make a lot of us happy.

The original answer to the original question remains the same. Mobile Apps don't do serious number-crunching. FAH does on your PS3, on your recent game-quality GPU, or your CPU (multi-core recommended).

A folding monitor that could access shared directories containing the fahlog.txt files of clients on your home network, calculate PPD, give you status notifications if a client stops or EUE's, and let you view fahlog.txt all on your iPhone/iPad would be very useful.