Replies: 6 comments
-
Can you share some instances, where this happens? Also you might want to try the new Version 4.0.0 first. |
Beta Was this translation helpful? Give feedback.
-
I found kissat 4.0.0 at 430 is the one which took >72h on a ryzen9 with 5GHz |
Beta Was this translation helpful? Give feedback.
-
ahh, I think the effect also occurs in clasp running
|
Beta Was this translation helpful? Give feedback.
-
it seems that the problem is not present in kissat-4.0.0 |
Beta Was this translation helpful? Give feedback.
-
Excellent! This is probably due to the new BVA (factor) code. |
Beta Was this translation helpful? Give feedback.
-
seconds spent on the 40 sterten instances 7745 ,kissat-sc2024 as we have seen above, kissat 3.1.0 had also |
Beta Was this translation helpful? Give feedback.
-
Kissat had problems with some larger instances,
generated by the same program as the smaller ones.
Some instances take very long time starting at about
600 variables and 1 hour running time.
I do not see this with clasp running on the same instances.
I'm using kissat 3.1.0 on Linux-Ubuntu
here the timings in seconds for 12 instances
with exactly one solution and with 650 variables
about 5850 clauses , 13300 literals , 1 thread :
kissat:5177,1545,440,78600,22004,260471,6520,29460,4500,2760,1440,30861
and the clasp-timings (4 threads, nondeterministic)
clasp4:1600,175,1605,2507,1896,4694,2285,359,1300,1700,1483,548
it's even worse when I exclude the solution as an additional clause
and let it search the whole instance to confirm that there is no
solution:
kissat: 148,246,99,381,122,563,88,310,67,53,232,214
clasp4: 6,5,8,6,7,8,4,9,6,5,7,7
seconds * 1000 , including the time needed to find the solution
which then is "excluded" in a 2nd run
I do not see this problem with smaller instances of the same kind.
(exact-cover-problems, exactly-one-clauses)
maybe this is some bug easily to be corrected ?!
Beta Was this translation helpful? Give feedback.
All reactions