Yes, but the question was strictly about minimal memory footprint. I
suggested to invest some limited effort into "optimization" of the
existing code rather than rewriting the whole thing to Oz, hoping that
a straightforward rewrite of the C++ code in Oz would consume less
memory.
Can you elaborate a bit on "rewrite of the C++ code in Oz"? Any idea to
improve Mozart is welcome! We are fully open to suggestions.
I think that Irene has a piece of C++ code, so I was referring to
translating that code into Oz, not optimizing Oz sources.
As for extensions, I'm planning to implement a new edge-finding
propagator based on a recent article from L.Mercier and P.V.Hentenryck
(http://www.cs.brown.edu/~pvh/ef2.pdf). I hope that I'll have time for
this. I think that the current builtin propagators in Mozart are a bit
buggy. (Or, do you know of a kind PhD student willing to do this? :-))
First, types are dynamic in Oz. Record arities are created at runtime,
for instance. In most cases, the virtual machine has to handle
references to data whose type is only known dynamically...
Yes, this is very cool and it speeds up coding. On the other hand, you
lose some potential compile-time type checks... but I guess that you
can't have it all, there's probably always some tradeoff.
Second, the most central data structure in Mozart is definitely not a
"standard container": dataflow variables.
I was referring to C++ being high-level when you use standard C++
library's containers such as std::map.
A variable is a transient
entity that is eventually bound to a value or another variable. You
need a dereferencing mechanism to cope with variables. If you get a
look at the implementation, you'll see that variables are incredibly
compact.
Yes, I partly have, and I completely agree. I think that you all did a
great job!
I think that although you can achieve (I think that with no effort)
better memory behavior in C++ than Oz (not only consumption, but also
fragmentation etc.), Oz may be more suitable for some operations on
the data. But this is beyond the topic, isn't it?
If you can do that with no effort, please tell us! ;-)
Well, with limited effort. Or with little *extra* effort ;-)
But this of course depends on the nature of the data and the desired
memory-resident data structure.
Note that the garbage collector of Mozart automatically compactifies
memory, hence no fragmentation issue here. Note also that quite a few
basic operations are defined entirely in Oz, like the module List.
OK, then this simply reduces to a performance issue.
About List - yes, but if I remember correctly, then e.g. dictionaries
are written in C++, right? I mean, if you want to implement some special
modern Mehlhorn's :-) data structure, then maybe you would end up coding
it in C++ anyway. (Now that I think of it, is there a priority queue
available in Oz? Something like fibonacci heap?)
All the best,
Filip
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
