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
|