Combining CPU's to process Work Units
4 Jun 2006 11:13:30 UTC
Topic 191317
(moderation:
I was just wondering if it is possiable to combine the power of all CPU's available to process one work unit (either for HT or Dual Core or even both)?
http://www.boincstats.com/signature/user_87657.gif
Combining CPU's to process Work Units
)
I believe it would be hard. It is again the nature of how BOINC scheduler works.
Further, particular BOINC project aplication (i.e. Einstein) would have to be programmed multi-threaded.
I agree that it may have some benefit like less memory and disk usage running single WU faster instead of several WUs in a longer period.
(AFAICR, only CPDN tryed such application last year during early stage of beta-testing).
I believe AMD is working on
)
I believe AMD is working on 'anti-HT'. Rather than taking one core and making it run two threads, they will take two cores and have them process one thread. I'm not sure of all the details but let me see if I can find an article for you guys.
EDIT - Here is a google translation of the original article
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
I can't see a way to split a
)
I can't see a way to split a thread apart and keep it internally syncronized without a major performance hit without having a shared set of registers.This has existed as a feature in x86 since the early pentium days (p2???) under the name parallel pipelining. If what they're doing, all protestations aside, isn't doubling the number of registers adn pipelines and adding HT support I'm baffled as to what it could be.
EDIT: Just saw your edit. I'd be fascinated to see how they're planning on bringing this off. Latencies between seperate sockets are an issue with high performance multithreaded apps, completely rewriting a singlethreaded app on the fly to handle far more frequently needed syncronization looks to be a monumental challenge.
The current Einstein@Home App
)
The current Einstein@Home App could easily be made multithreaded. Unlike than e.g. with CPDN, where the next stage of the model depends on the previous stage, the calculations done e.g. for a single sky position is independent of all the others, so it would just be splitting the lopp over them. However this is also the reason why running two WUs using two CPUs one after the other wouldn't be faster than running two WUs in parallel with only one CPU each. As Einstein@Home is CPU-bound instead of e.g. I/O-bound, the overhead doesn't matter much on modern systems. And last but not least this would require a heavy modification to BOINC and the way it handles CPUs.
BM
BM