I would not say that the goal of GPU users is to "gain large amounts of credit quickly". that's a pretty large mischaracterization in my opinion.

most, if not all, of us use GPUs because they are massively more power efficient for the work being done. hundreds or thousands of times more work done per watt than CPUs when properly coded/optimized. since most of us pay for our own electricity to donate free compute resources, it makes sense that people will go for a power efficient device.

Or people like me that buy hardware for other purposes but would rather let them do useful work instead of idling... Sure, at cost of paying (a lot) more for electricity, but that's just another form of donation. That's kinda the original pitch of boinc, though people bother to show up on forums are probably more dedicated. :-)

If I exclude math projects that I don't have much interest in, the number of CPU projects aren't that abundant these days either, so I am glad there will still meaningful work to do here.

I would not say that the goal of GPU users is to "gain large amounts of credit quickly". that's a pretty large mischaracterization in my opinion.

most, if not all, of us use GPUs because they are massively more power efficient for the work being done. hundreds or thousands of times more work done per watt than CPUs when properly coded/optimized. since most of us pay for our own electricity to donate free compute resources, it makes sense that people will go for a power efficient device.

Or people like me that buy hardware for other purposes but would rather let them do useful work instead of idling... Sure, at cost of paying (a lot) more for electricity, but that's just another form of donation. That's kinda the original pitch of boinc, though people bother to show up on forums are probably more dedicated. :-)

If I exclude math projects that I don't have much interest in, the number of CPU projects aren't that abundant these days either, so I am glad there will still meaningful work to do here.

There is a brand new on that will hopefully get the help they need to become a full fledged Boinc Project, they've sent out 10 total tasks so far, none are available to get though and they are Windows cpu only right now.

There are also more Boinc Projects than Chooka posted that are not listed in the Boinc Manager, most are small and can't keep going with the overwhelming crowds that tend to come when they find something new, which is understandable because as you said the total number of Projects is dwindling. https://gerasim.boinc.ru/ is one he didn't mention though and although they have the venue settings backwards to other Boinc Projects they do mostly have tasks or will generate some if you want them.

Nice to see that all the donated computation time did help to come to an end of the research project....

Like others here, I was just about to get a lot of FP64 capable GPUs (I like the thought of putting these otherwise uselss GPUS to a meaningfull purpose)..

Is there really no other GPU FP64 project out there?

asteroids makes use of FP64. but it's not 100% dependent like MW Separation is. so you get *some* benefit with good FP64 performance, but it can be overshadowed with even stronger FP32 numbers and raw clock speed, like the 40-series cards. plus their GPU CUDA app isn't very well optimized, and while it's faster (per task) on GPU you get better overall production per watt on CPU because the CPU can run so many in parallel.

a titan V is a decent performer on Asteroids, but older cards with only OK FP64 and outdated FP32 (like kepler cards) don't perform very well.

old AMD cards wont work on asteroids since they only have CUDA apps.

---

Question for Tom. In this video, https://www.youtube.com/watch?v=ma44b8-SLcA Professor Heidi mentions wanting to run simulations on multiple dwarf galaxies at the same time. Starts at about 11:40 in the video. Has this been done already? And will it be part of the paper?

This is my mostedest favoritedest project ever! Thanks a bunch.

Thanks for the enthusiasm! The video that you linked is discussing the Nbody project, which will still be running after the Separation project goes dark. We don't have support for multiple dwarf galaxies yet (you can do it manually but not in the BOINC simulations). Our focus is currently on adding the Large Magellanic Cloud to the simulations.

I curious as well if Macs well be supported again in Nbody

Sjmielh

We currently have a student who is working on getting Mac Nbody running again. I think he has made good progress, but I'm not sure how far out we are from releasing a Mac Nbody binary.

Also thank you all who are willing to look at the GPU code! The issue is that we are going to continue to make changes to the Nbody code, so we would need to keep a version of the GPU code up to date along with it. This is a lot of work and really isn't feasible for our group at the moment. It is very generous for you to donate your time to try to optimize the GPU code, but it is unreasonable for us to support GPU code because we would need someone to keep it updated.

Also thank you all who are willing to look at the GPU code! The issue is that we are going to continue to make changes to the Nbody code, so we would need to keep a version of the GPU code up to date along with it. This is a lot of work and really isn't feasible for our group at the moment. It is very generous for you to donate your time to try to optimize the GPU code, but it is unreasonable for us to support GPU code because we would need someone to keep it updated.

what kind of changes need to be made on a recurring basis? if it's just normal file IO/formatting stuff that can easily be handled as needed if you just communicate what's changing.

if you could provide working GPU code now, and then just communicate changes as they happen we could incorporate them into our GPU code.

---

what kind of changes need to be made on a recurring basis? if it's just normal file IO/formatting stuff that can easily be handled as needed if you just communicate what's changing.

if you could provide working GPU code now, and then just communicate changes as they happen we could incorporate them into our GPU code.

Unfortunately it isn't simple stuff, it's adding new physics to the simulations. So it's not just file/io reading stuff, it's things like making dark matter interact with a scattering cross section instead of just gravitationally.

I can see if the GPU code branch is up (I think it probably is, but I'll have to double check. This isn't something I work on), and share it if it is. But right now we don't have any plans to support GPU Nbody in the future.

if the main parts are changing all the time, it's hard to write an efficient GPU implementation without enough manpower. It's not like optimizing a well-known algorithm like FFT...

what about a hybrid approach? accelerate only hot parts that don't change too often? it could ease the maintenance, but on the other hand, the overhead may be too large, so it won't be efficient.

thank you for your feedback and efforts. Much appreciated!

I have a MacBook Air.

Ah, that's the problem then, N-Body is currently not available for Macs. (See applications.) But see Tom's post saying that there is progress towards that, albeit with no ETA.

In addition to some projects listed in previous posts, your CPU is 64-bit capable so an upgrade to a 64-bit OS is possible (you likely already know this but still).
I downloaded some Asteroid@home tasks and they were using very little memory in the short time I ran them (less than 10 MB of memory per task).

Sure it is, but why use 64 bit with 4 GB RAM and no dedicated graphics? Just means increased use of already limited RAM, so crippling performance further. And reinstalling Win 7 now would be a terrible pain.

Asteroids... Seem to have considered it after SETI@home ended, but never actually tried it, not entirely sure why, but since I see that the server was out for over a year, maybe it was already out then? And a glance on the forums now says that even after the project came back up, work is intermittent. So can't be a full replacement.

According to this page Moo Wrapper has 32bit cpu tasks as well https://moowrap.net/apps.php

From what I see, Moo Wrapper just allows distributed.net projects to run on BOINC? If so, distributed.net seems to just list 2 current projects, 1 in encryption and 1 in math. And 2 in math and 1 in encryption as possible future projects. No interest in any of that.

Math is finished. Only encryption is left.

I don't care if I am using GPU or CPU. My aim is not any sort of badges or rewards, just do the most I can to help all projects under BOINC to
obtain the required data for their successful processing leading to new discoveries in science. The cost of electricity has been increasing
remarkedly in Australia (we pay highest rates in the world, amazingly) and I have cut my hours of processing on my 5 computers from 24 x 7
to 16 x 7 (which has saved me $30 per seek), but it is still high for a pensioner to pay. BOINC is like a hobby for me (though I do not have to do
much!...LOL)

---

asteroids makes use of FP64. but it's not 100% dependent like MW Separation is. so you get *some* benefit with good FP64 performance, but it can be overshadowed with even stronger FP32 numbers and raw clock speed, like the 40-series cards. plus their GPU CUDA app isn't very well optimized, and while it's faster (per task) on GPU you get better overall production per watt on CPU because the CPU can run so many in parallel.

a titan V is a decent performer on Asteroids, but older cards with only OK FP64 and outdated FP32 (like kepler cards) don't perform very well.

old AMD cards wont work on asteroids since they only have CUDA apps.

Thanx for this helpful answer.

It´s too bad - I just spend the last couple days compiling a spreadsheet with FP64 numbers, including efficiency and FP64 per watt, looked for older GCN2 cards with 2:1 FP32(FP64 ratio, Kepler cards, etc and was actually ready to spend some money on these oldies to put them to good use (I like the thought of giving this itherwise more or less uselesse gear some new purpose) - sustainability and keeping them from being dumped in landfill or recycling..

I guess I saved some money now :)

I don't care if I am using GPU or CPU. My aim is not any sort of badges or rewards, just do the most I can to help all projects under BOINC to
obtain the required data for their successful processing leading to new discoveries in science. The cost of electricity has been increasing
remarkedly in Australia (we pay highest rates in the world, amazingly) and I have cut my hours of processing on my 5 computers from 24 x 7
to 16 x 7 (which has saved me $30 per seek), but it is still high for a pensioner to pay. BOINC is like a hobby for me (though I do not have to do
much!...LOL)

I hear you Chris! Likewise I've had to cut back. Electricity is killing me.
Even with a 6Kw solar, my last bill from Jan to Apr was $1700 ($1200 with the discount) From the first of July, that bill would be over $2200 (without the discount)
That's insane!
Admittedly, the air con is no longer running at least here in QLD.
{33.46c jumping to 45.37c/kWh + daily connection fee going from $1.17/day to $1.26/day}

See AGL's result today?

"AGL said "sustained periods" of higher wholesale electricity prices mean underlying earnings for FY24 are forecast to surge to $1.875b and $2.175b and profits more than double from $580m to $780m."

Meanwhile people are having to choose between food or keeping the lights on.
Should never have privatised a basic necessity like electricity. It shouldn't be a money making machine for shareholders.

---

I bought much of my hardware with Separation's rather unique FP64 requirements in mind. It's a shame that it is ending.
Is there an expected time frame for tasks to run out?

I have seen the odd task on two other projects benefit from FP64. I too deliberately bought old 1:4 GPUs for this project. One such project is World Community Grid, but their GPU tasks are very rare. I can't remember what the other one was! They're not entirely FP64, but I could see my FP64 cards doing better than they should if it were a plain FP32 task.

Hate to say it, but a lot of users will not stay/come back to just run CPU on this project as they are used to what their GPU can do. So expect a large drop off of users after.

I disagree - since it was not possible to run both on the same computer. So the Nbodys being done were on non-GPU machines.

However, maybe spend sometime optimizing the N-Body GPU app so that maybe they will stay/come back? Especially if you can find a way to utilize NVDIA CUDA more to bring those users in?

Some things just don't run well on GPUs. Pointless to do so without the massive benefit of speed. Best take the GPUs to another project.

I for one have switched Nbody on with all my computers, instead of just the non-GPU ones, so I'm doing more Nbody than before.

asteroids makes use of FP64. but it's not 100% dependent like MW Separation is. so you get *some* benefit with good FP64 performance, but it can be overshadowed with even stronger FP32 numbers and raw clock speed, like the 40-series cards. plus their GPU CUDA app isn't very well optimized, and while it's faster (per task) on GPU you get better overall production per watt on CPU because the CPU can run so many in parallel.

a titan V is a decent performer on Asteroids, but older cards with only OK FP64 and outdated FP32 (like kepler cards) don't perform very well.

old AMD cards wont work on asteroids since they only have CUDA apps.

Thanx for this helpful answer.

It´s too bad - I just spend the last couple days compiling a spreadsheet with FP64 numbers, including efficiency and FP64 per watt, looked for older GCN2 cards with 2:1 FP32(FP64 ratio, Kepler cards, etc and was actually ready to spend some money on these oldies to put them to good use (I like the thought of giving this itherwise more or less uselesse gear some new purpose) - sustainability and keeping them from being dumped in landfill or recycling..

I guess I saved some money now :)

This page might have saved you alot of spreadsheet time https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#Compute_capability_table
scroll down to see the FP64/FP32 ratio's