toTOW wrote:You can't compare an ARM processor and a P3 ... they're completely different. The ARM processors are not designed for computing power, they're designed to be low power processors.
Used to be true but not true anymore base on the latest ARM development. A power to be reckon with. If INTEL is not careful it may not be the CPU of choice in the future
You can't compare a ultra-low-voltage, ultra-mobile processor and a multicore server/desktop CPU ... they're completely different. The ULV/UM processors are not designed for computing power, they're designed to be low power processors.
It takes power to switch transistor logic gates. More gates, more power, faster switching, more power. To put it into perspective, an iPhone battery would run a 6-core i7 for about 3 minutes, ignoring other laws of physics and thermodynamics that make such a fast discharge from that battery impossible.
I don't doubt that they'll sell a lot of ARM processors, and the move from 32-bit to 64-bit is an important step forward, but it's not clear that this has anything to do with FAH, for two very important reasons.
1) FAH is a heavy user of Floating Point operations. From everything I've seen (which is admittedly not everything that has been announced) ARM does not provide good support for Floating Point. When Intel developed the original 8086/8088 line, the same was true. If you wanted to do math processing, you needed a separate socket for the 8087 chip, which was called a "math coprocessor" because it had hardware support for Floating Point. In those days, they were in transition between 8-bit and 16-bit for integers and addresses, but that's a completely independent consideration. The floating point hardware wasn't integrated into the x86 line until several generations later (in the 80486). It's likely that the ARM series will progress through a similar series of enhancements, but until it has floating point hardware to do the Math, there will be no FAH client.
2) Battery power and FAH do not mix. Low power CPUs are vital to battery powered installations (and although they eventually migrate to the desktop, which is good, the question here is what about the iPhone/IPod/etc.) Support for active power management techniques that let the CPU "rest" in an even lower powered state than when it's actively doing something is also vital for battery powered devices. On the other hand, FAH is specifically designed to keep the processor busy 100% of the time -- which is to say it's specifically designed to run down your batteries as quickly as possible. One of the first recommendations we make for someone new to FAH (on the desktop) is to disable the power-saving features of your CPU. FAH cannot work when the CPU is sleeping, whether it's a micro-sleep while it waits for you to move the cursor or a full hibernation when you actually realize it's inactive.
FAH does have a setting for laptops to allow processing to be suspended when running on batteries. (Laptops do have support for Floating Point math.) That means you CAN fold on a laptop when it's plugged in to the mains, but if a laptop is actually used as a portable device rather than an expensive desktop device, performance suffers for two reasons: 1) It's only useful part of the time, and 2) Both the CPU and the GPU in laptops are specifically designed for low-power, and as such, their performance for FAH is inferior to similar designs for desktop computers.
Yes I have read all these before so I do agree with your points. My point is watch for today and future ARM development. They already have a floating point unit and they will be in server market and they are not low power in a server configuration ... FAH will go with whatever is commonly used to get the computing resources.
I bet you if 5 out of 10 people are using ARM desktop wouldn't it be a good idea for FAH to TAP into that resource.
overdoze wrote:I bet you if 5 out of 10 people are using ARM desktop wouldn't it be a good idea for FAH to TAP into that resource.
One more point: I forgot to mention that generally speaking, RISC hardware is very fast when doing simple things but slows down significantly when doing complex things like FAH.
Anyway, FAH will only tap into the resource if it's worth it. With your 5 out of 10 number, it might happen but that's a pretty big number, so it may or may not ever happen. And then there's the cost of porting all the software to a new instruction set (see the referenced link about HP) and then scientifically re-certifying the software -- so it's not going to be seriously considered any time soon. Long term, lots of things might happen and there's no way to predict with what we know today.
Hardware configuration: Intel i7-4770K @ 4.5 GHz, 16 GB DDR3-2133 Corsair Vengence (black/red), EVGA GTX 760 @ 1200 MHz, on an Asus Maximus VI Hero MB (black/red), in a blacked out Antec P280 Tower, with a Xigmatek Night Hawk (black) HSF, Seasonic 760w Platinum (black case, sleeves, wires), 4 SilenX 120mm Case fans with silicon fan gaskets and silicon mounts (all black), a 512GB Samsung SSD (black), and a 2TB Black Western Digital HD (silver/black).
The Chinese getting involved in the CPU business could be the best thing in over a decade for computing. Intel seems to stay one small step ahead of AMD, only releasing enough R&D material to maintain that margin and charge through the nose for it. AMD hasn't really brought anything to the table since 939/940 K8 stuff with integrated memory controllers. Zambezi might be something good if they can ever ramp up production and clock speeds, but it's starting at a disadvantage since Gulftown has a 27% smaller die, and is therefore cheaper to manufacture.
I think that even if iPods and iPhone's have very low powers networking Several together would work right?
also regarding to the battery issue you could make it so that it will only run while connected to power during the night. that would mean that we would be able dedicate our phones to just folding for 8+ hours right?
The networking would not move data fast enough between them to be useful for folding at this point in time. So any client built around them would need to only run on a single iPad or iPhone.
iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
Also, when running while connected power, the amount of energy that would be consumed an efficient folding 'app' would massively slow down charging (kinda like how Skype video on an Iphone 3GS still drained the battery while charging...)
The battery issue would be significant as has already been said. Even a full-fledged laptop runs into battery limitations and look at the comparative size of their battery.
The other issue is that the compute power of the iPhone/iPad might be reasonable for integer calculations (MHz/GHz) but has anybody seen a GFLOPS number for floating point calculations for them? The FAH client and FahCore was ported to the PS3 (at considerable expense, by the way) and its processor did do a reasonable number of GFLOPS at a cost of lots of heat when it first came on the market, but Sony saw no need to keep up with the progress in GPUs and Multi-Core Intel comparable hardware.
Don't you all think that running F@H on these mobile devices will always be when plugged in? I'm using an Android tablet to show streamed movies on my HDTV through the HDMI port, but whenever I do that, I plug in the power cord.
Heck, even with the laptops running F@H, the default in v7 is to terminate folding when in battery mode - so I always have the laptops plugged in when I'm folding. If I'm sitting in an airport with the computer on my knees while surfing the web or getting email, I'm not folding.
One question that was raised a while ago is that the mobile devices would be good to run the FAH Control GUI - not the client or the folding cores. It would be awesome to use an Android phone/pad or Iphone/Pad/Pod in WiFi mode to monitor and control the folding on my other devices around the house. There should be no issue at all on horsepower there.
bruce wrote:The other issue is that the compute power of the iPhone/iPad might be reasonable for integer calculations (MHz/GHz) but has anybody seen a GFLOPS number for floating point calculations for them? The FAH client and FahCore was ported to the PS3 (at considerable expense, by the way) and its processor did do a reasonable number of GFLOPS at a cost of lots of heat when it first came on the market, but Sony saw no need to keep up with the progress in GPUs and Multi-Core Intel comparable hardware.
My nexus 10 gets 2.3 GFLOPS using RGbenchmm. The iphone/ipad uses similar hardware so it should be close. Still waiting for an announcement on opencl drivers the arndale board should get it soon the developers were targeting mid January but it slipped due to Christmas vacation. No word for about a month on development sitting on a wait and see.
Some neat things i got v7 running on ubuntu for arm I did not try running the local client but it did connect to my laptop. I also go v6 to fold on an emulated x86 linux client. If i remember correctly it was would have finished in 233 days. The things to remember are that it was going through an emulator, running on top of android and for some reason it was only using have the cpu, but still it was neat to see it run.
BIG_RED wrote:My nexus 10 gets 2.3 GFLOPS using RGbenchmm. The iphone/ipad uses similar hardware so it should be close.
OK, but is that 2.3 GFLOPS going to be adequate to complete WUs within the deadline? Possibly, according to the Processor GFlops Compilation table.
My very modest (by today's standards) AMD Athlon 64 X2 4200+ CPU @ 2.20Ghz finishes its smp:2 WUs well within the deadlines, and according to the above table, it has 6.8183 Average GFlops. The Intel Celeron 325 @ 2.53GHz in that table comes closest to your nexus 10's GFLOPS value, having 2.6307 Average GFlops. I don't know if anyone is currently folding with the Celeron 325, but it might be interesting to find out what PPDs they were getting.
art_l_j_PlanetAMD64
Over 1.04 Billion Total Points
Over 185,000 Work Units
Over 3,800,000 PPD
Overall rank (if points are combined) 20 of 1721690
In memory of my Mother May 12th 1923 - February 10th 2012