comb.Node@9fe84e was before locked by var@185ad79, but gets unlocked
again in the second line of the debug trace.
On 06/06/2012 10:34 PM, Christian Krause wrote:
This is very difficult to debug. I added some output to see which
variables are locked to which nodes, and to see when a NAC match
was found. Here the critical part. What should happen is that
comb.Node@9fe84e is matched by the NAC and thereby no valid match
is found.
...
NAC match found? true
Unlocking var@185ad79
Unlocking var@719f1f
Unlocking var@63a721
Locking var@63a721 to comb.Node@1000bcf (dynamic)
Locking var@719f1f to comb.Node@754fc (dynamic)
Locking var@185ad79 to comb.Node@c52200 (dynamic)
NAC match found? false
Unlocking var@185ad79
Unlocking var@719f1f
Unlocking var@63a721
Locking var@63a721 to comb.Node@ffd135 (dynamic)
Locking var@719f1f to comb.Node@1000bcf (dynamic)
Locking var@185ad79 to comb.Node@1cc0a7f (dynamic)
NAC match found? false
Side effect warning: deleting 'ver'-edge from comb.Node@c52200
(dynamic) to comb.Node@9fe84e (dynamic)
Side effect warning: deleting 'hor'-edge from comb.Node@754fc
(dynamic) to comb.Node@9fe84e (dynamic)
=== EXECUTED RULE 'addNewColumn' [TRUE] ===
On 06/03/2012 11:06 AM, Enrico Biermann wrote:
Hi,
true, the optimization is not the problem, however it probably
uncovered a bug in the constraints. you could make a rule for
each constraint type present in the application condition of
addNewColumn and then switching the order of variables (a nice
side benefit is that these rules would also make great unit
tests).
At least one variable order of one rule should fail to match.
Regards,
Enrico
On 03.06.2012 10:53, Christian Krause wrote:
Hi,
I couldn't find a bug in the example. The optimization is not
the problem. I changed the order of the nodes in the NAC and
now I get the error with and without the optimization.
From the log I can see that the NAC was not correctly checked.
There does exist an object and two edge, so the rule should
not be applicable to this match. The interpreter prints waring
now that edges are deleted due to a side effect. I still don't
know why the match finder has a problem.
Cheers
Christian
On 06/03/2012 10:38 AM, Enrico Biermann wrote:
Hi,
The order of variables should be irrelevant (for correct
results).
If it is not, then it points to either a missing constraint
or an incorrect handling of either initialized or
uninitialized domain slots for an existing constraint.
The order of nodes for the application condition of
addNewColumn was changed from 1, 2, 3, 4, 5 (order of
creation) to 3, 1, 4, 5, 2. So a constraint of 3, 4 or 5
should be responsible, but someone with knowledge of the
example should continue with the analysis.
Regards,
Enrico
On 02.06.2012 18:07, Christian Krause wrote:
Hi,
if you want to see why the optimization is important:
check out the latest version of the examples and run the
STSBenchmark with and without the optimization (order of
magnitude faster with optimization).
Enrico: does the MatchFinder assume any particular order
of the variables in the value lists returned by
ruleInfo.getVariableInfo().getGraph2variables() ? All I
was doing is to sort the lists.
Cheers,
Christian
On 06/02/2012 11:06 AM, Christian Krause wrote:
Hi,
I added the examples to the SVN. My last optimization
causes the comp-example to fail. I commented out the
optimization in line 342 of EngineImpl therefore. So for
now it works, but we should try to fix it so that the
optimization can be used. It seems like the NAC of
addNewColumn is not properly checked when the
optimization is used (nodes are added in every rule
application for the same match).
I turned on the logging. So if you want to try it out,
do this:
1) run CombBenchmarkManyMatches (works)
2) comment line 343 and uncomment 344-350 in EngineImpl
and execute it again (will not stop).
Cheers,
Christian
On 06/02/2012 10:06 AM, Dmitry Zakharov wrote:
Hi Christian,
I am giving you the short summery of all test cases.
With red I highlight those where hanshin is slower.
1) STS: Henshin is faster
2) LTS:
Henshin
StoryDiagram
N=20 R=10000 50541 ms 76562 ms
N=500 R=1 120765
ms 21505 ms
3) ALAP:
Henshin and SD have time same time
Nodes HENSHIN StoryDiagram
1000 468 ms 571 ms
5000 6973 ms 6751 ms
10000 29319 ms 30936 ms
4) Program Understanding : Henshin is
faster
5) Comb Many-Matches
Henshin Story
Diagram
Grid 50, pattern size 10 (2009 matches)
48725 1098
ms
Grid 50, pattern size 50 (49
matches) 46747
748 ms
6) Comb No-Match
Henshin
Story Diagram
Grid 200, pattern 10 38551 ms 1478
ms
Grid 200, pattern 50 54934 ms 3109 ms
regards, dmitry
on 02.06.2012 9:19, Christian Krause wrote:
Hi Dmitry,
I have one more request: could you briefly summarize where Henshin was
slower than SD and also give us a hint how much slower it was? This
would be very helpful for the profiling and optimization.
Cheers,
Christian
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|