Hi,
20% is when the search is done in ECLiPSe; if the search is moved into
Gecode (i.e. using Gecode's search engines), the problem is solved about
40% faster, so there is a corresponding increase in the difference
between 3.5.0 and 3.7.0 -- still not huge, but the difference is more
like 35-40% if the search is done in Gecode (and I guess this is the
number that is more relevant to you).
Cheers,
Kish
On 20/09/2011 13:01, Christian Schulte wrote:
Hi,
Even though 20% seems to be okay to me, I have added that count now does
less propagation when used with ICL_VAL or ICL_BND. The default ICL_DEF is
still domain consistent.
Cheers
Christian
--
Christian Schulte, www.ict.kth.se/~cschulte/
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Kish Shen
Sent: Tuesday, September 20, 2011 12:16 PM
To: [email protected]
Subject: Re: [gecode-users] Gecode 3.5.0 faster than Gecode 3.7.0?
Hi,
A follow-up: I've found another program (solves the crowded chessboard
problem, using a "natural" model where each chess piece is modelled with
a different domain value in a singe board, rather than having a 0/1
board for each chess pieces). This program uses count with =, and is 20%
slower in 3.7.0 (compared to 3.5.0).
Since I am getting this slow-down in two different programs, it could
mean that a count constraint with less than full domain consistency
could be useful. Does it make sense for Gecode to provide this?
Thanks and cheers,
Kish
On 14/09/2011 13:19, Christian Schulte wrote:
Okay, you got me red-handed here: before 3.7.0 count was in fact not
domain
consistent for the case
count(x,y,=,z)
where y is a variable. The pruning for y was actually missing (the values
for y can only be the values in x provided z>= 1).
So, a bug fix if you wish ;-)
Cheers
Christian
--
Christian Schulte, KTH, web.it.kth.se/~cschulte/
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Kish Shen
Sent: Wednesday, September 14, 2011 2:12 PM
To: [email protected]
Subject: Re: [gecode-users] Gecode 3.5.0 faster than Gecode 3.7.0?
Hi Christian,
Thanks for your reply!
The documentation for both 3.7.0 and 3.5.0 say that the single value count
constraint achieves domain consistency. I thought you can't really do
better
(more pruning) than domain consistency for single constraints, or am I
mistaken?
Cheers,
Kish
On 14/09/2011 09:35, Christian Schulte wrote:
This is most likely due to the count constraint. In Gecode 3.7.0 it
tries to do more pruning and that might cause the slow down (and your
examples might not necessarily profit from the additional pruning).
Cheers
Christian
--
Christian Schulte, KTH, web.it.kth.se/~cschulte/
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Kish Shen
Sent: Tuesday, September 13, 2011 6:41 PM
To: [email protected]
Subject: [gecode-users] Gecode 3.5.0 faster than Gecode 3.7.0?
Hi,
I have just upgrade the ECLiPSe interface to Gecode from Gecode 3.5.0
to 3.7.0. As I am currently doing some work on improving the
performance of the interface, I have been doing some timings with
example programs, and to my surprise, one of the example is running
consistently faster with 3.5.0. The run-times are:
3.5.0: 16.34s
3.7.0: 19.99s
The only change between these two is the version of Gecode used (plus
the changes in the C++ code needed for the upgrade, i.e. the #include
for the graph and scheduling modules).
As the program is written in ECLiPSe, there is no direct record of the
actual Gecode API calls made. The problem is the "roster" example from
the ECLiPSe website, modified for use with the Gecode interface. This
example is solving a simple rostering problem, and there are a lot of
relational constraints posted, plus some boolean expressions, all
posted via the MiniModel, and there are also some count contraints
(occurrences of one value variant). The search is done in ECLiPSe,
i.e. not using the search-engines of Gecode.
Is the above information sufficient for even guessing what the slow
down might be due to? If not, what additional information might be
needed?
Cheers,
Kish
--
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the
intended recipient (or authorized to receive for the recipient),
please contact the sender by reply e-mail and delete all copies of this
message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.
_______________________________________________
Gecode users mailing list
[email protected]
https://www.gecode.org/mailman/listinfo/gecode-users
--
This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or
authorized to receive for the recipient), please contact the sender by
reply
e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in England
and Wales with its registered office at 1 Callaghan Square, Cardiff, South
Glamorgan CF10 5BT.
_______________________________________________
Gecode users mailing list
[email protected]
https://www.gecode.org/mailman/listinfo/gecode-users
--
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.
_______________________________________________
Gecode users mailing list
[email protected]
https://www.gecode.org/mailman/listinfo/gecode-users
