There is no possibility to demand fixes on the trunk.
For the last time: this is the trunk (this means development version) and
not a released version, use the released version. To quote the download
page:
Please note, however, that this version reflects work in
progress, so there may be bugs. It even may not compile at all. So, for the
curious and venturous, the URL is
Christian
--
Christian Schulte, Professor of Computer Science, KTH,
www.ict.kth.se/~cschulte/
From: Mohamed Rezgui [mailto:kyo.al...@gmail.com]
Sent: Wednesday, February 27, 2013 7:24 AM
To: Guido Tack
Cc: cschu...@kth.se; users@gecode.org
Subject: Re: [gecode-users] Problem with rev13418 performances
OK thank you very much.
I found another bug in linking the libgecodeflatzinc.
error reference with Flatzinc::parse ...
so I must include the files parser.tab.cpp and lexer.yy.cpp in MakeFile.in
--> FLATZINCSRC0 = flatzinc.cpp registry.cpp parser.tab.cpp lexer.yy.cpp
to link successfully.
Can you fix this bug please ?
Thank you very much for your work ^^ You are the best ^^
Best Regards,
Mohamed REZGUI
2013/2/26 Guido Tack <t...@gecode.org>
There was a memory leak in flatzinc. It's now fixed in the trunk, I tried
your example and it seems to work fine.
As Christian said, FlatZinc in the trunk uses a different search heuristic
if you don't specify the search in the model, so the behaviour may still be
slightly different.
Cheers,
Guido
On 27/02/2013, at 7:37 AM, Mohamed Rezgui <kyo.al...@gmail.com> wrote:
Hi,
I tried also with cmake in 3.7.3 compilation and I have the same thing.
So, in your opinion, is it better to remove some instances in my benchmarks
or to use 3.7.3 version ?
Best Regards,
Mohamed REZGUI
2013/2/26 Christian Schulte <cschu...@kth.se>
Hi,
I just tried myself and there is indeed a big bug somewhere. It appears to
be in the flatzinc stuff and not only due to the branching, one can see that
by the difference in number of nodes explored per second (it looks it also
has a memory leak of epic proportions and prints random messages on the
screen). I checked the base Gecode stuff and there everything is fine, the
trunk is in most cases slightly faster.
But as said, it's the trunk ;-)
Cheers
Christian
--
Christian Schulte, www.ict.kth.se/~cschulte/
From: Mohamed Rezgui [mailto:kyo.al...@gmail.com]
Sent: Tuesday, February 26, 2013 7:49 PM
To: victor.zverov...@gmail.com
Cc: cschu...@kth.se; users@gecode.org
Subject: Re: [gecode-users] Problem with rev13418 performances
Hi Victor,
thank you, I dit it but no speed up come. As Christian Schulte says : it
rather the default strategy is bad.
I hope the new version (4.0) comes soon ^^.
Thank you for your attention ^^
Best regards,
Mohamed REZGUI
2013/2/26 victor.zverov...@gmail.com <victor.zverov...@gmail.com>
CMake supports different build types, make sure that you use the Release one
to enable optimizations and disable asserts and debug info. You can do it at
configuration time with the following command:
cmake -DCMAKE_BUILD_TYPE=Release
HTH,
Victor
On Tue, Feb 26, 2013 at 7:22 AM, Mohamed Rezgui <kyo.al...@gmail.com> wrote:
OK so I will work with gecode 3.7.3.
I just compile the revision with cmake and I use gecode 3.7.3 from download
section of the official website.
I will see the flags used in compilation.
Thank you for all ^^
Best Regards,
Mohamed REZGUI
2013/2/26 Christian Schulte <cschu...@kth.se>
That's what happens when you use the trunk, you should never, because, yes,
it is the trunk and not a release ;-)
The difference is easy to explain though. The instance you have chosen does
not have a search annotation in it, so Gecode picks some default search
(which for this type of problems is a desaster anyway). And we just changed
the default search behavior for the upcoming Gecode 4.
But then there is another observation: Did you compile both versions with
exactly the same flags? I doubt. Please check this.
Christian
--
Christian Schulte, Professor of Computer Science, KTH,
www.ict.kth.se/~cschulte/
From: users-boun...@gecode.org [mailto:users-boun...@gecode.org] On Behalf
Of Mohamed Rezgui
Sent: Tuesday, February 26, 2013 3:31 PM
To: users@gecode.org
Subject: [gecode-users] Problem with rev13418 performances
Hi,
I made benchmark with the attached instance (2DLevelPacking_Class5_20_6.fzn)
from the minizinc challenges with the latest version of gecode revision
13418 in release mode.
When I compare performances between this version and the 3.7.3 version of
gecode, I am so surprised !!!.
Gecode 3.7.3 is faster than the latest revision !!!
I just use the parameter -s for stats :
---> gecode/bin/fz -s 2DLevelPacking_Class5_20_6.fzn
Use of E7-4870 Intel processor
Benchmarks with gecode rev13418 :
%% runtime: 2594.74 (2594737 ms)
%% solvetime: 2594.72 (2594718 ms)
%% workers: 1
%% type search: bab
%% solutions: 1
%% objective: 9
%% variables: 801
%% propagators: 70
%% propagations: 22306041
%% nodes: 1564742
%% failures: 702986
%% restarts: 0
%% peak depth: 51
%% peak memory: 838 KB
Benchmarks with gecode 3.7.3 :
%% runtime: 32.394 (32394.264 ms)
%% solvetime: 32.384 (32384.895 ms)
%% workers: 1
%% type search: bab
%% solutions: 1
%% variables: 801
%% objective: 9
%% propagators: 70
%% propagations: 23159635
%% nodes: 3114256
%% failures: 1557118
%% peak depth: 53
%% peak memory: 2831 KB
Can you help me about that ???
Is it better that I work with 3.7.3 version ???
Thank you for your attention.
--
Best Regards,
Mohamed REZGUI
_______________________________________________
Gecode users mailing list
users@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
--
Cordialement,
Mohamed REZGUI
_______________________________________________
Gecode users mailing list
users@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
--
Cordialement,
Mohamed REZGUI
_______________________________________________
Gecode users mailing list
users@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
