Closed msoos closed 3 years ago
I can reproduce locally. I will investigate.
Looks like it only happens when we reduce the gpu clause db. My bad. I usually run the non-release on only a few instances, and I only run the release version (without assertions, much more performant) on a larger number of instances. I will run the non-release on more instances.
Ahhh, sorry, I forgot I should have compiled the release version! My bad :( Ok, will do that once you fix this issue! Sorry again!
I have fixed an actual non-release bug. The one you mentioned was an assertion that a device array would would not have a size bigger than 500 millions. I guess that when I added that line, 500 millions seemed really huge. But I suspect it could happen with arrays with a type of size 1. We use such arrays when copying the new clauses to the GPU as well as sending the updates to the assignments. So I've increased the limit.
Thanks for your help!
Thanks for the fix! I have now made sure to pull the update and build a release version, so we get the extra speed as well :) I scheduled a run, I'll get back to you with the results. It seems that we will be able to schedule one 24-thread run on 30 nodes for about 12-15h, to do a full SAT competition run. I'm expecting somewhere around 7000 hours of CPU core time/run. We should be able to burn at least 200k hours, so we should be able to do about 30 full runs to try out different options. We can schedule them "stacked", i.e. we can put 3-5 into the queue and they will be ran that way, perhaps in parallel (on different 30 nodes), or sequentially. So we should be able to get some data back, tune, etc.
Thanks again for the quick fix, I'll get back to you with the results,
Mate
Hi
I think that the gpu version will do better with 32 threads than with 24. (on my desktop, it did better with 32 threads than with 16, on a 16 cores machine). We're limited to 32 threads though.
So I think the commands we can run are:
glucose-gpu_release -write-stats-period-sec=-1 -max-thread-count=24 -max-memory=90000 -mem-lim=100000 glucose-gpu_release -write-stats-period-sec=-1 -max-thread-count=32 -max-memory=90000 -mem-lim=100000 glucose-gpu_release -write-stats-period-sec=-1 -max-thread-count=32 -gpu-inc-reduce-db=60000 -max-memory=90000 -mem-lim=100000 glucose-gpu_release -write-stats-period-sec=-1 -max-thread-count=32 -gpu-inc-reduce-db=20000 -max-memory=90000 -mem-lim=100000
glucose-syrup_release -maxnbthreads=24 -maxmemory=90000 -mem-lim=100000 glucose-syrup_release -maxnbthreads=32 -maxmemory=90000 -mem-lim=100000
It's really exciting to be able to test a full competition run in half a day rather than weeks, thanks!
If we want to do more run, maybe it would be possible to to run it on the sat 2019 competition?
Nicolas
For example, when solving
sc2013.cnf
from SAT 2019. Command line ran:./glucose-gpu -write-stats-period-sec=-1 -max-thread-count=12 -max-memory=45000 -mem-lim=50000 003-sc2013.cnf
output:The full
/usr/bin/time --verbose
output is:Note that I used
doalarm
but that should be fine I think? This repeats with other CNFs, too. Here is001-80-12-sc2014.cnf
(also from SAT 2019):The
/usr/bin/time --verbose
output on this one is:Note that I adjusted the command line and ran 12 threads, 2 of them in parallel on a single node, with a single GPU shared by the two. I did this because I wanted to make sure we don't go over our time budget for this particular run (we can increase it for future runs).
Here are all the assert failures we get from a run on SAT'2019 instances:
I hope my command line parameter changes (dividing everything by 2) is OK?
Cheers,
Mate
PS: I was running this under:
As I usually do, to make sure things don't go astray.