Hi, Just a comment on the last part of Guido's reply. I've actually attempted a refactoring as I think he suggested by implementing views with virtual functions instead of templates. What I found was that it has a significant negative impact on runtime. If the goal is to reduce compiled code, maybe you could look instead to explicitly template instantiation, and factor out some common instantiations? I must say I did that on another view-based solver, not on gecode, but I guess the same would be true here.
Hope it helps, Marco On Apr 11, 2015 8:00 AM, "Guido Tack" <t...@gecode.org> wrote: > > > On 11 Apr 2015, at 11:56 am, Sebastian Kosch < > sebastian.ko...@mail.utoronto.ca> wrote: > > > > Thanks Guido, that's helpful! > > > > Before I get started on c) then -- to start, I would probably just drop > in mzn2fzn.cpp + friends, turn its output into a FlatZincSpace and run it > > We already have a version of the Gecode/FlatZinc interpreter that is fully > integrated into libminizinc (i.e. without the detour of producing a > FlatZinc text file). We hope to be able to release at least a preview of > this soon (this is with my MiniZinc hat on, it's not really related to > Gecode). > > > -- I have two more questions: > > > >> a) There are a few options here. You can change the parser to also > export its symbol table, which you can use to look up variables in the > FlatzincSpace by their name. > > > > That sounds really convenient, but I'm afraid I'll need a bit more > hand-holding. As far as I can see, my named variable arrays in Minizinc > turn into dozens of X_INTRODUCED_### variables in Flatzinc. How do I keep > track of them? > > Yes, that's a problem, this mapping is currently not available. All you > can do at the Gecode level is to use the names in the FlatZinc (and that's > the symbol table you could use). If you want to discuss more about the > MiniZinc side of things, I'd suggest we move the discussion to the MiniZinc > forums (or private email) instead. > > > > >> I also have some ideas on making Gecode much more compact (by removing > much of the template instantiation), I think that should help make the > generated Javascript more manageable. > > > > That's an interesting and promising idea. Is this on your short-term > agenda? If not, and if I decide to look into it myself, where would be the > best place to start (in terms of refactoring effort/bloat reduction ratio)? > > First of all I'd try out the usual compiler options, i.e. turning off > inlining, and setting the optimiser to focus on code size. > > After that it's really a refactoring job. Most propagators in Gecode use > "views" to implement different versions of a constraint, and each version > requires a different template instantiation. That blows up the code size. > Instead, it would be possible to implement the different versions using > views with virtual functions, and then instantiate the propagators only > with the base view class and derive the different versions by inheritance. > I haven't fully thought this through yet, it's possible that it would > involve quite a lot of code duplication and copy/paste, no idea if it's > possible to do it more systematically. > > Cheers, > Guido > > > > >> b) The serialisation interface was part of Gecode 2 but we removed it > in Gecode 3 (I think), mainly because it was an incredibly invasive part of > the code (IIRC it made up about 30% of the overall Gecode code base!). > > > > Ah, I see. > > Thanks again! > > > > Seb > > > >> > >>> On 11 Apr 2015, at 12:03 am, Sebastian Kosch < > sebastian.ko...@mail.utoronto.ca> wrote: > >>> > >>> Hi, > >>> > >>> I am playing with the idea of building a simple browser interface to > >>> Gecode. I have tweaked the source so that it compiles to a asm.js blob > >>> via emscripten -- notwithstanding the dozens of obvious reasons why > >>> doing this is a dumb idea, I can now solve Flatzinc models in the > >>> browser, and that's pretty cool. > >>> > >>> I would like to do more than just input a Flatzinc string, of course, > >>> and build something closer to Gist maybe. So I would like to either > >>> > >>> a) write wrapper functions in C++ to interact with the Flatzinc model > >>> after it's been read in. This code would go into the JS blob and allow > >>> me to interact with the space from the browser (e.g. add/remove > >>> variables and constraints, change options, restart searches etc.) -- > or: > >>> > >>> b) have an easier way of passing Javascript objects directly to Gecode > >>> to manipulate the space. > >>> > >>> (a potential option c) might be to integrate the Minizinc parser into > >>> the JS blob, and to create a "proper" space in Gecode directly from > >>> Minizinc instead of compiling to Flatzinc first, and then use a) ... > but I'd rather not.) > >>> > >>> In terms of a), what are my options beyond finding out which of the > >>> variables are part of the optimization? Can I access Flatzinc > >>> annotations on variables somehow? Is there a way to predict which > >>> objects in the space correspond to which of the parts in the "original" > >>> Minizinc model? > >>> > >>> In terms of b), it appears that this was planned at some point (see > >>> > https://github.com/mattetti/Gecoder/blob/0352cf3b879d2f6764a4da6efe3fb2b1ff1b819c/vendor/gecode/win32/include/gecode/serialization.hh > ), > >>> but then dropped. Could I investigate this further, or did you come up > >>> against hard reasons why that's not an option at all? > >>> > >>> I hope all of this doesn't sound too crazy or convoluted. I'm looking > >>> forward to your thoughts! > >>> > >>> Sebastian > >>> > >>> > >>> > >>> _______________________________________________ > >>> Gecode users mailing list > >>> users@gecode.org > >>> https://www.gecode.org/mailman/listinfo/gecode-users > >> > > > > > > _______________________________________________ > > Gecode users mailing list > > users@gecode.org > > https://www.gecode.org/mailman/listinfo/gecode-users > > > _______________________________________________ > Gecode users mailing list > users@gecode.org > https://www.gecode.org/mailman/listinfo/gecode-users >
_______________________________________________ Gecode users mailing list users@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
