Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-dev] benchmark results

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


Back to the top