[gecode-users] Problem with rev13418 performances

[Mohamed Rezgui]

sorry, I do not finish with the bug. Can you undefine HAVE_MMAP in windows
compilation of the flatzinc library too please (in CMakeList.txt) ? ^^


Best Regards,
Mohamed REZGUI

2013/2/27 Mohamed Rezgui <kyo.alone at gmail.com>

> 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 <tack at 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.alone at 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 <cschulte at 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.alone at gmail.com]
>>> *Sent:* Tuesday, February 26, 2013 7:49 PM
>>> *To:* victor.zverovich at gmail.com
>>> *Cc:* cschulte at kth.se; users at 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.zverovich at gmail.com <victor.zverovich at 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.alone at 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 <cschulte at 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-bounces at gecode.org [mailto:users-bounces at gecode.org] *On
>>> Behalf Of *Mohamed Rezgui
>>> *Sent:* Tuesday, February 26, 2013 3:31 PM
>>> *To:* users at 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 at gecode.org
>>> https://www.gecode.org/mailman/listinfo/gecode-users****
>>>
>>> ** **
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> --
>>> Cordialement,****
>>>
>>> Mohamed REZGUI****
>>>
>>
>>  _______________________________________________
>> Gecode users mailing list
>> users at gecode.org
>> https://www.gecode.org/mailman/listinfo/gecode-users
>>
>>
>>
>
>
> --
> Cordialement,
> Mohamed REZGUI
>



-- 
Cordialement,
Mohamed REZGUI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20130227/6998f768/attachment-0001.html>