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.al...@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 <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 > -- Cordialement, Mohamed REZGUI
_______________________________________________ Gecode users mailing list users@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
