Folding@Home - reaching final target soon.

Nothing makes my inner geek happier than saying "My hobby is computational chemistry." For the last few years I have been taking part in the distributed computation Folding@home project. This Stanford University project uses donated computer time to study protein folding. A better understanding of protein folding will advance medical research looking for solutions to diseases such as Alzheimers, Huntingtons, Parkingsons and many cancers.

I kind of fell into the project in 2008 when looking for a worthwhile activity for my Mac G5 that had the problem of crashing when waking from sleep mode. The folding@home project kept the system busy and the cause is worthwhile. The CPU donations don't come for free as a flat out computer (or two) adds noticeably to the quarterly electric bill, offset somewhat by a set of PV Solar panels on the roof.

One feature of the project is the donation stats generated from returning completed work units. Donors join teams and those teams compete for ranking and placement on the donation stats boards. These stats are post-processed by a couple of web sites ExtremeOverclocking and KoaoStats give a sense of community and competition. There are also a good set of forums to get help and support for running the work units.

Folding@home can be done on wide variety of machines and operating systems. Work units can also be done on higher spec graphics cards using a CUDA compatible folding client. Folding can use all or just part of a machine's capacity by setting values in a configuration files. When running on all CPUs the power supply, motherboard and cooling are throughly tested. At one stage I had Mac, Windows 7 and Ubuntu folding side by side with a GPU client. The best performance numbers from a single machine, with an Intel Gulftown Hexacore cpu was ...

NODE (s) Real (s) (%)

Time: 17278.673 17278.673 100.0

4h47:58

(Mnbf/s) (GFlops) (ns/day) (hour/ns)

Performance: 711.518 36.599 10.001 2.400

That kind of performance from a PC size machine in 2011 puts it along side a Cray T94 from the mid 90s.

There is lots to learn running a small group of high performance folding systems. Mostly that problems occur when you are not looking or just after you left on holiday. Other issues that required some technical attention....

• Software configuration control
• Power supply reliability both domestic input supply and ACtoDC converter
• PC System building, especially over clocking.
• CPU performance and CPU cooling
• Wine the PC on Linux environment
• Remote access for administration

I have enjoyed my time with the folding crew at Team MacOS X but having reached 12,000 work units and 30,000,000 folding points it's time to move on to other research projects. Posted here are my folding stats graph showing monthly output.

If you have some cpu cycles spare be it on a Mac, PC or even a Playstation 3 check out the Folding@home project.

HPC and parallel processing - 2 fave quotes

From HPC wire
Posted by Michael Feldman - November 27 @ 9:04AM

Clever software can make even great hardware humble. D-Wave CTO Geordie Rose, the panel's quantum computing advocate, argued that new algorithms can have a much bigger payoff than more powerful silicon. He noted that using Pollard's rho algorithm from 1977, it would take 12 years to factor a 90-digit number on a modern-day 400 teraflop Blue Gene supercomputer. But using the newer quadratic seive algorithm, it would take just 3 years to perform the same operation on a 1977 Apple II computer. When you consider the multi-million dollar investment that went into the Blue Gene supercomputer compared to the probable investment that went into developing the new algorithm, you can get some sense of the industry's misplaced priorities.


From Slashdot ..
By acidrain (35064) on Thursday March 22 2007, @08:00AM (#18441773)

Look guys. There is no multi-processing silver bullet. It isn't even such a hard problem, *if you stop trying to solve it at such a low level*. Break your application into separate pieces that, *don't need to communicate very often.* Then this is the same kind of problem scalable websites like Google, MySpace, Hotmail and so on, have already, just without having to factor in the reliability issues. Finer grained multi-threading just leads to deadlocks and is really hard to debug. If you *really must* render the same sphere on 100 processors at the same time, then you need the speed of a custom coded solution. But you don't so let it go. The main loop of your program will be just fine as a single threaded implementation, 1 processor will do, and farm the 10% code / 90 % heavy lifting out in big clean chunks to other processors. If you find yourself writing some bizzare multi-threaded message passing system so that you can have 100s of threads all modifying the same live object model at the same time -- you are fucked, just forget about it 'cause you will never be able to debug that one killer bug that you know is going to get you right as you go to ship.


Pure genius from the net