Message boards :
Number crunching :
Twin CPUs and multi-core nbody tasks - success :-)
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
How will this make it better? Twice the effort going into 64 bit? Less untidy programming catering for both? Surely we should continue using both if it's not a one size fits all? |
Send message Joined: 24 Jan 11 Posts: 708 Credit: 543,294,568 RAC: 140,060 |
Talking about two DIFFERENT things here. Boinc apps are NOT the science apps. |
Send message Joined: 8 May 09 Posts: 3319 Credit: 520,337,727 RAC: 21,641 |
No, they are just dropping all the x86 32 bit versions. According to the Developers there is ALOT of 32bit crap in there holding things back, ie showing the actual amount of memory on gpu's that have more than 4gb so projects can filter then out of app that crash when trying to run them, ie Einstein. The 64bit stuff is already in there, making one without the 32bit stuff in it has been in the works for awhile to make sure Boinc still works afterwards. |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
Talking about two DIFFERENT things here. Boinc apps are NOT the science apps. I know. I thought you or someone else mentioned they were planning on stopping the 32bit science apps too. |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
According to the Developers there is ALOT of 32bit crap in there holding things back, ie showing the actual amount of memory on gpu's that have more than 4gb so projects can filter then out of app that crash when trying to run them, ie Einstein. The 64bit stuff is already in there, making one without the 32bit stuff in it has been in the works for awhile to make sure Boinc still works afterwards. It's not just the memory they need to filter on, I've got cards with plenty memory that won't run gravity, because they lack the newer instruction set. What they should be doing is looking at the model of graphics card, and comparing it to a list of ones that the program has been tested on. Or just testing for certain instructions being available. I notice when you start Boinc that it has a big list of AVX, MMX, etc for CPUs. Does it check cards like that too? |
Send message Joined: 8 May 09 Posts: 3319 Credit: 520,337,727 RAC: 21,641 |
According to the Developers there is ALOT of 32bit crap in there holding things back, ie showing the actual amount of memory on gpu's that have more than 4gb so projects can filter then out of app that crash when trying to run them, ie Einstein. The 64bit stuff is already in there, making one without the 32bit stuff in it has been in the works for awhile to make sure Boinc still works afterwards. Nope not until they dump the 32bit stuff it can't...conflicts you know. |
Send message Joined: 24 Jan 11 Posts: 708 Credit: 543,294,568 RAC: 140,060 |
Talking about two DIFFERENT things here. Boinc apps are NOT the science apps. No, I did not say that. I said that David Anderson wants to eliminate the 32 bit clients. He controls the BOINC applications. Has nothing to do with any science application other than Nebula. |
Send message Joined: 24 Jan 11 Posts: 708 Credit: 543,294,568 RAC: 140,060 |
According to the Developers there is ALOT of 32bit crap in there holding things back, ie showing the actual amount of memory on gpu's that have more than 4gb so projects can filter then out of app that crash when trying to run them, ie Einstein. The 64bit stuff is already in there, making one without the 32bit stuff in it has been in the works for awhile to make sure Boinc still works afterwards. The capabilities of the graphics cards are read from the vendors API stack. For our use that is either the CUDA API or the OpenCL API depending on which vendor the science applications use. Already at a disadvantage on the memory capacity with Nvidia cards as mentioned previously because of incorrect API usage. And at the low level, each card is still restricted by the silicon and gpu firmware installed. You will never get a OpenCL 1.0 capable card perform a OpenCL 1.2 or 2.0 instruction. |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
The capabilities of the graphics cards are read from the vendors API stack. For our use that is either the CUDA API or the OpenCL API depending on which vendor the science applications use. So who is responsible for Einstein Gravity trying to run on my R9 280X cards and failing? Has the card misreported it can do it? Or is Einstein not properly checking? |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
How will this make it better? Twice the effort going into 64 bit? Less untidy programming catering for both? They also need to rewrite the scheduler. I've yet again got something stupid happening here. I have Collatz set to run 1 WU per GPU, Einstein to run 2 per GPU, and Milkyway to run 2 per GPU (because that's what it's most efficient at). Normally this works fine, but I've just noticed it being daft. It's running the last Einstein in it's queue on half the GPU. It's got Collatz and Milkyway queued. But it's refusing to shove the Milkyways into the other half of the GPU. I can only assume because I have Collatz at higher priority, so it wants to run that. But it won't move Einstein out because that's also a fairly high priority. Half the GPU is idling! Anybody got a common sense stick? |
Send message Joined: 24 Jan 11 Posts: 708 Credit: 543,294,568 RAC: 140,060 |
Check how much cpu support is needed for each task type and make sure you have enough. Having only half of the load on a card with 0.5 share should only be transitional. It is making room to allow the full gpu tasks to start based on the REC needs. I have run both Einstein, Milkyway and GPUGrid on my cards with 0.5 shares for both Einstein and Milkyway and 1.0 share for GPUGrid and the cards and the scheduler behaved themselves. Many times I would have a Einstein and a Milkyway running on a card together with no issues. Only when a GPUGrid task was queued to run next did one of the 0.5 tasks drop off and none to replace it because the scheduler knew the GPUGrid task was next up. |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
Check how much cpu support is needed for each task type and make sure you have enough. Having only half of the load on a card with 0.5 share should only be transitional. It is making room to allow the full gpu tasks to start based on the REC needs. I have run both Einstein, Milkyway and GPUGrid on my cards with 0.5 shares for both Einstein and Milkyway and 1.0 share for GPUGrid and the cards and the scheduler behaved themselves. Many times I would have a Einstein and a Milkyway running on a card together with no issues. Only when a GPUGrid task was queued to run next did one of the 0.5 tasks drop off and none to replace it because the scheduler knew the GPUGrid task was next up. I've set all GPU tasks to "need" 0.01 cores of CPU, since they get a higher process priority in Windows and always shove CPU tasks out of the way automatically (I've tested it). It's not being sensible at all. If the full gpu tasks are more important, it should do those and stop the half ones immediately. If the half gpu tasks are more important, it should either download more of them, or run a full GPU task for a bit to reduce the buffer size. Also, since I had some more half GPU tasks sat waiting, it might as well have those running aswell! It would be like you and me having a big heavy job to do, say moving a sofa, which requires us both. Also we each have some smaller jobs to do. You decide one of yours is very important and go do that, and the way Boinc works, I'd sit and wait instead of doing something I have which is less important than the sofa. |
Send message Joined: 24 Jan 11 Posts: 708 Credit: 543,294,568 RAC: 140,060 |
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline. If you need to actually see which tasks the client will run next, invoke rr_simulation along with cpu_sched_deug in the Event Log. |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline. I see no evidence of a FIFO pipeline. If you lower the priority of a project, it will leave those tasks half done and start different ones. The point is it's not very intelligent at all as to what runs when. What would simplify it is to only apply project weights at one point - when they're downloaded. It seems to be doing it a second time when it picks one to run. An extreme example: Set MW to weighting 1000. Set Einstein to weighting 1. Boinc will download MW most of the time, but every so often it will get some Einstein. But since 1/1001 of the time adds up to running one task every blue moon, Boinc will hardly touch that task until it gets close to the deadline. Then at the very last minute it will start it, only to find you've shut the machine off, or are playing a game, or it misjudges the time remaining, so it gets returned late. |
Send message Joined: 8 May 09 Posts: 3319 Credit: 520,337,727 RAC: 21,641 |
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline. There's no winning no matter which way you choose...ie your way or if you chose to have it set to run immediately upon downloading it stops whatever else you are doing and runs to completion meaning you lose out on that special badge or bunkering event because it needed that 1% workunit. The point is Boinc has no clue you want to watch a movie tomorrow night or compete in that event or shut down the pc because it's roasting hot or you are going out of town or whatever, it's a computer not an AI. |
Send message Joined: 5 Jul 11 Posts: 990 Credit: 376,143,149 RAC: 6 |
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline. It knows how often the computer is switched off or placed into pause due to a game etc. It should therefore know not to start a 3 hour remaining task 4 hours before the end, in case I play the same game for 5 hours I played the whole of the last week! Even putting user interaction aside, it's only a predicted remaining time, Boinc can get it very wrong, so it should leave a much wider margin of error. Anyway, my way above would work fine. Let's say you choose weightings of 1 and 1000. It should download 1 task from project A and 1000 from project B before getting another A, but once it has downloaded them just run them. |
Send message Joined: 8 May 09 Posts: 3319 Credit: 520,337,727 RAC: 21,641 |
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline. Umm not exactly but anyway...I use settings of zero upto 100. |
©2024 Astroinformatics Group