I already suggested a similar option as you in the past - my approach was to let a CPU core pre calculate the CPU only parts so a task can jump straight into GPU calculation.
But my guess is it's just not worth the effort, or not even possible within the boinc infrastrucutre. Plus for graphic cards with enough RAM there is an easy fix: run 2 tasks and offset them so that when one task is in CPU only calculation the GPU is still used by the other task. Also consider: these tasks use significant memory, if you can't run 2 tasks parallel on your card it might not work out for other tasks neither.
KLiK wrote:
Well, those gaps are from 10~15min long, compared to tasks working some 40~70min to finish.
That very heavily depends on the CPU.
My AMD 7800x3d has a total CPU time of 5 minutes per task
My Intel 10750H already has 21 minutes of CPU time - both are total including the gaps.
for speeding up the crunching times no GPU tasks. We all know that task from 49,5%~50% & from 99,5~100% are doing CPU only work. During those times, GPU is not working much. So why not release GPU for crunching other data?
Why?
Well, those gaps are from 10~15min long, compared to tasks working some 40~70min to finish. That means 20~30min GPU is not working & available from crunching, or in other words some 40~50% of task time GPU is not working - in which time other task can be started & completed, while CPU analyzes what it needs to analyze.
This will improve the GPU work load time & give back much more results back into feed - not only for this project, but also others which work on GPU...
Can this be done? ????♂️
Running two staggered tasks is a way around this but there are two problems, firstly if your graphics card only has 4 GB of memory then this is barely enough and you wind up fighting the OS (Windows 10 in my case) to stop it loading stuff that Microsoft or whoever thought was really important. The second problem is that you need to make sure the tasks stay staggered and don't wind up getting in sync, in which case they'll both be doing the CPU part at the same time which doesn't achieve anything.
The other thing to do is to run other types of GPU tasks but this also has problems. One is that the MeerKAT task seems to hog all the processing power and the GW task takes way longer, another is to make sure the computer has enough of both types of tasks and that it keeps running one of each (and not only MeerKATs).
It would be nice to be able to attribute a lower priority to another class of task such as MeerKAT so that these will run when the GPU is idle and then pause when a higher priority task starts to use it again. I've been doing this manually sometimes and it works well. So basically manually suspending all the MeerKAT tasks until the running GW task reaches 49.5% or 99.5% and then resuming a MeerKAT task. When the GW task starts GPU crunching again then I check if the MeerKAT task has checkpointed (by checking the *.cpt file in C:\ProgramData\BOINC\slots) and when it has, I pause it again and wait for the next 49.5% or 99.5%. Clearly I don't get out often enough.
He obviously changed his mind since he created both the 1.08 and 1.14 apps. The 1.08 app is the original version that offloads the toplist creation to the cpu at the 49.5 and 99.5 % points and the gpus go idle for however long the cpu takes to crunch the toplist depending on cpu speed for the most part.
But he also created the 1.14 app which does the calculations of the toplist on the gpu entirely at the ~48 and ~98% points and no calcs are done on any cpu.
He obviously changed his mind since he created both the 1.08 and 1.14 apps. The 1.08 app is the original version that offloads the toplist creation to the cpu at the 49.5 and 99.5 % points and the gpus go idle for however long the cpu takes to crunch the toplist depending on cpu speed for the most part.
But he also created the 1.14 app which does the calculations of the toplist on the gpu entirely at the ~48 and ~98% points and no calcs are done on any cpu.
There is another chunk of O3ASHF work that I issued just now. Sorry, I expected the previous one to last at least over the long weekend that we had in Germany.
The current chunk is the last of a continuous frequency range (up to 1468 Hz), we need to decide how to proceed with O3ASHF during this week.
KLiK wrote:SUGGESTION I
)
I already suggested a similar option as you in the past - my approach was to let a CPU core pre calculate the CPU only parts so a task can jump straight into GPU calculation.
But my guess is it's just not worth the effort, or not even possible within the boinc infrastrucutre. Plus for graphic cards with enough RAM there is an easy fix: run 2 tasks and offset them so that when one task is in CPU only calculation the GPU is still used by the other task. Also consider: these tasks use significant memory, if you can't run 2 tasks parallel on your card it might not work out for other tasks neither.
That very heavily depends on the CPU.
My AMD 7800x3d has a total CPU time of 5 minutes per task
My Intel 10750H already has 21 minutes of CPU time - both are total including the gaps.
Keith Myers wrote: Why not
)
Didn't Bernd say something about the precision on the cpu vs the gpu one time when talking about that?
KLiK wrote: SUGGESTION for
)
Running two staggered tasks is a way around this but there are two problems, firstly if your graphics card only has 4 GB of memory then this is barely enough and you wind up fighting the OS (Windows 10 in my case) to stop it loading stuff that Microsoft or whoever thought was really important. The second problem is that you need to make sure the tasks stay staggered and don't wind up getting in sync, in which case they'll both be doing the CPU part at the same time which doesn't achieve anything.
The other thing to do is to run other types of GPU tasks but this also has problems. One is that the MeerKAT task seems to hog all the processing power and the GW task takes way longer, another is to make sure the computer has enough of both types of tasks and that it keeps running one of each (and not only MeerKATs).
It would be nice to be able to attribute a lower priority to another class of task such as MeerKAT so that these will run when the GPU is idle and then pause when a higher priority task starts to use it again. I've been doing this manually sometimes and it works well. So basically manually suspending all the MeerKAT tasks until the running GW task reaches 49.5% or 99.5% and then resuming a MeerKAT task. When the GW task starts GPU crunching again then I check if the MeerKAT task has checkpointed (by checking the *.cpt file in C:\ProgramData\BOINC\slots) and when it has, I pause it again and wait for the next 49.5% or 99.5%. Clearly I don't get out often enough.
He obviously changed his mind
)
He obviously changed his mind since he created both the 1.08 and 1.14 apps. The 1.08 app is the original version that offloads the toplist creation to the cpu at the 49.5 and 99.5 % points and the gpus go idle for however long the cpu takes to crunch the toplist depending on cpu speed for the most part.
But he also created the 1.14 app which does the calculations of the toplist on the gpu entirely at the ~48 and ~98% points and no calcs are done on any cpu.
He explained all this in the forums. https://einsteinathome.org/goto/comment/223686
1.14 with RecalcGPU
or
1.08 with RecalcCPU
Suggest you read the thread to determine which app is best for your hardware and whether you run singles or multiples on the gpus.
astro-marwil
)
+1
Keith Myers wrote: He
)
KLiK's hosts are all Windows, so the only app he has available is the 1.07 OpenCL app, which does CPU recalc.
_________________________________________________________________________
Ian&Steve C. wrote:KLiK's
)
I hadn't checked to see what kind of hosts he has.
So just looked at that apps list. So Bernd got rid of the 1.08 entirely? Only the 1.14 app available now for Linux?
[Edit]
Went back and reviewed that thread. The old 1.08 (RecalcCPU) app got reissued and renamed as the 1.15(beta) app now.
So still have two choices available for RecalcGPU or RecalcCPU depending on whether you allow for beta applications.
There is another chunk of
)
There is another chunk of O3ASHF work that I issued just now. Sorry, I expected the previous one to last at least over the long weekend that we had in Germany.
The current chunk is the last of a continuous frequency range (up to 1468 Hz), we need to decide how to proceed with O3ASHF during this week.
BM
How many ? :) Stats page
)
How many ? :) Stats page kinda doesnt show atm ..
And when you gonna be at it . could you fix also BRP7 search progress ? that negative ammount of work is bugging me look on numbers .P
I just issued. another chunk
)
I just issued another chunk that should last for another few weeks.
The progress counter always needs some time to adjust to another chunk, usually 1d, 2d if work ran dry.
Regarding BRP7 I'm still waiting for input from the scientists.
BM