I do not understand how using GPU optimized application could be bad,
in contrary. My CPU has a calculating speed of 3.4 gigaflops per core while my
Radeon 4870 card have a calculating speed of 1.2 teraflops, that is 353 times
faster. I am totally amazed that there are only a volunteer in milkyway@home
that have been capable to write a program that can use this tremendous power.
IMO Einstein@home are using a slow crawling tractor when they could be using a rocket.
The GPU apps are well and good, bring them on. But tulio and mikey are expressing the view of the average joe blow computer user that doesn't have a fancy, high priced graphics card (some people even...gasp... still use intergrated graphics!). Not really needed when you're just surfing the net, checking your bank account or even perusing forums. I've a 2600 HD and a 3650 HD, both ATI. I can use the 2600 at Folding, but it is rather mediocre and AFAIK, the 3650 is too low end for any project. The other thing that I'll reiterate from tullio and mikey, is basically that w/o a graphics card and even if one has a pretty good CPU power, still left in the dust by the teraflop push of someone's GPU in ranking. That's why they would like to see a split in stats.
The GPU apps are well and good, bring them on. But tulio and mikey are expressing the view of the average joe blow computer user that doesn't have a fancy, high priced graphics card (some people even...gasp... still use intergrated graphics!). Not really needed when your just surfing the net, checking your bank account or even perusing the forums. I've a 2600 HD and a 3650 HD, both ATI. I can use the 2600 at Folding, but it is rather mediocre and AFAIK, the 3650 is too low end for any project. The other thing that I'll reiterate from tullio and mikey, is basically that w/o a graphics card and even if you have a pretty good CPU power, your still left in the dust by the teraflop push of someone's GPU in ranking. That's why they would like to see a split in stats.
You can buy a low end computer and put a high end video card in it.
The total cost will be much lower then a high end PC but it will outpreform
ANY high end PC that does not have this cind of video card.
When you take in acount the preformance, power and power consumption the highend video card PC is light years ahead.
You can buy a low end computer and put a high end video card in it.
The total cost will be much lower then a high end PC but it will outpreform
ANY high end PC that does not have this cind of video card.
When you take in acount the preformance, power and power consumption the highend video card PC is light years ahead.
That's all quite true, but the 'demographics' of the E@H cruncher population is such that the vast majority of users aren't anywhere near the level of, or even interest in, this discussion. The design of the project ( and BOINC in general ) is for casual science use of the hardware after the main role of the computer has been dispensed with. Thus predominantly the target boxes are likely to be optimised for something else entirely - low cost and convenience are common goals.
Quote:
{ An early and ongoing criterion for E@H was to take very good care of dial-up users, so max ~ 56K there and generally much lower, simply because that represents the vast bulk of internet connection types worldwide. The design of the entire strategy for parceling out of WU's pivots around this. }
Hence that must remain a feature as low/slow boxes really do vastly outnumber the hotshots. So while it's OK to allow top end performance that must never be a detriment to the bulk. All the back end work at this project reflects that. I ought say the E@H developers have been very good at attempting to exploit ( within fiscal and human limits ) the variety of possible target circumstances.
Those of us huddled here are on a mere twig of the tree E@H participants. A pretty keen twig admittedly .... :-)
Cheers, Mike.
( edit ) Sorry, I've got fumble-fingers this morning. Midshipman! More caffeine!
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
What I am suggesting, basing upon what is happening at SETI, is that the use of graphic cards to process applications is not an simply an evolution of BOINC but a revolution along Thomas Kuhn's lines, that is a new paradigm. And in a revolution people (and projects) can get hurt. Thanks to Mike, mikey and nevermore for supporting my hunch.
Tullio
Having a glance at the CUDA area of NVidia there's obviously some exciting stuff like massive parallelism say, where FFT's seem to be a mere snack for them. But :
- the hardware is obviously proprietary.
- it has a C and other language ports to program with BUT limitations like no recursion, no use of function pointers, a single process must run across multiple disjoint memory spaces, and not all the usual IEEE floating point behaviours for double precision.
- full performance benefits only if threads number in the thousands and better if in groups of 32!
So while do-able ( don't ask me to! ) I think it looks like a right royal pain to convert current sources ( ie. re-write ) to quite a different software architecture.
I just hope Bernd and Oliver don't read this thread - they'll have a fit!
"You want WHAT other platform ??" :-) :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Another aspect which would slow the adoption of new directions like CUDA is direct testing with respect to the science goals of E@H. It has been demonstrated before that it is of no use relying purely upon quorums to define acceptability of results - an incorrectly functioning app cannot be saved by that. There is a more general concept of 'certification' of software. A mixture of apps, at source level, may be hazardous.
I won't go through the full historic detail of dear Akos Fekete's tremendous initial assembler level optimisations of the binaries ( ie. post compile ), but the upshot can be summarised as follows :
- E@H was born, by Prof. Allen's impetus ( brilliant foresight boss! ), of the need to enact vast processing power for the signal analysis on IFO data for the Continuous Wave Group of LIGO. Looking for certain types of neutron star behaviours that is.
- this sub-arm of LIGO doesn't have the money to complete this in-house.
- BOINC was an available infrastructure/model to farm out the work on a volunteer basis, thus a 'free' outsourcing of computing ability. Not only hardware, but power consumption and other costs were avoided by LIGO. We crunchers choose to carry that burden.
- LIGO is a very unique type of collaboration amongst a big group of professional scientists in an area of investigation where, shall I say politely, quality and accuracy of results cannot be any less than first rate.
- there is an overarching sense, or need, to be as sure as one can be about the low level but crucial aspects like hardware dependencies.
- so fast is nice, but right is better. This project is quite conservative, and comparisons with other BOINC utilising entities really have only superficial analogies and lessons.
Sorry to sound like a wet blanket. I don't personally criticise anyone, or want to bucket on enthusiasm, but the context of our volunteer role here is quite particular.
Having said all that : it may well be that as CUDA matures, or at least some subset sufficient for E@H does along with an adequate market penetration of the proprietary technology, then we may well be speaking of CUDA apps at some time used here.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I very much agree with tullio's comparison to a revolution. The transition can be quite painful (ask Mac users who probably feel a bit neglected).
So what does CUDA (or GPU based Distributed Computing in general) mean for E@H? The devs have stated repeatedly that porting to GPUs is on their agenda. Let's not forget there are two searches, the S5R5 search alnd the PALFA search, both seem to offer opportunities for GPU processing but this has to be looked into.
It might well turn out that trying to make CPU and GPU apps compatible is not the right way to go, for example it might be better to handle the WU creation differently for CPU and GPU crunching, so maybe there would be different searches altogether, one for GPU and one for CPU (Milkyway@Home seems to head this way as well, right?). Maybe CUDA is not the future-proof way to go at all, maybe OpenCL will be. This is all my private speculation, but it shows the complexity of the task which goes beyond "just" porting the apps to CUDA, which is demanding in itself.
BTW, there was a report on a German news site (sorry, no English version available) that the AEI is currently installing some NVIDIA Tesla gear alongside the x86 based ATLAS supercomputer, so you can see that GPU processing is indeed considered in the Gravitational Wave community.
Hi all!
It might well turn out that trying to make CPU and GPU apps compatible is not the right way to go, for example it might be better to handle the WU creation differently for CPU and GPU crunching, so maybe there would be different searches altogether, one for GPU and one for CPU (Milkyway@Home seems to head this way as well, right?). Maybe CUDA is not the future-proof way to go at all, maybe OpenCL will be. This is all my private speculation, but it shows the complexity of the task which goes beyond "just" porting the apps to CUDA, which is demanding in itself.
CU Bikeman
As you probably already know, and alluded too, CUDA ONLY works on Nvidia cards! ATI cards take a different language altogether!! The new OpenCL that has been agreed to by all parties is the next greatest thing and will be a 'standard' for the use of all video cards to crunch under. I would guess that most projects that don't already support CUDA crunching are waiting for that.
Oh and just to clear up something...I do have 2 video cards crunching, they both crunch for Folding@home. I have a 9500GSO and a 9800GT, both are Nvidia cards. One is in a quad core machine, where 3 cores crunch for Boinc and 1 core is used solely to supply the video card, the other is in an Intel Celeron single core pc that is only running Folding. Video cards take alot of power wattage from the power supply and use a ton of cpu time to feed them. Boinc has made many attempts to combine cpu and gpu crunching but the results are not good at best. Yes it will work, but it is much more efficient to do it as I do then try to let Boinc figure it out. Will Boinc get better, OF COURSE IT WILL! But IMO it is not there yet. That is another limiting factor in projects jumping on the video card bandwagon, IMO.
I believe in 2 years there will be more projects with videocard processing available than without it. Some have already looked into it and have said it doesn't provide what the project needs in terms of how their own project runs. Some, like Seti, already allow for videocard crunching. Reliability, triple checking, whatever, all need to be considered before a videocard is allowed to crunch for a given project! The last thing a project wants to do is deliver BAD Science, especially when it is Science that is its main goal!
The new OpenCL that has been agreed to by all parties is the next greatest thing and will be a 'standard' for the use of all video cards to crunch under.
I think that is much more likable. Source code that taps OpenCL would, for instance :
- disconnect from proprietary aspects and similiar closed technology issues.
- be resilient to specific vendor success/failure.
- simplify/flatten the terrain for testing.
- take advantage of jointly developed common tools, economy of scale etc.
Stick with the pack! :-)
Quote:
Reliability, triple checking, whatever, all need to be considered before a videocard is allowed to crunch for a given project! The last thing a project wants to do is deliver BAD Science, especially when it is Science that is its main goal!
This is a recurrent theme - the tension between speed/credits and real world usefulness. Slow science is still solid science, but luring fast boxes in is a definite boon too. Not to forget that today's hotbox is tomorrow's sour lemon. Moore's Law et al.
Also you don't want to leave current volunteers behind, like the Mac users mentioned by Bikeman. That's disturbing. Not only for their particular sakes, but confidence can wane from others who may think they're next. It would sap a project to convey the impression of a preferred elite flavour. E@H has a long term mission tracking and servicing the IFO developments, an expanding worldwide network, and possible future integration with other astronomy modes just like PALFA. So one ought place a premium on volunteer loyalty. They don't have to do it ..... so don't give them any reason not to! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
This will get you an idea of
)
This will get you an idea of how much powe is used under low an hi load.
The measuremen is of the power used by the whole system.
RE: I do not understand how
)
The GPU apps are well and good, bring them on. But tulio and mikey are expressing the view of the average joe blow computer user that doesn't have a fancy, high priced graphics card (some people even...gasp... still use intergrated graphics!). Not really needed when you're just surfing the net, checking your bank account or even perusing forums. I've a 2600 HD and a 3650 HD, both ATI. I can use the 2600 at Folding, but it is rather mediocre and AFAIK, the 3650 is too low end for any project. The other thing that I'll reiterate from tullio and mikey, is basically that w/o a graphics card and even if one has a pretty good CPU power, still left in the dust by the teraflop push of someone's GPU in ranking. That's why they would like to see a split in stats.
RE: The GPU apps are well
)
You can buy a low end computer and put a high end video card in it.
The total cost will be much lower then a high end PC but it will outpreform
ANY high end PC that does not have this cind of video card.
When you take in acount the preformance, power and power consumption the highend video card PC is light years ahead.
RE: You can buy a low end
)
That's all quite true, but the 'demographics' of the E@H cruncher population is such that the vast majority of users aren't anywhere near the level of, or even interest in, this discussion. The design of the project ( and BOINC in general ) is for casual science use of the hardware after the main role of the computer has been dispensed with. Thus predominantly the target boxes are likely to be optimised for something else entirely - low cost and convenience are common goals.
Hence that must remain a feature as low/slow boxes really do vastly outnumber the hotshots. So while it's OK to allow top end performance that must never be a detriment to the bulk. All the back end work at this project reflects that. I ought say the E@H developers have been very good at attempting to exploit ( within fiscal and human limits ) the variety of possible target circumstances.
Those of us huddled here are on a mere twig of the tree E@H participants. A pretty keen twig admittedly .... :-)
Cheers, Mike.
( edit ) Sorry, I've got fumble-fingers this morning. Midshipman! More caffeine!
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
What I am suggesting, basing
)
What I am suggesting, basing upon what is happening at SETI, is that the use of graphic cards to process applications is not an simply an evolution of BOINC but a revolution along Thomas Kuhn's lines, that is a new paradigm. And in a revolution people (and projects) can get hurt. Thanks to Mike, mikey and nevermore for supporting my hunch.
Tullio
Having a glance at the CUDA
)
Having a glance at the CUDA area of NVidia there's obviously some exciting stuff like massive parallelism say, where FFT's seem to be a mere snack for them. But :
- the hardware is obviously proprietary.
- it has a C and other language ports to program with BUT limitations like no recursion, no use of function pointers, a single process must run across multiple disjoint memory spaces, and not all the usual IEEE floating point behaviours for double precision.
- full performance benefits only if threads number in the thousands and better if in groups of 32!
So while do-able ( don't ask me to! ) I think it looks like a right royal pain to convert current sources ( ie. re-write ) to quite a different software architecture.
I just hope Bernd and Oliver don't read this thread - they'll have a fit!
"You want WHAT other platform ??" :-) :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Another aspect which would
)
Another aspect which would slow the adoption of new directions like CUDA is direct testing with respect to the science goals of E@H. It has been demonstrated before that it is of no use relying purely upon quorums to define acceptability of results - an incorrectly functioning app cannot be saved by that. There is a more general concept of 'certification' of software. A mixture of apps, at source level, may be hazardous.
I won't go through the full historic detail of dear Akos Fekete's tremendous initial assembler level optimisations of the binaries ( ie. post compile ), but the upshot can be summarised as follows :
- E@H was born, by Prof. Allen's impetus ( brilliant foresight boss! ), of the need to enact vast processing power for the signal analysis on IFO data for the Continuous Wave Group of LIGO. Looking for certain types of neutron star behaviours that is.
- this sub-arm of LIGO doesn't have the money to complete this in-house.
- BOINC was an available infrastructure/model to farm out the work on a volunteer basis, thus a 'free' outsourcing of computing ability. Not only hardware, but power consumption and other costs were avoided by LIGO. We crunchers choose to carry that burden.
- LIGO is a very unique type of collaboration amongst a big group of professional scientists in an area of investigation where, shall I say politely, quality and accuracy of results cannot be any less than first rate.
- there is an overarching sense, or need, to be as sure as one can be about the low level but crucial aspects like hardware dependencies.
- so fast is nice, but right is better. This project is quite conservative, and comparisons with other BOINC utilising entities really have only superficial analogies and lessons.
Sorry to sound like a wet blanket. I don't personally criticise anyone, or want to bucket on enthusiasm, but the context of our volunteer role here is quite particular.
Having said all that : it may well be that as CUDA matures, or at least some subset sufficient for E@H does along with an adequate market penetration of the proprietary technology, then we may well be speaking of CUDA apps at some time used here.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Hi all! I very much agree
)
Hi all!
I very much agree with tullio's comparison to a revolution. The transition can be quite painful (ask Mac users who probably feel a bit neglected).
So what does CUDA (or GPU based Distributed Computing in general) mean for E@H? The devs have stated repeatedly that porting to GPUs is on their agenda. Let's not forget there are two searches, the S5R5 search alnd the PALFA search, both seem to offer opportunities for GPU processing but this has to be looked into.
It might well turn out that trying to make CPU and GPU apps compatible is not the right way to go, for example it might be better to handle the WU creation differently for CPU and GPU crunching, so maybe there would be different searches altogether, one for GPU and one for CPU (Milkyway@Home seems to head this way as well, right?). Maybe CUDA is not the future-proof way to go at all, maybe OpenCL will be. This is all my private speculation, but it shows the complexity of the task which goes beyond "just" porting the apps to CUDA, which is demanding in itself.
BTW, there was a report on a German news site (sorry, no English version available) that the AEI is currently installing some NVIDIA Tesla gear alongside the x86 based ATLAS supercomputer, so you can see that GPU processing is indeed considered in the Gravitational Wave community.
CU
Bikeman
RE: Hi all! It might well
)
As you probably already know, and alluded too, CUDA ONLY works on Nvidia cards! ATI cards take a different language altogether!! The new OpenCL that has been agreed to by all parties is the next greatest thing and will be a 'standard' for the use of all video cards to crunch under. I would guess that most projects that don't already support CUDA crunching are waiting for that.
Oh and just to clear up something...I do have 2 video cards crunching, they both crunch for Folding@home. I have a 9500GSO and a 9800GT, both are Nvidia cards. One is in a quad core machine, where 3 cores crunch for Boinc and 1 core is used solely to supply the video card, the other is in an Intel Celeron single core pc that is only running Folding. Video cards take alot of power wattage from the power supply and use a ton of cpu time to feed them. Boinc has made many attempts to combine cpu and gpu crunching but the results are not good at best. Yes it will work, but it is much more efficient to do it as I do then try to let Boinc figure it out. Will Boinc get better, OF COURSE IT WILL! But IMO it is not there yet. That is another limiting factor in projects jumping on the video card bandwagon, IMO.
I believe in 2 years there will be more projects with videocard processing available than without it. Some have already looked into it and have said it doesn't provide what the project needs in terms of how their own project runs. Some, like Seti, already allow for videocard crunching. Reliability, triple checking, whatever, all need to be considered before a videocard is allowed to crunch for a given project! The last thing a project wants to do is deliver BAD Science, especially when it is Science that is its main goal!
RE: The new OpenCL that has
)
I think that is much more likable. Source code that taps OpenCL would, for instance :
- disconnect from proprietary aspects and similiar closed technology issues.
- be resilient to specific vendor success/failure.
- simplify/flatten the terrain for testing.
- take advantage of jointly developed common tools, economy of scale etc.
Stick with the pack! :-)
This is a recurrent theme - the tension between speed/credits and real world usefulness. Slow science is still solid science, but luring fast boxes in is a definite boon too. Not to forget that today's hotbox is tomorrow's sour lemon. Moore's Law et al.
Also you don't want to leave current volunteers behind, like the Mac users mentioned by Bikeman. That's disturbing. Not only for their particular sakes, but confidence can wane from others who may think they're next. It would sap a project to convey the impression of a preferred elite flavour. E@H has a long term mission tracking and servicing the IFO developments, an expanding worldwide network, and possible future integration with other astronomy modes just like PALFA. So one ought place a premium on volunteer loyalty. They don't have to do it ..... so don't give them any reason not to! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal