CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

Hello,

In my first answer I told you about a DAG used to maintain constructions
so as to evaluate exactly predicates using them.

When the answer of a predicate can be certified using approximated
constructions, the DAG does not change. When approximations are
not sufficient to conclude (what we call a filter failure), a traversal
of the DAG is made and the corresponding path is simplified and replaced
by the corresponding exact value.

The main difference between 4.3 and 4.5 is that the compiler gets better
and fewer filter failures are observed. The result is that the DAG is
more often simplified when using 4.3 than with 4.5 (thus the memory 
increase with 4.5).
You can observe it by manually simplify the DAG by using for example the
following:
      if (i % 5 == 0 ) exact(vit->point());
      // Option B
      pointsToInsert.push_back(vit->point() + v);

In general, it is not a good solution to use iterative constructions
with the Lazy_kernel as no automatic simplification policy are
implemented right now and can lead to memory issues.

Does the displacement of your points need to be exact? Otherwise using
Exact_predicates_inexact_constructions_kernel might be sufficient.
If you tell us more details about your application, we might find a
solution that fit your needs.


S.



Graham Macpherson wrote:
> Hi Sebastien,
>
> Do you have any further info on using gcc 4.5?  Is it an isolated problem
> related to where I found it, or are there wider implications across CGAL?
>
> Thanks,
>
> Graham
>
>
> On Monday 17 January 2011 13:40:04 Sebastien Loriot (GeometryFactory) wrote:
> > Graham Macpherson wrote:
> > > Hi Sebastien,
> > >
> > > Thanks for the reply.
> > >
> > > I've checked and I do see the linear memory increase with openSUSE and not 
> > > with
> > > Ubuntu; the logs I attached to my email are valid.
> > >
> > > Is it worth investigating if gcc 4.4 vs 4.5 makes a difference?
> > You were right, there seems to be a problem when using gcc 4.5.
> > I don't know right now what. I'll post here when I have more
> > information.
> >
> > S.
> >
> >
> > > Regards,
> > >
> > > Graham
> > >
> > >
> > >
> > > On Monday 17 January 2011 08:40:52 Sebastien Loriot (GeometryFactory) wrote:
> > > > There is no memory leak in your code.
> > > >
> > > > Behind the Exact_predicates_exact_constructions_kernel, there are
> > > > *a multi-precision number type (for example Gmpq if GMP is available)
> > > > *filtering mechanism on constructed objects (such as points)
> > > >
> > > > In your for loop, you are iteratively summing to your points a vector.
> > > > Both implementation details are responsible for the memory increase:
> > > >
> > > > *The precision needed by the number type to exactly do the sums
> > > > requires more precision, thus more space. Running you code with
> > > > CGAL::Simple_cartesian<CGAL::Gmpq>, you will observe an increase in
> > > > memory usage, but not at each iteration (only when precision of numbers
> > > > is increased).
> > > >
> > > > *the filtering mechanism maintain a DAG of the cascaded constructions.
> > > > Each sum create a note in the DAG. This is the real cause of the memory
> > > > usage increase in your case.
> > > >
> > > >
> > > > However, I am surprised that you do not observe the memory consumption
> > > > increase on Ubuntu.
> > > > Can you please check again to confirm whether there is a problem?
> > > >
> > > > S.
> > > >
> > > > Graham Macpherson wrote:
> > > > > Hello all,
> > > > >
> > > > > I've found a strange memory problem that I've reproduced in the attached code.
> > > > >
> > > > > I'm taking the vertices of a Delaunay tessellation, calculating a displacement
> > > > > for them, clearing the tessellation, then reinserting the displaced vertices.
> > > > > When I run this, the memory use by the process increases linearly with each
> > > > > iteration, which is wrong, it should be essentially constant, however:
> > > > >
> > > > >  + The problem doesn't occur with option A in the attached, only with option 
> > > > > B,
> > > > >    i.e. when adding a Vector_3 to the point;
> > > > >
> > > > >  + The problem doesn't occur using
> > > > >    Exact_predicates_inexact_constructions_kernel, only with
> > > > >    Exact_predicates_exact_constructions_kernel;
> > > > >
> > > > >  + It doesn't appear on all operating systems - it appears on openSUSE 11.3, 
> > > > > but
> > > > >    not on Ubuntu 10.04.
> > > > >
> > > > > Also attached are two log files showing the contrasting behaviour on the two
> > > > > operating systems with the code the same.
> > > > >
> > > > > I've tried on openSUSE 11.3 with gcc 4.5.0 (system compiler) and gcc 4.5.2,
> > > > > boost versions 1.40.0, 1.42.0 (system) and 1.45.0, and with CGAL 3.5.1 and 
> > > > > CGAL
> > > > > 3.7, and they all essentially do the same thing.
> > > > >
> > > > > On Ubuntu I'm using CGAL 3.7, gcc 4.4.3 (system compiler) and boost 1.40.0
> > > > > (system).
> > > > >
> > > > > Note, the memInfo class is one that's part of other libraries I'm using, so it
> > > > > won't compile for you, it's only there to show how the output was generated.
> > > > >
> > > > > Assuming that the addition operation in option B is legitimate, then this 
> > > > > looks
> > > > > like a bug in a library.  Any suggestions for how to get to the bottom of it?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Graham
> > > > >
> > > > > --
> > > > > Graham Macpherson
> > > > >
> > > > > OpenCFD Ltd.
> > > > > www.openfoam.com
> > > > >
> > > > >
> > > > > +44 (0)118 9471030
> > > > >
> > > > > 9 Albert Road
> > > > > Caversham
> > > > > Reading RG4 7AN