[PPL-devel] Overhead of the generalization
Enea Zaffanella
zaffanella.enea at tiscali.it
Tue Apr 2 18:30:36 CEST 2002
I suggest to start looking at the implementation of the class Row::Type,
which probably needs some polishing anyway.
There should be an intrinsic overhead of one instruction for each newly
inserted
row in a Matrix, since we now have to "merge" the Matrix topology kind
(NNC/NC) and the row kind (LINE_OR_EQ/RAY_OR_POINT_OR_INEQ)
in order to obtain the Row::Type ...
I tried to perform this merge only once when adding multiple rows of the
same kind.
No other "intrinsic" overhead should be expected when working with the class
Polyhedron, apart from the usual topology tests (one for each public method
invoked).
However, we still have un-optimized implementations for, e.g.,
add_constraints() and for limited_widening_assign()
(see the FIXME comments in the code).
You maybe want to use the profiler to see if these are the causes
of the overhead.
ciao,
Enea.
Roberto Bagnara wrote:
>
> Here is how much time China took for analyzing the entire
> benchmark suite with our domain of closed polyhedra, in random
> days during the development of the generalization that allows
> us to deal with NNC polyhedra:
>
> Mar 15 2439.11
> Mar 16 2427.51
> Mar 17 2448.84
> Mar 18 2459.51
> Mar 19 2414.16
> Mar 22 2428.86
> Mar 23 2468.88
> Apr 01 2538.46
>
> The merge took place in the night between Marh 26 and 27.
> It looks like the overhead is greater than 4%. This is not
> very bad, but I expected it to be under 1%. A figure of >4%
> almost certainly means that we are paying a lot at the
> Row level. I hope we can improve the implementation so as
> to recover what we have lost.
> Ciao
>
> Roberto
>
More information about the PPL-devel
mailing list