I participate in one of those distributed computer (www.ud.com) programs where your spare CPU time is used for some Great Cause (currently cancer research). I usually leave my computer on overnight (and idle). When I first go the program, it took about 8 hours per chunk of data. Now it takes under 3 hours. All of the chunks are about the same size, and about the same amount of work has to be done. Am I hallucinating, or has my CPU “learned” to do this task quicker? It’s a P4 if that makes a difference.
There is no manner of “AI” built into CPUs. Many of those distributed programs automatically update themselves when needed. Sounds like a programmer might have found a spot of code that could use some optimizing. It could also be a number of other factors, fragmented versus unfragmented drive, throughput (if the data isn’t all sent up front), etc.
One prosessor I cn think of off the top of my head that is on the market that does “learn” is the Transmeta Carusoe. Also CPU cache L1 L2 L3 keep the most used instructions stored close by in faster memory than having to go back to the main computer memory allowing the processes to be exicuted faster.
Indeed, UD automatically updates:
That’s a logical explanation. Or, the program is capable of handling different size data packets, and they decided to start breaking the data into smaller pieces.
There are certain, rather rare cases where you could really stretch a point and claim learning on the part of a computer/software combination. For example, if you have a software emulator (like the Mac PowerPC code that emulated the 68xxx instruction set), the computer can cache the translation so, particularly in the case of loops and subroutines, the code executes much faster on subsequent times through. But as people have said, it doesn’t sound like this is the case here, so unless you did something drastic here like defragmenting your drive, increasing virtual or RAM memory, or switching out of a power saving mode, it would be hard to explain that kind of speed improvement.
If it’s anything like the distributed data analysis for SETI@Home, the data chunks are all the same size, but some take longer to analyse than others because they contain more significant data, well actually, it’s the other way around; the computer gives up on some chunks early because of excessive noise or corruption in the data.
Now I know that radiometric data is a whole different kettle of fish to what your cancer research stuff is, but it may be the same thing; if the program recognises early on in the analysis process that the data isn’t going to yield any significant results (like maybe if some variables to be statistically analysed are just all over the place and way off the plot), it might be set to give up and get another chunk.
It’s also possible (I’m speculating) that certain tasks are sent out to be more thoroughly examined than others; again with the SETI thing, they send the same data out to several people as a safeguard against error or sabotage, I can imagine (still speculating) that if anything looked promising for a given chunk that they might send it out again, but with the instruction to analyse in more detail/at a higher resolution or whatever.
Of course a far more mundane possibility exists; when the program took 8 hours it was because you had some other process running, now that don’t, more CPU are available for the cancer research program.
That last paragraph makes me sound even more of an idiot than usual, it should read:
Of course a far more mundane possibility exists; when the program took 8 hours it was because you had some other process running, now that you don’t, more CPU cycles are available for the cancer research program.
Another factor is present to some degree (hard to tell what degree)…
Different mathematical functions take differring amounts of processor time. Even a fairly simple operation like a simple division can take different amounts of CPU time depending on the values you’re dividing. It is nearly impossible to accurately estimate the aggregate run time required to process large arrays of numbers, due to this indeterminacy. Please don’t ask me to explain as this is related to Turing’s Incomputability Theorem and it’s a good half-semester of CompSci classes in and of itself.
I run UD on 5 different machines, work and home. I have been participating for 5 months. Even though the the packages that UD sends are the same size, they may take a very different amount of time to calculate. What the program does is checks different known molecule compounds and try to ‘dock’ with the target protein. When it is successful, it get logged as a “hit”. All of the molecule clusters you download vary in complexity.
I have had simple molecule clusters run all the way through in 3 hours with 182 hits, and MFH (molecules from hell) run for 46+ hours (with the conformer count running in the billions) with only 6 hits.
I have had fast results running the VEGF protein molecules, but I usually have ups and downs when running the Superoxide Dismutase molecule.
Anyway, glad to hear you are using the spare CPU cycles to help find a cure for cancer! Keep on crunching those numbers!! = )
-Alex
sethdallob Ihave been running the same program you mentioned above since April 4th and while the time it takes my computer to run a data set apparently differs from yours, I have noticed a similar decrease in the time it takes. I also noticed that it seems like it is a bit quicker if you keep the primary task information screen closed.
Abby
-
-
- Um, this is rather vague, but there is a computer chip that can “learn”, as it is, somewhat. It is a simple 32-gate array, and the logic gates are resettable in their characteristics somehow, by the frequency of each gate’s use. Or something. -There’s only 32 gates per chip, so you’re not gonna replace your PIII anytime soon, and I understand that these gates are rather slow-operating for PC use. -You could buy them, though, but the implication was that these were cutting-edge devices, so they might be expensive. In a magazine article I read recently, some researcher used them to build insect-like robots that would do simple tasks (like, go towards a light in a dark room), and it was found that the systems that were allowed to program themselves did so differently than identical robots who had grad students set their chips up manually. The “learning” setups responded faster to changes in the test environment, and usually used less gates than the grad students’ setups did. At the time, it had not been detirmined exactly how this was so. Probably Scientific American, in the last few months. - MC
-